Модель анемической области - Anemic domain model

Модель анемической области использование программного обеспечения модель предметной области где объекты домена содержат мало или совсем не бизнес-логика (проверки, расчеты, бизнес-правила и т. д.).

Обзор

Этот паттерн был впервые описан[1] к Мартин Фаулер, который считает эту практику антипаттерн. Он говорит:

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

В анемичном дизайне предметной области бизнес-логика обычно реализуется в отдельных классах, которые преобразуют состояние объектов предметной области. Фаулер называет такие внешние классы скрипты транзакций. Этот шаблон является распространенным подходом в Ява приложения, возможно, поощряемые такими технологиями, как ранние версии EJB с Entity Beans,[1] а также в .СЕТЬ приложения, следующие за архитектурой приложений трехуровневых служб, где такие объекты попадают в категорию «бизнес-сущностей» (хотя бизнес-сущности также могут содержать поведение).[2]

Фаулер описывает шаблон сценария транзакции следующим образом:

Большинство бизнес-приложений можно рассматривать как серию транзакций. Транзакция может рассматривать некоторую информацию как организованную определенным образом, другая вносит в нее изменения. Каждое взаимодействие между клиентской системой и серверной системой содержит определенную логику. В некоторых случаях это может быть просто отображение информации в базе данных. В других случаях это может включать в себя множество этапов проверки и расчетов. Сценарий транзакции организует всю эту логику в основном как единую процедуру, выполняющую вызовы непосредственно в базу данных или через тонкую оболочку базы данных. Каждая транзакция будет иметь свой собственный сценарий транзакции, хотя общие подзадачи могут быть разбиты на подпроцедуры.[3]

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

Причины, почему это может произойти

AnemicDomainModel может возникать в системах, на которые влияют сервис-ориентированные архитектуры, где поведение не изменяется или имеет тенденцию не перемещаться.

  • Архитектура обмена сообщениями / конвейера
  • API, такие как SOAP / REST

Такие архитектуры, как COM + и Remoting, допускают поведение, но Интернет все чаще предпочитает автономные архитектуры и архитектуры без сохранения состояния.

Критика

Существует некоторая критика относительно того, следует ли считать этот шаблон разработки программного обеспечения анти-шаблоном, поскольку многие видят в нем также преимущества, например:

  • Четкое разделение логики и данных.[4]
  • Хорошо работает для простых приложений.
  • Приводит к логике без сохранения состояния, что облегчает горизонтальное масштабирование.
  • Избегает необходимости в сложном слое отображения объектно-ориентированной базы данных.
  • Большая совместимость с каркасами сопоставления и внедрения, ожидающими «глупых» свойств, а не конкретного конструктора или порядка заполнения свойств. [4]

Пассивы

  • Логику нельзя реализовать действительно объектно-ориентированным способом.
  • Нарушение инкапсуляция и скрытие информации принципы.
  • Требуется отдельный бизнес-уровень для хранения логики, которая в противном случае находится в модель предметной области. Это также означает, что модель предметной области объекты не могут гарантировать их правильность в любой момент, потому что их логика проверки и мутации размещена где-то снаружи (скорее всего, в нескольких местах).
  • Требуется уровень обслуживания при совместном использовании логики домена между разными потребителями объектной модели.
  • Делает модель менее выразительной.

Пример

Анемичный

учебный класс Коробка{    общественный int Высота { получать; набор; }    общественный int Ширина { получать; набор; }}

Без анемии

учебный класс Коробка{    общественный int Высота { получать; }    общественный int Ширина { получать; }    общественный Коробка(int высота, int ширина)    {        если (высота <= 0) {            бросать новый ArgumentOutOfRangeException(Имя(высота));        }        если (ширина <= 0) {            бросать новый ArgumentOutOfRangeException(Имя(ширина));        }        Высота = высота;        Ширина = ширина;    }    общественный int Площадь()    {        возвращаться Высота * Ширина;    }}

Смотрите также

Рекомендации

  1. ^ а б http://www.martinfowler.com/bliki/AnemicDomainModel.html
  2. ^ «Архивная копия». Архивировано из оригинал на 2013-01-10. Получено 2013-02-13.CS1 maint: заархивированная копия как заголовок (связь)
  3. ^ https://www.martinfowler.com/eaaCatalog/transactionScript.html
  4. ^ а б http://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/

внешняя ссылка