Анемичная модель предметной области - это использование модели предметной области программного обеспечения, в которой объекты предметной области содержат мало или совсем не содержат бизнес-логики (проверки, вычисления, бизнес-правила и т. Д.).
Обзор
Эта модель была впервые описана [1] с помощью Мартина Фаулера , который считает практиковать анти-модель . Он говорит:
Фундаментальный ужас этого антипаттерна состоит в том, что он настолько противоречит основной идее объектно-ориентированного проектирования; который заключается в объединении данных и их совместной обработке. Модель анемичной предметной области - это просто дизайн в процедурном стиле, именно то, с чем возражают фанатики вроде меня ... с которыми борются с первых дней существования Smalltalk . Что еще хуже, многие люди думают, что анемичные объекты являются реальными объектами, и поэтому совершенно не понимают, что такое объектно-ориентированный дизайн.
В анемичном дизайне предметной области бизнес-логика обычно реализуется в отдельных классах, которые преобразуют состояние объектов предметной области. Фаулер называет такие внешние классы транзакционными скриптами . Эта модель представляет собой общий подход в Java - приложениях, возможно , воодушевлены технологиями , такие , как ранние версии EJB «s Entity Beans , [1] , а также в .NET приложениях после архитектуры трехслойных услуг приложений , где такие объекты попадают в категорию «Бизнес-сущности» (хотя бизнес-сущности также могут содержать поведение). [2]
Фаулер описывает шаблон сценария транзакции следующим образом:
Большинство бизнес-приложений можно рассматривать как серию транзакций. Транзакция может рассматривать некоторую информацию как организованную определенным образом, другая вносит в нее изменения. Каждое взаимодействие между клиентской системой и серверной системой содержит определенную логику. В некоторых случаях это может быть просто отображение информации в базе данных. В других случаях это может включать в себя множество этапов проверки и расчетов. Сценарий транзакции организует всю эту логику в основном как одну процедуру, выполняющую вызовы непосредственно в базу данных или через тонкую оболочку базы данных. Каждая транзакция будет иметь свой собственный сценарий транзакции, хотя общие подзадачи могут быть разбиты на подпроцедуры. [3]
В своей книге «Шаблоны архитектуры корпоративных приложений» Фаулер отметил, что шаблон сценария транзакции подходит для многих простых бизнес-приложений и позволяет избежать сложного слоя отображения объектно-ориентированной базы данных.
Причины, по которым это может произойти
AnemicDomainModel может возникать в системах, на которые влияют сервис-ориентированные архитектуры, где поведение не передается или имеет тенденцию не перемещаться.
- Архитектура обмена сообщениями / конвейера
- API, такие как SOAP / REST
Такие архитектуры, как COM + и Remoting, допускают поведение, но Интернет все чаще предпочитает отключенные архитектуры и архитектуры без сохранения состояния.
Критика
Существует некоторая критика относительно того, следует ли считать этот шаблон разработки программного обеспечения анти-шаблоном, поскольку многие видят в нем также преимущества, например:
- Четкое разделение логики и данных. [4]
- Хорошо работает для простых приложений.
- Приводит к логике без сохранения состояния, что облегчает горизонтальное масштабирование.
- Избегает необходимости в сложном слое отображения объектно-ориентированной базы данных.
- Большая совместимость с каркасами сопоставления и внедрения, ожидающими «глупых» свойств, а не конкретного конструктора или порядка заполнения свойств. [4]
Пассивы
- Логика не может быть реализована действительно объектно-ориентированным способом.
- Нарушение принципов инкапсуляции и сокрытия информации .
- Требуется отдельный бизнес-уровень для хранения логики, которая в противном случае находится в модели предметной области . Это также означает, что объекты модели предметной области не могут гарантировать их правильность в любой момент, потому что их логика проверки и изменения находится где-то снаружи (скорее всего, в нескольких местах).
- Требуется уровень обслуживания при совместном использовании логики домена между разными потребителями объектной модели.
- Делает модель менее выразительной.
Пример
Анемичный
class Box { public int Height { получить ; набор ; } public int Width { получить ; набор ; } }
Без анемии
class Box { public int Height { получить ; } public int Width { получить ; } общественный Box ( ИНТ высота , ИНТ ширина ) { если ( высота <= 0 ) { бросить новый ArgumentOutOfRangeException ( nameof ( высота )); } if ( width <= 0 ) { выбросить новое исключение ArgumentOutOfRangeException ( nameof ( width )); } Высота = высота ; Ширина = ширина ; } public int Area () { return Высота * Ширина ; } }
Смотрите также
- Обычный старый объект Java
- Домен-ориентированный дизайн
- Информационный эксперт GRASP , модель анемичной предметной области является типичным результатом неприменения принципа информационного эксперта, то есть вы можете избежать анемичной модели предметной области, пытаясь распределить обязанности между теми же классами, которые содержат данные
Рекомендации
- ^ а б http://www.martinfowler.com/bliki/AnemicDomainModel.html
- ^ "Архивная копия" . Архивировано из оригинала на 2013-01-10 . Проверено 13 февраля 2013 .CS1 maint: заархивированная копия как заголовок ( ссылка )
- ^ https://www.martinfowler.com/eaaCatalog/transactionScript.html
- ^ а б http://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/