Бизнес-логика в POCO Entity Framework с использованием частичных классов?

Question

У меня есть бизнес-логика, которая может либо находиться на уровне бизнес-логики / сервиса, либо быть добавлена ​​к новым членам расширенного класса домена (EOC T4, сгенерированного POCO), который использует функцию частичного класса.может иметь:

a) bool OrderBusiness.OrderCanBeCancelledOnline(Order order) .. или (порядок заказа)

или

b) bool order.CanBeCancelledOnline() .. т. е. сам ордер знает, может ли он быть отменен.

Для меня вариант b) больше ОО.Однако вариант а) позволяет применять более сложную логику, например, с использованием других объектов или служб домена.

На данный момент у меня есть смесь обоих вариантов, и это не выглядит элегантно.на это будет очень признателен!

Answer 1

Ключевым моментом в ОО для меня является то, что вы говорите объектам делать что-то для вас .Вы не извлекаете атрибуты и не принимаете решения самостоятельно (в классе помощника или другом).

Поэтому я согласен с вашим утверждением относительно варианта b).Поскольку вам требуется дополнительная логика, выполнение операции над объектом не причинит вреда при передаче ссылок на дополнительные вспомогательные объекты, чтобы они взаимодействовали.Делаете ли вы это во время самой операции или предварительно заполняете объект заказа этими сотрудничающими объектами, очень сильно зависит от вашей текущей ситуации.

Answer 2

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

Более длинный ответ:

Если вы разместите свою логику в слое обслуживания, вы аффективно будете следовать шаблону сценария транзакции и получите модель анемичного домена . Это может быть действительный маршрут, но обычно он лучше всего работает с простыми и небольшими проектами. Проблема заключается в том, что уровень сценария транзакции (уровень службы) становится все сложнее поддерживать по мере роста.

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

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

Вопреки одному из ответов, использование классов POCO не означает, что в ваших классах домена не может быть бизнес-логики. POCO - это не применение структур, специфичных для фреймворка, к классам вашего домена , таких как методы и интерфейсы, специфичные для определенного ORM. Класс с некоторыми функциями для применения бизнес-логики, очевидно, все еще является Plain-Old-CLR-Object.

Answer 3

Вы также можете использовать методы расширения для POCO, чтобы обернуть ваши методы bll. Таким образом, вы можете продолжать использовать свой текущий BLL. в c # что-то вроде:

public static class OrderBusiness <- everything must be static, class and method
{
  public static bool CanBeCancelledOnline(this Order order) <- notice the 'this'
  {
    logic ...

И теперь вы можете сделать заказ. CanBeCancelledOnline ()

Answer 4

Обычный вопрос, и частично субъективный.

ИМО, вам следует выбрать вариант А.

POCO должны быть именно такими объектами "plain-old-CLR". Если вы начнете применять к ним бизнес-логику, они перестанут быть POCO. :)

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

Действительно зависит от того, насколько сложны ваши бизнес-правила. В нашем приложении бизнес-правила очень просты, поэтому мы используем вариант A.

Но если ваши бизнес-правила начинают становиться беспорядочными, рассмотрите возможность использования Specification Pattern.