MVC Области для предприятия - хорошие или плохие?

В рамках одного решения по проекту, представляющего области, когда у вас много контроллеров, улучшается разделение и позволяет легко копировать модули в решение или из него. Однако в крупном корпоративном решении я бы предпочел разделить логику на отдельные проекты.

Таким образом, существуют отдельные проекты интерфейса, контроллера, SOA, модели и репозитория. В этом сценарии области больше не имеют смысла, плюс они добавляют дополнительный верхний уровень к Url, который часто не нужен, хотя я считаю, что вы можете опустить область в URL, если вы держите свои контроллеры уникальными, но не что немного вонючий?

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

Ответ 1

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

Я использую области MVC для предприятия и люблю несколько вещей об этом:

Обычно люди работают над функцией в пределах данного домена (например, Search, Checkout и т.д.). Если имена областей соответствуют вашим бизнес-доменам, Области MVC помогают сократить время, затрачиваемое на реализацию функции, поскольку связанные классы легко найти.
Маршрутизация MVC дает вам тонкость гибкости относительно того, как структурировать URL-адреса. Раньше я использовал "Контроллер действия" "шаблон" , но для URL-адресов, не относящихся к публике, я только что полностью охватил маршрут по умолчанию в регионе, чтобы упростить.
Области дают вам особое преимущество стилизации и, что более важно, инкапсулирующего поведения на уровне раздела сайта. Каждая область получает свою собственную веб-конфигурацию, где вы можете управлять базовым представлением или добавлять управляемые обработчики.

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

Но области MVC отлично подходят для предоставления некоторого порядка хаосу UI/маршрутизации, поскольку веб-проект растет, что для меня неоценимо, независимо от контекста.

Ответ 2

Прежде всего, прежде чем ответить, обратите внимание, что это только мое мнение, и в основном это касается моделей.

Как я вижу, области могут быть настолько злыми. Если у вас много областей, ваш исследователь решений становится лабиринтом, и ему может быть так сложно что-то найти.

Я предлагаю создать новый проект библиотеки внутри вашего решения и разместить там логику.

Лучшее преимущество (и это не то, что вы можете найти то, что вы ищете намного проще) заключается в том, что ваше приложение становится гораздо более модульным. Если вы создаете библиотеку и указываете ссылку для нее в приложении ASP.NET MVC, вы не можете легко ошибиться и задействовать интерфейс в логике.