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

Question

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

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

Answer 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

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

Answer 2

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

Answer 3

Я понимаю, что это действительно старый вопрос, но я написал статью о том, как именно то, что вы просите

http://dotnetslackers.com/articles/aspnet/storing-asp-net-mvc-controllers-views-in-separate-assemblies.aspx

Answer 4

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

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

Answer 5

Только завершение @ ответа Дэвида:

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