контроллер веб-API в n-слойной архитектуре

Интересно, просто ответил на аналогичный вопрос...

Поэтому я не сделаю этого, я был вами.

Вот только несколько недостатков подхода от верхней части головы:

1. Производительность - избыточный HTTP-обратный трафик в проекте Web MVC.
2. Разделение проблем - в большинстве случаев функциональность, предоставляемая API, сильно отличается от пользовательского интерфейса для одного и того же проекта/приложения. Вы можете ограничить API несколькими способами со строгим контрактом. Если вы хотите, чтобы веб-API был слоем между веб-MVC и вашим DAL, вам также придется выставить всю функциональность, необходимую для пользовательского интерфейса. Также вы можете иметь разные механизмы авторизации и аутентификации. Очень часто обработка исключений API также различна, а также проверка ввода.
3. Maintanance - каждый раз, когда вам нужно внести изменения, необходимые для пользовательского интерфейса, вы должны убедиться, что он не тормозит ваших клиентов API. Кроме того, версия API - это очень важная тема, и ее смешивание с большинством изменений пользовательского интерфейса делает этот процесс еще более сложным.

Вероятно, на данный момент приложение не так сложно, но с точки зрения дизайна ваше решение намного более гибкое, чем если бы вы решили разместить веб-API между вашими интерфейсами и слоями DAL.

Приложения N-Tier и многослойные не пользуются популярностью среди новой волны разработчиков. Имейте в виду, что только потому, что что-то не популярно среди группы, это не значит, что у него нет заслуг.

Плюсы MVC:

• Разделение проблем
• Тестирование устройства

Имеет ли многоуровневое MVC-приложение, использующее Web.API:

Я знаю, что это будет встречено с некоторым недовольством и разногласиями. Тем не менее, я обеспокоен тем, что разработчики приложений с одним назначением не учитывают развитие предприятия. Развитие предприятия, балансировка нагрузки, управляемое обслуживание кода и истинное разделение проблем возможны только в многоуровневых приложениях, которые могут легко поддаваться N-уровню.

Многие разработчики работают в средах, которые требуют, чтобы они проектировали и внедряли структуры данных в SQL, создавали и поддерживали модели и функции CRUD, разрабатывали контроллеры и разрабатывали привлекательные и дружелюбные взгляды. Модель MVC, использующая Entity Framework, делает эту управляемую задачу для этих небольших и умеренных разработчиков платформы.

На Предприятии разделение уровней доступа к бизнесу и доступу к данным из пользовательского интерфейса дает реальный смысл. Сейчас MVC - популярная и очень функциональная платформа для эффективной и удобной разработки пользовательского интерфейса. Какая платформа UI через десять лет? Разделение пользовательского интерфейса из других слоев дает больше жизни для работы, потраченной на разработку бизнес-логики. Не говоря уже о том, что сегодня он позволяет получать доступ к данным на нескольких платформах.

Многослойный MVC с использованием Web.API имеет следующие преимущества:

• Истинное разделение проблем
• Поддерживает модульное тестирование
• Делает логику бизнес-логики и доступа к данным более масштабируемой и многоразовой, чем только MVC.
• Поддерживает процессы обработки данных без обновления страницы. (ОТДЫХ)

CONS: - не поддерживает поддержку Entity Framework. (Что еще не готово для предприятия)

Я согласен с другими здесь, изучая использование строго типизированных представлений, контроллеры создавали бы экземпляр viewmodel и отправляли его в представление. Затем модель представления является посредником на уровне служб данных. Я лично создаю все свои объекты, используя EF, в другом проекте, чтобы разделить функцию. Модель просмотра может либо вызвать EF напрямую, либо вы можете добавить еще один слой предварительно запрограммированных EF-запросов, которые Viewmodel использует для заполнения коллекций представлений. Это будет выглядеть так:

[View] - [Controller] - [Viewmodel] - [Дополнительный репозиторий и интерфейс к EF] --- [EF]

В интерфейсе EF вы поймаете все ошибки БД при попытке получить информацию и вернуться к представлению в соответствии с вашим дизайном.

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

Вы можете реализовать бизнес-логику/проверку/калибровку в реальных классах model/entity, а не ApiControllers, иначе у вас будет столько кода в контроллере, что на самом деле не очень хорошо.

Также вы можете использовать атрибуты DataAnnotations для выполнения вашей проверки, которая находится вне вашего контроллера. for.eg http://msdn.microsoft.com/en-us/library/ee256141(v=vs.100).aspx

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

Но то, что я предпочитаю делать, это сохранить логику в собственном слое. Причина в том, что, я думаю, лучшее разделение проблем. Мне нравится использовать IoC, поэтому могут быть разные конфигурации, которые я маршрутизировал, думая о разных запущенных решениях. Или у меня может быть другой интерфейс/API/проект, который использует один и тот же логический уровень.

Что касается накладных расходов, он имеет немного накладных расходов, но я думаю, стоит того, чтобы сравнить с фактическими накладными расходами в коде, который он создает.