Почему я должен изолировать свои доменные объекты от уровня презентации? - PullRequest
84 голосов
/ 04 мая 2009

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

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

Так что я ищу несколько конкретных причин, которые я могу использовать, чтобы подтвердить это. В частности:

  1. Почему мы не должны использовать доменные объекты в нашем уровне представления?
    (если ответ очевиден, «разъединение», то, пожалуйста, объясните, почему это важно в этом контексте)
  2. Должны ли мы использовать дополнительные объекты или конструкции для изоляции наших доменных объектов от интерфейса?

Ответы [ 14 ]

1 голос
/ 02 июля 2012

С помощью такого инструмента, как ' Value Injecter ' и концепции 'Mappers' в уровне представления при работе с представлениями, гораздо проще понять каждый фрагмент кода. Если у вас есть немного кода, вы не сразу увидите преимущества, но когда ваш проект будет расти все больше и больше, вы будете очень счастливы, работая с представлениями, чтобы не вводить логику сервисов, хранилища, чтобы понять модель представления. View Model - еще один защитник в огромном мире антикоррупционного слоя, который на долгое время стоит на вес золота.

Единственная причина, по которой я не вижу преимуществ в использовании модели представления, заключается в том, что ваш проект небольшой и достаточно простой, чтобы представления были привязаны непосредственно к каждому свойству вашей модели. Но если в будущем изменение требований и некоторые элементы управления в представлениях не будут привязаны к модели, и у вас нет концепции модели представления, вы начнете добавлять исправления во многих местах и ​​у вас будет устаревший код, который ты не оценишь. Конечно, вы можете провести некоторый рефакторинг, чтобы преобразовать вашу модель представления в view-viewmodel и следовать принципу YAGNI, не добавляя код, если он вам не нужен, но для себя, это гораздо более эффективная практика, которой я должен следовать для добавления слой представления, представляющий только объекты модели представления.

1 голос
/ 05 мая 2009

См. Также раздел «Распространение данных между слоями» в следующем, который, я думаю, представляет убедительные аргументы:

http://galaxy.andromda.org/docs/andromda-documentation/andromda-getting-started-java/java/index.html

1 голос
/ 04 мая 2009

Возможно, вы не понимаете уровень пользовательского интерфейса в достаточно широком смысле. Подумайте о множественных формах ответа (веб-страницы, голосовой ответ, печатные буквы и т. Д.) И о нескольких языках (английский, французский и т. Д.).

Теперь предположим, что речевой механизм для системы телефонного вызова работает на компьютере совершенно другого типа (например, Mac) с компьютера, на котором работает веб-сайт (возможно, Windows).

Конечно, легко попасть в ловушку «Ну, в моей компании мы заботимся только об английском языке, запускаем наш сайт на LAMP (Linux, Apache, MySQL и PHP), и все используют одну и ту же версию Firefox». Но что будет через 5 или 10 лет?

0 голосов
/ 04 мая 2009

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

Проекты, управляемые доменом, лучше всего работают при использовании в сочетании с ортогональным набором структур функциональных доменов (таких как ORM, GUI, Workflow и т. Д.). Всегда помните, что только в смежности внешнего уровня семантика домена должна быть представлена. Обычно это внешний интерфейс (GUI) и постоянный внутренний интерфейс (RDBM, ORM). Любые эффективно разработанные промежуточные слои могут и должны быть инвариантными в отношении домена.

...