Образцовый шаблон против «умных» бизнес-объектов

Question

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

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Repository-is-the-new-singleton

The DAL should go all the way to UI

Answer 5

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

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

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

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