Является ли Value Object плохим образцом? - PullRequest
1 голос
/ 31 июля 2009

Является ли использование VO (POCO) плохим дизайном? Некоторые люди говорят, что вся логика предметной области объекта должна быть вместе в этом объекте.

Пример: ProductVO: Id, Name, Description

ProductBO: SearchById (int id), Вставка (ProductVO newProduct), Обновление (ProductVO обновленный Product, SearchByKeyword (строковое слово) ......

Ответы [ 6 ]

8 голосов
/ 31 июля 2009

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

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

Один из способов взглянуть на это состоит в том, что службы должны быть разделены на три набора,

  • Инфраструктурные услуги. те, которые относятся к общим техническим аспектам (например, общий доступ к базе данных, кэширование, ведение журнала, настройка, обмен сообщениями и т. д.)

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

  • Доменные службы. Услуги, которые явно связаны с бизнес-моделью. (например, создание резервирования для места авиакомпании на конкретном рейсе с конкретными запросами на питание и назначением места, а также соответствующие транзакционные дебеты по указанной кредитной карте ...)

    Последний тип "службы" должен быть на уровне домена, первые два - не ...

5 голосов
/ 08 августа 2009

Является ли использование ВО (POCO) плохим дизайном шаблон? Некоторые люди говорят, что все доменная логика объекта должна быть вместе в этом объекте.

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

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

POCO / POJO также не является подходящим выражением, поскольку оно также не означает отсутствие логики, только то, что не требуется никакого конкретного суперкласса, интерфейса или улучшения байт-кода.

Что касается вашего вопроса: иметь модель предметной области в классах без логики по любой другой причине, кроме как видеть, как другие люди делают это таким образом, и иметь имя для нее действительно очень плохой дизайн - это анти-паттерн, известный как модель анемичного домена . К сожалению, был ряд плохо спроектированных фреймворков (сейчас вообще заброшенных), которые требовали и продвигали этот «шаблон».

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

При этом, безусловно, неверно, что «вся логика домена объекта должна быть вместе в этом объекте» - иногда есть веские причины извлечь некоторую логики домена и сохранить ее в отдельные классы:

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

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

3 голосов
/ 31 июля 2009

Использование VO позволяет отделить состояние от поведения, которое звучит несовместимо с ООП, но вполне может быть целесообразным, когда различные аспекты приложения рассматривают состояние с учетом своих собственных целей.

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

2 голосов
/ 08 августа 2009

Ценность объектов велика!

Почему в мире вы захотите продолжать вызывать «IsValidName (myString)» повсеместно, когда вы можете просто инкапсулировать правила того, что делает имя в классе Name, и затем компилятор должен убедиться, что не проверенное имя никогда не будет передано?

1 голос
/ 31 июля 2009

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

1 голос
/ 31 июля 2009

Я думаю, что они являются хорошим шаблоном для определенных сред (например, сервис-ориентированных приложений).

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

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

...