Как обрабатывать представления в многослойном приложении

Question

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

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

Но это не кажется правильным. Почему к ним следует относиться как к нормальным сущностям, когда они явно не таковы? Что ж, DTO кажется необходимым, но создание «бизнес-логики» и класса данных для каждого представления выглядит довольно неудобно. Поэтому я подумал, что создаю один общий класс бизнес-данных и классов данных, который содержит логику / код для всех представлений (мне все равно придется создавать DTO для каждого отдельного представления, возможно, я мог бы использовать анонимные типы)

Что вы думаете обо мне или как бы вы решили эту проблему?

РЕДАКТИРОВАТЬ: 9. августа 2011 Извините, пост может быть неясным. Под views я имел в виду Views с sql-сервера.

Answer 1

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

Пользователь открывает представление -> Запрос выполняется только для получения определенных данных для представления -> Возвращенные данные - это модель (хотя вы можете назвать еетакже DTO, в данном случае это одно и то же)

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

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

Answer 2

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

1. Просмотр моделей для форм / представлений в ASP.Net MVC. Это важный шаг развязки. Пользовательский интерфейс будет развиваться отдельно от модели.
2. Нет сервисного уровня, вместо этого его заменили на «обработчики команд» (операции преобразования) и «средства поиска» (операции запроса), которые представляют небольшие операции и запросы соответственно (CQS - Разделение запроса команды).
3. Сохранение модели с помощью NHibernate и логики домена ALL внутри модели.
4. Любые внешние сервисы также общаются с поиском и обработчиками команд

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

Answer 3

Я бы посоветовал не использовать DTO между слоями. Я не уверен, что есть какая-то польза, но я буду рад получить инструкции, если вы думаете, что у вас есть какие-то.

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

Вот как я бы наложил слои приложений:

view <--- controller <--- service <--- + <--- model
                                       + <--- persistence

Этот дизайн отделяет взгляды от услуг; Вы можете повторно использовать сервисы с разными взглядами. Методы обслуживания реализуют сценарии использования, проверяют входные данные в соответствии с бизнес-правилами, собственными единицами работы и транзакциями и взаимодействуют с объектами модели и постоянства для выполнения запросов.

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

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

Службы и постоянство должны быть основаны на интерфейсе.