Валидация и в уровне сервиса или бизнес-объектах?

Question

Мартин Фаулер предлагает использовать уровень обслуживания в качестве границы между моделью предметной области и «Загрузчиками данных». Однако Rockford Lhotka предлагает встроить проверку в сам бизнес-объект, и это именно то, что делает CSLA.NET.

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

Answer 1

Я не уверен, что вы поняли это.

Мартин Фаулер предлагает в PEAA сервисный уровень API между уровнями пользовательского интерфейса (или клиентов) и доменом / данными он предоставит любую функциональность, которую может использовать клиент.

Если вы посмотрите на модель домена ( Здесь )

Объектная модель домена, которая включает в себя как поведение, так и данные.

Уровень домена будет содержать эти объекты, которые будут иметь действия / проверки (Поведение) и состояние (Данные)

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

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

Посмотрите на макет острой арки (http://www.sharparchitecture.net/)

Это мое понимание этого материала.

НТН

кости

Answer 2

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

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

Answer 3

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

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

Я заметил, что идеал, согласно которому модель предметной области «должна» состоять из доменных объектов, которые представляют собой сочетание данных и поведения, - это концепция Фаулера / Эванса, примерно 2000-2002 гг. распределенные информационные системы вместо 2-х уровневых приложений.)

Мысли