Как наилучшим образом представлять представления базы данных/итоговую информацию в приложении «3-ярусное»

Question

Это в основном задает тот же вопрос, что и в How to handle views in a multilayer-application. Однако этот пост не получил большой обратной связи.

Вот проблема: мы построили 3-уровневой веб-приложение со следующими уровнями:

-DATA доступа (с использованием репозиториев)
-Service
-ui (MVC 3)

DTO передаются между уровнем пользовательского интерфейса (Controller) и уровнем обслуживания. Более мощные модели доменов, содержащие много логики уровня домена, передаются между службами и слоями доступа к данным. Все отключено с помощью IOC, и приложение следует принципам SOLID (или пытается тоже) - большой счастливой развязанной семьи!

В настоящее время преобразование DTO-> Domain Model и Domain Model-> DTO происходит на сервисном уровне.

Итак, наконец, на мой вопрос:

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

Может ли кто-нибудь указать мне правильное направление?

Большое спасибо!

Answer 1

Ваша мысль о разбиении слоев на чтение, а затем отображение значений имеет смысл полностью. В конце концов, архитектура/дизайн системы должны помочь вам, а не наоборот.

Отображение данных, подобных отчету, пользователю необходимо запросить просто из базы данных и нажать на представление; без преобразования домена/dto, особенно если вы находитесь в веб-приложении. Сделав это, вы сэкономите массу неприятностей. Лично у меня были попытки пройти эти сопоставления только для отображения некоторых данных только для чтения, и он работал плохо; производительности, ненужных сопоставлений, странных вещей, которые мне приходилось делать, чтобы отобразить какие-то отчеты, подобные просмотру. В этом случае у вас, вероятно, будет модель вашего домена и модель чтения. Вы можете найти шаблон CQRS, это может привести вас к мысли, что вы хотите использовать одну и ту же модель данных для записи и чтения.

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