Понимание DTO и Анемичной Модели Домена - PullRequest
2 голосов
/ 21 июня 2011

Я новичок в доменном шаблоне, мне нужно убедиться, что я понимаю то, что прочитал до сих пор !!, Пожалуйста, скажите мне, являются ли следующие предложения верными или не нарушают принцип, связанный с DDD

enter image description here

0) DAL получит параметры в DTO и вернет извлеченные данные в LIST of DTO (Entity)

1) Разделит BLL и DAL через репозиторийpattern.

2) Объект является объектом DTO.

3) ProductCategoryData содержит список ProductData.

4) Это будет ANTI-модель модели предметной области, если BLL.ProductCategory.не содержит свойств, которые описывают бизнес-объект.

5) BLL.ProductCategory содержит список BLL.Product …… У меня плохое предчувствие по этому поводу

6) Я избегаю в этом проекте анемичногоАнти-шаблон модели домена.

7) Я успешно применил шаблон модели домена.

8) Я использовал объекты DTO для передачи данных между уровнями.

Пожалуйста, поговорите со мной :)

Ответы [ 2 ]

3 голосов
/ 21 июня 2011

Почему у тебя плохое предчувствие?Анемия звучит как плохое слово, но какой вред вы обнаружили?

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

Если по другим причинам вы решили переместить это поведение в другое место (например, в службы), есть аргумент, что вы выбираете архитектуру, которая более функциональна, чем объектно-ориентированная.Это действительно так плохо?

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

Лучший вопрос: «Есть ли у меня параллельные модели? Одна для DTO, а другая для бизнес-уровня?»Если да, я бы сказал, что двойное обслуживание гораздо более опасно, чем анемия.

0 голосов
/ 21 июня 2011

Если это интерфейс и нет методов для ваших объектов, то это все еще анемичная модель.

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

Также выберите более подходящие имена для вашей модели и избегайте общих имен, таких как «Данные». Читатель сразу спрашивает: что это за данные?

...