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

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

1 голос
/ 18 мая 2011

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

Случай 1

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

Дело 2

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

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

  1. Makeчто два бизнес-класса и заполняют их отдельно в каждом методе DAL (эти объекты просты, но учтите, что метод может иметь сложный запрос на выборку, который необходимо инкапсулировать для повторного использования, поэтому шаблон репозитория здесь не очень подходит, по крайней мере, я так думаю).
  2. Создать толькоy один объект 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, это "похоже навариант один, и мне нужно будет создать тонны объектов малого бизнеса.

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

1 Ответ

2 голосов
/ 02 июня 2011

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

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

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

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

...