Как отделить модель, просмотр и контроллер в приложении ASP.NET MVC в разных сборках

В настоящий момент я пытаюсь войти в структуру ASP.NET MVC.
Для большинства моих тестовых приложений я использовал единую сборку/проект. Это отлично подходит для некоторых небольших приложений. Затем я подумал, как я могу разместить классы модели, контроллера и представления в отдельных сборках? В действительно больших веб-приложениях не очень реалистично вкладывать все в единую сборку/проект.

Итак, мой вопрос: возможно ли сообщить инфраструктуре ASP.NET MVC для поиска в другой сборке для представлений и/или контроллеров без потери встроенной гибкости механизма маршрутизации?

Ответы

Ответ 1

(неизвестно) правильно. Создайте два проекта: библиотеку классов и веб-проект MVC. Проект MVC должен ссылаться на библиотеку классов, которая содержит контроллеры и код за файлами (глобальный asax и т.д.). Вот пример макета.

Библиотека классов должна содержать только файлы .cs и никакие представления (файлы .aspx/.ascx).

MyProject.BaseSite (class library)
    + Controllers
        - HomeController.cs
        - ... any other controllers
    - default.aspx.cs
    - global.asax.cs

Веб-проект MVC должен содержать конфигурации, представления и т.д. и ссылку на вашу библиотеку классов

MyProject.ExampleSite
    + Content
        + scripts
        + css
        + images
    + Views
        + Home
            - index.aspx
            - .. other aspx files
        + Shared
            - Site.master
    - web.config

Помните о разных пространствах имен. Затем вы можете создать несколько веб-сайтов примера, которые ссылаются на один и тот же код. Это позволяет эффективно скрыть ваш сайт по-разному.

Ответ 2

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

Ответ 3

Да, если вы используете один из поддерживаемых контейнеров dependency injection, то их данные конфигурации обычно указывают не только класс, который должен быть загружен в ответ на конкретный запрос, а также сборку, из которой она должна быть загружена. Это позволяет разделить классы на произвольные сборки, и MVC все равно сможет их найти.

Хотя, конечно, будет работать и более простой ответ, предоставленный Неизвестным (Google)!

Ответ 5

Выполнение только ответа @David:

Если ваш проект управляется NuGet, после создания библиотек классов выполните копию вашего файла packages.config в корневой каталог классов. После этого вы должны отредактировать каждый packages.config файл, добавляющий или удаляющий пакеты, в соответствии с потребностями каждой библиотеки классов.