Какой слой должен создать Модель Представления?
Я использую архитектуру S#arp, и я не могу помнить, где я считал ее, но они говорят их, ViewModels должен быть сохранен на уровне служб, и Ваши представления должны подвергнуть viewmodel сервису для обработки.
Мой вопрос затем - это. Какой слой должен создать ViewModel? Это должно быть на уровне служб, и контроллер запрашивает это? Или контроллер должен создать его сам? Существует также вопрос об обновлении модели представления, как будто это содержит наборы, и образцовое состояние недопустимо, Вам также будут нужны к repopuplate любые списки.
Какие-либо предложения?
Большое спасибо
Матовый
3 ответа
Я создаю модели представления внутри контроллеров. Контроллеры берут сущности домена (извлекаемые из базы данных связывателями моделей), возможно, внутри других моделей представления, связываются с репозиториями для получения дополнительных данных, создают новую модель представления и передают ее соответствующему представлению (или перенаправляют). Таким образом, ответственность контроллеров состоит в том, чтобы подготовить представление / модель представления в соответствии с входными данными домена (и, конечно же, обработать ошибки).
Вы можете посмотреть здесь для альтернативы созданию моделей представления в контроллере. Этот метод перемещает создание модели представления за пределы действий, так что не только действия контроллера принимают чистые объекты домена, но также возвращают чистые объекты домена. Я бы не сказал, что это уместно во всех случаях, но научиться этому очень интересно.
Вышеупомянутый метод, связанный с AutoMapper, также вызвал вопросы, подобные «следует ли передавать модели просмотра на уровень обслуживания». Нет, не знаешь. Если вам нужно передать сложный объект на уровень сервиса или домена, вы определяете этот объект на соответствующем уровне сервиса / домена и используете его для передачи данных на эти уровни. Затем этот объект можно легко сопоставить с моделями представления (например, с помощью AutoMapper). Но ваши нижние уровни (служба / домен) не должны быть связаны с верхними уровнями (представление / контроллеры). Ни в этом случае, ни в других. Ни в коем случае уровни нижнего уровня не должны зависеть от чего-то определенного над ними.
Эти статьи могут быть вам интересны:
DDD: разделение командных запросов как архитектурная концепция
Улучшение служб приложений и CQS с использованием S # arp Архитектура
Существует пример приложения, связанного со второй статьей, которое имеет модели представления и формы на уровне служб, а не в контроллере.
также посмотрите Кто может мне помочь - это фантастика. эта структура основана на архитектуре S # arp. в нем есть много рекомендаций по View / Form / Edit viewModels среди прочего.