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

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

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

Любые предложения?

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

Matt

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ответ 3

Эти статьи могут быть вам интересны:

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

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

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

Ответ 4

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