Образец репозитория против "умных" бизнес-объектов

Я вижу две основные "школы мыслей", когда речь идет о создании более масштабных корпоративных приложений на .NET(Winforms, WPF, ASP.NET).

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

В другом лагере используется то, что я называю "умными" бизнес-объектами, которые знают, как загружать себя, и обычно они имеют метод Save(), возможно Update() или даже Delete(). Здесь вам действительно не нужен репозиторий - сами объекты знают, как загружать и сохранять себя.

Большой вопрос: что вы используете или предпочитаете? И почему?

Используете ли вы один и тот же подход во всех своих приложениях, или у вас есть какие-то особые критерии, когда нужно выбирать один подход по сравнению с другим? Если да - каковы эти критерии?

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

Спасибо за любой конструктивный ввод!

Ответ 1

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

Ответ 2

Шаблон репозитория не обязательно приводит к немым объектам. Если объекты не имеют логики вне Save/Update, вы, вероятно, слишком много делаете вне объекта.

Idealy, вы никогда не должны использовать свойства для получения данных с вашего объекта, вычисления вещей и возврата данных обратно в объект. Это разрыв инкапсуляции.

Таким образом, объекты не должны быть анемичными, за исключением случаев, когда вы используете простые объекты DTO с операциями CRUD.

Тогда разделение проблем с сохранением проблем вашего объекта - хороший способ иметь единую ответственность.

Ответ 3

Вот две интересные статьи, которые я встретил

Repository-is-the-new-singleton

DAL должен пройти весь путь до пользовательского интерфейса

Ответ 4

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

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

Помимо тестирования также было бы намного сложнее заменить технологии доступа к данным, например, от Linq-to-SQL до NHibernate или EntityFramework (хотя это часто случается не часто).

Ответ 5

Это действительно зависит от потребностей приложения, но при работе со сложной бизнес-моделью я предпочитаю ActiveRecord. Я могу инкапсулировать (и проверить) бизнес-логику в одном месте.

Большинство ORM (EF, nHibernate и т.д.) служат в качестве вашего репозитория. Многие люди считают слой поверх ORM, который инкапсулирует все взаимодействие данных как репозиторий, который, как я считаю, неверен. По словам Мартина Фаулера, репозиторий инкапсулирует доступ к данным в виде коллекции. Поэтому, имея индивидуальные методы для всех извлечения/мутации данных, можно использовать Data Mapper или Object Access Object.

Используя ActiveRecord, мне нравится иметь базовый класс "Entity". Обычно я использую ORM (репозиторий) с этим базовым классом, поэтому все мои объекты имеют методы GetById, AsQueryable, Save и Delete.

Если я использую больше сервис-ориентированной архитектуры, я буду использовать репозиторий (тот, который маскирует прямой доступ к данным или ORM) и вызывает его непосредственно в моих службах.