Почему я должен изолировать свои доменные объекты от моего уровня представления?

вы пропустили <router-outlet> </router-outlet>. Пожалуйста, добавьте приведенный ниже код после навигации в html-файл app.component.

<router-outlet> </router-outlet>
83
задан Mark Rogers 31 May 2009 в 15:00
поделиться

11 ответов

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

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

это означает, что вы должны реализовать свои доменные объекты в двух местах; ваш уровень интерфейса и в вашем уровне BO. Но это переопределение, хотя на первый взгляд это может показаться дополнительной работой, помогает навязать разделение, которое сэкономит ТОННЫ работы в какой-то момент в будущем.

это означает, что вы должны реализовать свои доменные объекты в двух местах; ваш уровень интерфейса и в вашем уровне BO. Но это переопределение, хотя на первый взгляд это может показаться дополнительной работой, помогает навязать разделение, которое сэкономит ТОННЫ работы в какой-то момент в будущем.

46
ответ дан 24 November 2019 в 08:55
поделиться

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

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

-1
ответ дан 24 November 2019 в 08:55
поделиться

See also the section "Data propagation between layers" in the following, which I think presents compelling arguments:

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

1
ответ дан 24 November 2019 в 08:55
поделиться

Черт возьми, я клянусь , это говорит о настойчивости.

В любом случае, это еще один пример того же: закон Парнаса говорит, что модуль должен хранить секрет, а секрет - это требование, которое может измениться. (У Боба Мартина есть правило, которое является еще одной версией этого.) В такой системе презентация может изменяться независимо от домена . Например, компания, которая поддерживает цены в евро и использует французский язык в офисах компании, но хочет представить цены в долларах с текстом на китайском языке. Домен является таким же; презентация может измениться. Таким образом, чтобы минимизировать хрупкость системы, то есть количество вещей, которые необходимо изменить для реализации изменения требований, вы разделяете проблемы.

3
ответ дан 24 November 2019 в 08:55
поделиться

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

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

1
ответ дан 24 November 2019 в 08:55
поделиться

Мы используем одну и ту же модель на сервере и в интерфейсе пользователя. , И это боль. Мы должны когда-нибудь провести его рефакторинг.

Проблемы главным образом связаны с тем, что модель предметной области нужно разрезать на более мелкие части, чтобы можно было сериализовать ее без ссылки на всю базу данных. Это усложняет использование на сервере. Важные ссылки отсутствуют. Некоторые типы также не сериализуемы и не могут быть отправлены клиенту. Например, «Тип» или любой универсальный класс. Они должны быть не универсальными, а Type должен быть передан в виде строки. Это создает дополнительные свойства для сериализации, они избыточны и сбивают с толку.

Другая проблема заключается в том, что сущности в пользовательском интерфейсе не подходят. Мы используем привязку данных, и многие объекты имеют множество избыточных свойств только для целей пользовательского интерфейса. Кроме того, в модели сущностей есть много «BrowsableAttribute» и других. Это действительно плохо.

В конце концов, я думаю, что вопрос в том, какой путь проще. Могут быть проекты, в которых он просто отлично работает и в которых нет необходимости писать другую модель DTO.

4
ответ дан 24 November 2019 в 08:55
поделиться

Вы делаете это по той же причине, по которой вы не допускаете SQL на своих страницах ASP / JSP.

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

Вы хотите повторно использовать этот изящный виджет пользовательского интерфейса в другом приложении? Ну, вам нужно создать базу данных с этим именем, этими двумя схемами и этими 18 таблицами. Вы также должны настроить Hibernate и Spring (или выбранные вами фреймворки) для проведения бизнес-валидации. Ой,

16
ответ дан 24 November 2019 в 08:55
поделиться

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

Моя система бухгалтерского учета имеет структуру и содержание (и данные), которые должны моделировать работу моей компании. Эта структура реальна и существует независимо от того, какое бухгалтерское программное обеспечение я использую. (Неизбежно, что данный программный пакет содержит структуру и контент сам по себе, но частью проблемы является минимизация этих накладных расходов.)

По сути, у человека есть работа. DDD должен соответствовать потоку и содержанию работы. DDD - это предоставление полной информации обо всех работах, которые необходимо выполнить полностью и независимо, насколько это возможно. Тогда, надеюсь, пользовательский интерфейс облегчает выполнение работы максимально прозрачно и максимально продуктивно.

Интерфейсы - это входы и представления, предоставленные для правильно смоделированного и инвариантного функционального ядра.

3
ответ дан 24 November 2019 в 08:55
поделиться

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

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

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

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

Идея, что кто-то поставит проверку в своем бизнес-объекте? Ну, я говорю, что это хорошо. Ваш пользовательский интерфейс не должен нести единоличную ответственность за проверку ваших бизнес-объектов. Ваш бизнес-уровень ДОЛЖЕН выполнить собственную проверку.

Почему вы помещаете код генерации пользовательского интерфейса в объект busienss? В моем случае у меня есть отдельные объекты, которые генерируют код UI отдельно от UI. У меня есть отдельные объекты, которые делают мои бизнес-объекты в Xml, Как я думаю, немного больше, есть случаи, когда информация пользовательского интерфейса может принадлежать на уровне домена. И это может омрачить то, что вы называете доменным слоем, но я работал над мультитенантным приложением, у которого было совершенно другое поведение, как внешний вид и поведение пользовательского интерфейса, так и функциональный рабочий процесс. В зависимости от различных факторов. В этом случае у нас была модель предметной области, которая представляла арендаторов и их конфигурацию. Их конфигурация включала информацию пользовательского интерфейса (например, метки для общих полей).

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

19
ответ дан 24 November 2019 в 08:55
поделиться

Я не согласен.

Я думаю, что лучше всего начать с объектов предметной области на уровне представления, ДО ТОГО, КОГДА ОНА ПОЛУЧИТ СМЫСЛ ДЕЛАТЬ ИНОЕ.

Вопреки распространенному мнению " "Объекты домена" и "Объекты-значения" могут успешно сосуществовать на уровне представления. И это лучший способ сделать это - вы получаете преимущества обоих миров, уменьшая дублирование (и шаблонный код) с объектами домена; а также адаптация и концептуальное упрощение использования объектов значений в запросах.

13
ответ дан 24 November 2019 в 08:55
поделиться

Ваша презентация может ссылаться на уровень вашего домена, но не должно быть прямой привязки вашего пользовательского интерфейса к вашим объектам домена. Объекты домена не предназначены для использования пользовательского интерфейса, поскольку при правильном проектировании они часто основаны на поведении, а не на представлениях данных. Между пользовательским интерфейсом и доменом должен быть слой сопоставления. MVVM или MVP - хороший образец для этого. Если вы попытаетесь напрямую привязать свой пользовательский интерфейс к домену, вы, вероятно, создадите себе много головной боли. У них две разные цели.

2
ответ дан 24 November 2019 в 08:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: