Вопрос о доменных объектах, сервисном уровне и использовании Linq2SQL и ASP.net MVC с шаблоном репозитория - PullRequest
1 голос
/ 05 января 2011

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

Мы находимся в фазе исследований и разработок нового сайта ASP.net MVC2 и хотим, чтобы мы могли 1) отделить наше хранилище данных от нашего приложения, 2) разрешить тестирование нашего приложения с помощью модульных тестов и3) позволяют нам изменить наше хранилище данных или использовать что-то другое, кроме Linq2SQL, по линии.

Эта, казалось бы, простая цель открыла для меня целый новый мир, который включает в себя шаблон Repository, IoC, DI и всевиды других вещей, которые заставляют мою голову плавать.Вот что находится в центре внимания, или, по крайней мере, то, что я считаю несколько правильным планом для достижения наших целей:

  1. У нас будет несколько ISpecificRepository интерфейсы, которые определяют контракт между пользователями интерфейса и базовым хранилищем данных.

  2. Реализации SpecificRepository будут запрашивать конкретные хранилища данных и возвращать POCO, представляющий объекты нашего домена (илиих коллекции).

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

Как уже упоминалось, мы планируем использовать Linq2SQL для реализации наших конкретных репозиториев для приложения и решили отделить наш уровень обслуживания от этой реализации, создав POCOдля наших доменных объектов и создать отображение наи из этих объектов в объекты, созданные LINQ.На уровне сервиса мы можем затем создать бизнес-логику для запроса к хранилищу, добавить данные и делать все остальное, что нам нужно сделать для каждого варианта использования.Это выглядит нормально, но меня беспокоит то, что, поскольку мы используем Linq2SQL, наша конкретная реализация репозитория Linq теперь должна будет содержать все многие запросы Get , которые требуются сервисному уровню для эффективной реализации бизнес-логики.

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

Причина, по которой я чувствую, что нам нужно сделать это таким образом, заключается в том, что я могу писать более эффективные запросы Linq в моем конкретном репозитории Linq, используя различные DataLoadOptions и т. Д., Не возвращая IQueryable из моего репозитория на мой уровень обслуживаниягде, казалось бы, такая логика на самом деле принадлежит.Кроме того, все примеры интерфейсов IRepository, которые я видел, кажутся очень легковесными и предоставляют лишь несколько методов для GetByID, GetAll, Find, Insert, Delete и SubmitChanges в базовое хранилище данных.В моем случае, похоже, что мои конкретные репозитории будут делать гораздо больше.

Спасибо за чтение этого места.Любая помощь, которая может прояснить мои заблуждения, будет принята с благодарностью.

-Mustafa

1 Ответ

2 голосов
/ 05 января 2011

наша конкретная реализация репозитория Linq теперь должна будет содержать все многие запросы Get, которые требуются сервисному уровню для эффективной реализации бизнес-логики.

Мне интересно, не нарушит ли это каким-либо образомШаблон репозитория

Совсем нет.Репозиторий - это коллекция сущностей домена.Если у меня Repository Accounts, вполне разумно хотеть Accounts.ThatAreOverdue().

. Я лично предпочитаю свободное именование.Accounts.ThatAreOverdue() чувствует себя лучше, чем AccountRepository.GetOverdue() .. но я полагаю, что это предпочтение.

Кроме того, все примеры интерфейсов IRepository, которые я видел, кажутся очень легковесными и предоставляют лишь несколькометоды GetByID, GetAll, Find, Insert, Delete и SubmitChanges в базовое хранилище данных.

Интерфейс репозитория может быть тонким.Find предназначен для использования с шаблоном спецификации.Инкапсулируйте критерии в другом объекте.Реализация критериев может быть передана объектам Linq2Sql для запроса, но будет труднее повторно использовать классы критериев для объектов домена в памяти (по сравнению с базой данных, в которой участвует Linq2Sql).

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

Вы говорите, чтовся ваша логика будет в Службах, а «доменные объекты» будут мешками свойств и привязаны к представлению?

Не думаю, что я бы рекомендовал это.

Если тот же объект, который используется в логике приложения, также используется в представлении, то вы тесно связали два уровня приложения, и опыт показывает, что это вызывает проблемы.Будет очень трудно поддерживать согласованность в Сервисах и Домене посредством изменений, если представление использует одни и те же объекты.Представлению потребуются фрагменты данных, и они неизбежно застрянут в тех местах, которым они на самом деле не принадлежат.

...