Использование репозиториев и сервисных ссылок в контроллерах MVC

Question

У меня возникли проблемы с выбором решения для моего приложения MVC.

Справочная информация.

У нас есть модель EF, с которой мы выполняем операции через службы WCF (не службы данных).

У меня есть приложение MVC, у которого есть несколько репозиториев, которые обращаются непосредственно к службам и возвращают их.WCF возвращается обратно к контроллеру, который вызывает метод репозитория. Этот тип вызывается, например, WCFUserEntity (на самом деле это не префикс WCF).

Внутри контроллера я планирую автоматизировать WCFUserEntity для объекта ViewModel.

Что меня беспокоит в этом решении, так это то, что из-за того, что я возвращаю WCFUserEntity контроллеру, у меня должна быть ссылка на прокси-сервер WebService в моем контроллере, который мне не подходит, мне нужны мои контроллерыничего не знать о том, откуда хранилище получило данные.Поэтому другой вариант для меня - сделать автоматическое отображение внутри репозитория и вернуть сущность ViewModel в контроллер, хотя я не могу найти много вокруг того, что поддерживает эту идею, так что на самом деле я ищу валидацию этого 2-го решения.или помогите с 3-м.

спасибо, Dom

Answer 1

Как я мог бы подойти к этому, может потребоваться внести некоторые изменения в архитектуру, но я бы посоветовал вам обратиться к своему API-интерфейсу WCF, чтобы вернуть ViewModels вместо сущностей.

Для начала подумайте о проблемах с пропускной способностью (которые могут возникнуть при размещении WCF в Azure или в облаке). Если ваша ViewModel использует только несколько определенных свойств, зачем тратить пропускную способность, возвращая другие данные? В сценариях с высоким трафиком это может привести к трате трафика, что может привести к затратам. Например, если в вашем представлении отображаются только пользователь и его вопросы, нет причин отправлять по электронной почте его электронную почту, ответы, количество баллов и т. Д.

Еще одна проблема, о которой стоит задуматься, это стремление к загрузке. Имея, что служба WCF возвращает ViewModel, вы знаете, что у вас есть все данные (даже если они относятся к связанным объектам), необходимые для представления за одну поездку к службе WCF. Вам не нужно получать WCFUserEntity, а затем запрашивать у WCF WCFDocumentEntities, которые связаны с этим конкретным пользователем.

Наконец, если ваш WCF API построен на ViewModels, у вас НАМНОГО более ясное понимание вовлеченных бизнес-процессов. Вы знаете, что этот конкретный запрос (и представление в системе) даст вам эту конкретную информацию, и если вам нужна другая информация для другого представления, то вы знаете, что это совершенно другой бизнес-запрос, имеющий другие бизнес-требования. Используя переполнение стека в качестве примера, легко увидеть, что этот бизнес-процесс запрашивает текущего пользователя со своими связанными вопросами, в то время как этот бизнес-процесс запрашивает текущего пользователя со связанными ответами.

Использование ViewModels в вашем API поиска WCF означает, что ваши внешние слои не обязательно знают, откуда поступили данные, они просто знают, что они вызвали бизнес-процесс и получили необходимые данные. Насколько он знает уровень данных, подключенный к базе данных напрямую, а не к WCF.

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

Answer 2

Вы можете рассмотреть третий вариант.

Использование ViewModelBuilders.

в вашем контроллере они будут работать так:

var myViewModel = myViewModelBuilder.WithX (). WithY (). Build ();

WithX и WithY были бы методами, которые добавляли бы вещи к вашей модели представления внутренне (внутри компоновщика, например WithCountriesList (), если вы хотите добавить раскрывающийся список, показывающий страны в вашем представлении), а метод Build вернул бывнутренняя модель представления после добавления всех битов методами WithXXX.Это так, потому что большую часть времени вы можете захотеть добавить списки для выпадающих списков и вещей, которые не являются частью вашей исходной модели (в данном случае, вашего userEntity).

Таким образом, ваш контроллер не знает ничего о том, как построить модель представления, ваш репозиторий также не зависит от моделей представления.Вся работа выполняется в Builder.С другой стороны, вам нужно создать ViewModelBuilder для каждой ViewModel.

Надеюсь, это поможет.