Приложение MVC3, на существующую архитектуру

Question

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

Теперь я хочу попробовать создать приложение MVC3. Итак, правильно ли построить это как отдельный проект в моем решении, а затем включить часть контроллера в приложение MVC для уровня обслуживания моего текущего решения? Например, мой сервисный уровень предоставляет метод «GetAllUsers», который возвращает список. Затем я беру этот список и формирую модель (M часть MVC) и передаю ее в представление. Кажется, все в порядке?

Answer 1

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

Answer 2

Чтобы повторить Dima - вы можете снова сопоставить свои классы DTO с пользовательскими классами ViewModel, специально предназначенными для просмотра (в противном случае вам может понадобиться использовать ViewBag и т. Д., Чтобы добавить дополнительные данные в представление).

Также для подтверждения того, что «M» MVC представляет собой весь задний конец системы (DAL, BLL, Service Layer, DTO, Entities и т. Д.). Обычно мы удаляем папку Model в проектах MVC asp.net, так как другие слои находятся в отдельных сборках и на которые ссылаются/вводятся. Я предполагаю, что ваш внешний интерфейс MVC является «основным» интерфейсом для вашей системы (т. Е. Одна и та же команда разрабатывает внешний интерфейс MVC и задний конец).

Одна спорная точка - это уровень обслуживания - есть как минимум следующие 2 варианта.

1. Вы можете рассматривать слой сервиса для только потребителей «внешний» системы, и разрешить контроллеры непосредственно взаимодействовать с УСК, или даже (стиль CQRS) непосредственно с DAL/Repository для запросов (т.е. Service Layer = разомкнутый интерфейс интерфейсов интеграции). (Но ваш собственный внешний интерфейс Ajax вызывает и т. Д. Должен вызывать методы MVC-контроллера, а не сервисный уровень IMO)
2. Примите более традиционный строгий многоуровневый подход и рассмотрите уровень обслуживания как шлюз для вашего бизнес-уровня (т. Е. Ваш MVC-фронт isn ' t особый потребитель услуг вообще и должен пройти через сервисный уровень).

В варианте 1 вам может потребоваться дублировать службы в контроллере (безопасность, границы транзакций, ведение журнала и т. Д.). Как правило, диспетчеру потребуется эта проблема.

С вариантом 2, например. если вы используете WCF, вы должны попытаться избежать дополнительных сетевых (и сериализации/десериализации), если это возможно. Поэтому, если вы обнаружите, что вы можете развернуть свой внешний интерфейс и уровни обслуживания на одном физическом сервере, вы можете, например, сконфигурировать IoC (или classfactory), чтобы вставлять ваши экземпляры контрактов на обслуживание WCF прямо в ваш контроллер (т. Е. все еще проходят через уровень обслуживания через определенные контракты WCF, но без накладных расходов).

Также с вариантом 2, если у вас есть другие системы, которые используют ваши услуги (кроме вашего собственного интерфейса), может быть целесообразным формализовать ваш интерфейс, например. дополнительным фасадом/картографированием для внешних потребителей. В противном случае, каждый раз, когда вы добавляете новое свойство или метод в службу WCF для своего собственного интерфейса, вы нарушаете контракт внешних потребителей. WCF MessageContract s полезны для внешних системных интерфейсов, поскольку у вас есть более тонкий контроль над форматами сообщений.