Сущность и бизнес-уровень / логика

Question

Я занимаюсь самообучением архитектуры MVVM-light - EF Application. Я пытаюсь создать приложение, подобное продукту или квитанции.У меня есть Db / EF с таблицей / сущностью продукта и квитанции в отношении многих ко многим.тогда у меня есть DAL, который просто использует Linq для выполнения простого CRUD.

вопрос в том, где и как поместить мою бизнес-логику в это приложение.

пара идей пришла на ум

опция 1 - создать ReceiptBo (бизнес-объект Receipt), который наследует класс Entity Receipt и Icollection (ProductBo), класс ReceiptBo будет отвечать за добавление Product, вычисление итогов и промежуточных итогов и вызов Dalдля вставки.Возможно, эта опция показалась немного излишней.

option 2 - вывести методы вычисления в сгенерированные объекты Entity, используя частичные классы и просто используя BuisnessLayer для вызова Dal.это сделало бы классы Buisnesslayer устаревшими, на мой взгляд, и я не уверен, что классы сущностей вообще следует использовать для бизнес-логики?

опция 3 - делать бизнес-классы, но не беспокоиться об использовании наследованияПросто добавьте продукты в Entity, сделайте там вычисления и позвоните в Dal для вставки.который кажется простым, но не очень элегантным.

вариант 4 - ничего из вышеперечисленного и я не знаю

сейчас я не использую WCF, но идея в том, что я хочусделайте это приложение слабосвязанным, чтобы его было легко реализовать и расширить.

также я немного запутался в том, что такое бизнес-уровень.в некоторых примерах он больше используется как Dal, который также выполняет вычисления, тогда как другие говорят, что это не сделано.

некоторая помощь будет очень полезна.THX

PS: извините за мой плохой английский

Answer 1

Обычно я сохраняю свою бизнес-логику в моем ViewModels, а не в Models, и я рассматриваю объекты EF как Models. Самое большее, у них будет некоторая базовая проверка данных, такая как проверка длины или обязательных полей.

Например, EditRecieptViewModel будет проверять бизнес-правила, такие как проверка значений в определенном диапазоне, или проверка того, что пользователи имеют доступ к редактированию объекта, или выполнение некоторых пользовательских вычислений при изменении значения.

Кроме того, не забывайте, что ViewModels должен отражать представление, а не Model, поэтому не каждый Model будет иметь ViewModel своего

Answer 2

На самом деле, я бы просто пошел и выбрал общую многоуровневую архитектуру, разработанную следующим образом:

• уровень доступа к данным (в основном, ваша модель Entity Framework вместе со всеми вашими сущностями)
• бизнес-уровень, который предоставляет методы для доступа к вашим сущностям (методы CRUD + любой пользовательский метод, выполняющий некоторую логику)
• уровень службы, который предоставляет методы без сохранения состояния через WCF (служба + контракт данных)
• уровень представления (в вашем случае с использованием шаблона MVVM)
  • Представления (страницы XAML)
  • ViewModels (классы C #)
  • Модель представлена ​​здесь объектамикоторые выставляются через WCF сервисным уровнем

Я бы не стал добавлять какой-либо метод непосредственно в сущности.Все методы определяются на бизнес-уровне и предоставляются сервисным уровнем.