бизнес-уровень с несколькими объектами со всеми свойствами, заполненными из БД, или один объект с заполненным только подмножеством

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

Случай 1

Например, пользователь принадлежит городу, который, в свою очередь, принадлежит штату и стране, User, City, State и Country - это таблицы в моей базе данных с большим количеством полей, но мне нужен список пользователей со списком Заказы, поэтому я создаю бизнес-объект, называемый, например, UserWithOthers, только с важными свойствами (UserId, UserName, CityName, StateName, CountryName, List<Order>), и мой DAL извлекает только эти поля из базы данных.

Случай 2

Я хочу сейчас вернуть пользователя с количеством заказов, я заканчиваю следующими полями в моем бизнес-объекте (UserId, UserName, CityName, StateName, CountryName, OrdersCount), и класс может быть вызван, например, UserWithOrderCount

Подумал в некоторых вариантах:

  1. Сделайте эти два бизнес-класса и заполните их отдельно в каждом методе DAL (эти объекты просты, но учтите, что этот метод может иметь сложный запрос выбора, который необходимо инкапсулировать для повторного использования, поэтому шаблон репозитория здесь не подходит, по крайней мере, я думаю, что ).
  2. Создайте только один объект User со всеми свойствами (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) и заполните только подмножество в каждом методе DAL, но это подразумевает семантическую связь, когда вы используете метод, потому что вы должны знать, какое подмножество полей заполняется из базы данных, а семантическая связь худшее из всех сцеплений.
  3. Вариант 1 не подходит, если мне понадобится другое представление, свойства как List<Order>, так и OrdersCount.
  4. Теперь подумайте, что если вы используете ASP.NET MVC, хорошие практики говорят, что вам нужна ViewModel для перехода к представлению, я думал вернуть ViewModels из моего уровня Businnes, но я не думаю, что это хорошая идея, похоже, что я что-то нарушает, а также невозможно, потому что мой бизнес-уровень находится в другой сборке, а не в веб-приложении.
  5. Я не хочу писать один и тот же запрос Linq снова и снова, но если использовать NHibernate или EFCodeFirst, это «похоже» на первый вариант, и мне нужно будет создать множество объектов малого бизнеса.

Как вы справляетесь с этой ситуацией? Я считаю, что это дизайнерское решение высокого уровня.


.net domain-driven-design class-design business-logic business-logic-layer
person k-dev    schedule 18.05.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Прежде всего, я определенно согласен с вами в некоторых вещах, которых нельзя делать:

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

  2. Не возвращайте ViewModels из вашего бизнес-уровня; ваш бизнес-уровень должен представлять бизнес-концепции домена вашего приложения, а ViewModel - это объект данных, который содержит данные, необходимые для отображения определенного представления одной части этого домена - это очень разные вещи, и бизнес-уровень должен совершенно не осознавать, что его бизнес-объекты используются в любом графическом интерфейсе.

Я бы согласился с вашим первым предложением - создайте один отдельный бизнес-объект для представления каждой бизнес-концепции. Затем я бы использовал ORM (например, EF или NHibernate) для заполнения этих объектов за меня с выделенными репозиториями для каждой группы объектов. Затем я бы использовал уровень приложения, который вызывает репозитории для возврата любых требуемых объектов. с этой целью ваш репозиторий может включать методы, которые возвращают объединенных пользователей и заказы, когда вы знаете, что вам нужно использовать эти два типа вместе. Это позволяет вам возвращать пользователя со всеми его заказами в одном запросе, сохраняя при этом отдельные значимые сущности для представления пользователей и заказов.

person Steve Wilkes    schedule 02.06.2011
comment
спасибо за ваш комментарий, я голосую за то, чтобы поделиться, первое предложение также имеет проблему, заключающуюся в том, что мы можем закончить с большим количеством бизнес-объектов, в конечном итоге разработчики могут столкнуться с проблемой, что они не знают, какой объект является правильным для того, что они хотят , или на самом деле давая имена собственные, хоть что-нибудь об этом? - person k-dev; 09.06.2011
comment
Спасибо за голосование :) Модель предметной области должна быть чем-то, что разработчики обсуждают каждый день, и если кто-то не знает, какой объект использовать для чего или как назвать конкретный объект, они должны иметь возможность обсудить это с другими разработчиками. в том же проекте или с экспертами в предметной области. Модель предметной области, которую вы пишете в коде, является отражением концептуальной модели, с которой вы все должны работать, и чем больше, чем модель обсуждается и понимается, тем лучше будет код :) - person Steve Wilkes; 09.06.2011
comment
Еще раз спасибо, я согласен с вами, я отмечу это как ответ, поскольку вы говорите, что обсуждение является частью разработки программного обеспечения - person k-dev; 09.06.2011