Должен ли доменный уровень в 3-уровневой архитектуре приложения переносить классы данных, необходимые для уровня пользовательского интерфейса?

Question

Предполагая, что «стандартное» 3-уровневое приложение (UI - Domain - Data), должно Domain Layer показывать классам UI, первоначально определенным в Data Layer?

Я имею в виду, предполагая, что в Data Layer определен класс Product, не правильно ли, чтобы какой-то метод из моего Domain Layer имел методы, возвращающие его (то есть, делая их видимыми для пользовательского интерфейса)? Или я должен определить в самом Domain Layer некоторый класс, который переносит Product из Data Layer, поэтому пользовательский интерфейс теперь не зависит от Data Layer?

Спасибо

Answer 1

У вас обычно есть интерфейс Product и ProductImpl. Пользовательский интерфейс знает только интерфейс и отлично отделен от уровня данных (который использует класс реализации).

Answer 2

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

Answer 3

Является ли класс домена Продуктом? Как вы получаете класс продукта на уровне пользовательского интерфейса? Вы действительно имеете в виду 3-х уровневый? Уровень - это физическая граница, поэтому 3-уровень означает, что UI / BL / DB - это три разных процесса.

Если вы используете Product в качестве класса домена (= данные + логика), вам не следует делиться им с пользовательским интерфейсом, а вместо этого следует создать новый объект передачи данных (DTO). DTO передает только необходимую информацию между двумя уровнями.

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

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

Answer 4

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

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

Answer 5

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

Если у вас почти нет логики в доменном слое или нет, то в 90% всех случаев в этом нет необходимости.использовать разные объекты, определенные на уровне данных.

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

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

Answer 6

Это зависит от вашей архитектуры. Например, если вы используете шаблон MVVM (Model-View-ViewModel), вы должны определить классы модели пользовательского интерфейса в середине.