Какой слой должен создать модель представления?

Question

Я использую архитектуру S # arp, и я не могу вспомнить, где я ее читал, но они говорят, что ViewModel должны храниться на уровне сервиса, а ваши представления должны отправлять viewmodel в сервис для обработки.

Тогда у меня такой вопрос. Какой слой должен построить ViewModel? Должно ли это быть на уровне сервиса, и контроллер запрашивает это? Или контроллер должен построить его сам? Существует также вопрос об обновлении модели представления, так как если она содержит коллекции и состояние модели недопустимо, вам также потребуется повторно заполнить любые списки.

Есть предложения?

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

Мэтт

Answer 1

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

Но когда вы приступаете к реализации этого самостоятельно с помощью Entity Framework, MVC, Repository и т. Д., Тогда вы понимаете что-то еще.

Кто-то должен отобразить Модели сущностей с помощью ViewModels (DTO упоминается в конце). Должно ли это быть сделано в A) уровне UI (Контроллером) или в B) уровне Service?

Я использую Вариант B. Вариант A - это нет-нет, потому что тот простой факт, что несколько моделей сущностей объединяются в одну ViewModel. Мы не можем передавать ненужные данные на уровень пользовательского интерфейса, тогда как в варианте B служба может воспроизводить данные и передавать только требуемый / минимум на уровень пользовательского интерфейса после сопоставления (в ViewModel).

Но, давайте предположим, что мы перейдем к варианту A, мы поместим ViewModel на уровень пользовательского интерфейса (и модель сущностей на уровень Service).

Если уровень сервиса должен отображаться на ViewModel, то слой сервиса должен иметь доступ к ViewModel на уровне пользовательского интерфейса. Какая библиотека / проект? Модель представления должна находиться в отдельном проекте на уровне пользовательского интерфейса, и на этот проект должен ссылаться сервисный уровень. Если ViewModel не находится в отдельном проекте, то есть круговая ссылка, поэтому не стоит. Выглядит неловко, когда сервисный уровень получает доступ к пользовательскому интерфейсу, но все же мы могли бы справиться с этим.

Но что, если есть другое приложение пользовательского интерфейса, использующее этот сервис? Что делать, если есть мобильное приложение? Насколько может отличаться ViewModel? Должна ли Служба получать доступ к одному и тому же проекту модели представления? или все проекты пользовательского интерфейса будут конкурировать?

После этих соображений мой ответ будет состоять в том, чтобы поместить проект Viewmodel в Service Layer. Каждый уровень пользовательского интерфейса в любом случае должен иметь доступ к уровню сервиса! И может быть много похожих ViewModel, которые они все могут использовать (следовательно, отображение становится проще для уровня обслуживания). В наши дни сопоставления выполняются через linq, что является еще одним плюсом.

Наконец, есть обсуждение DTO. А также об аннотации данных во ViewModels. ViewModels с аннотациями данных не могут находиться на уровне сервиса. Таким образом, DTO будет точной копией ViewModel с отображением один на один между двумя (скажем, с AutoMapper). Опять же, DTO по-прежнему обладает логикой, необходимой для пользовательского интерфейса (или нескольких приложений), и находится на уровне обслуживания. А слой пользовательского интерфейса ViewModel предназначен только для копирования данных из DTO с добавлением некоторого «поведения» (например, атрибута).

Хотя это не имеет прямого отношения к вопросу. 'ViewModel Façade' (viewmodel внутри другой viewmodel) & 'command', упомянутые в этом разделе, должны смотреть канал 9, ссылка также стоит изучить (@ 11: 48 начинается)

Answer 2

Я создаю модели представления внутри контроллеров. Контроллеры берут доменные объекты (извлекаемые из базы данных связывателями моделей), возможно, внутри других моделей представлений, связываются с хранилищами дополнительных данных, создают новую модель представлений и передают ее в соответствующее представление (или перенаправляют). Поэтому ответственность контроллеров заключается в том, чтобы подготовить view / viewmodel в соответствии с данными входной области (и, конечно, обрабатывать ошибки).

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

Приведенный выше метод, связанный с AutoMapper, также поднимал вопросы, похожие на «Должен ли я передавать модели представления на сервисный уровень». Нет, ты не Если вам нужно передать сложный объект на уровень службы или домена, вы определяете этот объект на соответствующем уровне службы / домена и используете его для передачи данных на эти уровни. Затем этот объект может быть легко отображен в / из моделей вида (например, с помощью AutoMapper). Но ваши нижние уровни (сервис / домен) не должны быть связаны с верхними уровнями (вид / контроллеры). Не в этом случае, не в других. Никогда низкоуровневые слои не должны зависеть от того, что определено над ними.

Answer 3

Вам могут быть интересны эти статьи:

DDD: разделение командного запроса как архитектурная концепция

Улучшенные службы приложений и CQS с использованием архитектуры S # arp

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

Answer 4

также посмотрите на Кто может мне помочь - это фантастика. эта структура основана на архитектуре S # arp. кроме всего прочего, у него есть множество рекомендаций для View / Form / Edit viewModels.