Как разделить модель, представление и контроллер в приложении ASP.NET MVC на разные сборки
-
05-09-2019 - |
Вопрос
На данный момент я пытаюсь проникнуть в структуру ASP.NET MVC.
Для большинства моих тестовых приложений я использовал одну сборку/проект.Это отлично работало для некоторых небольших приложений.Затем я задался вопросом, как можно разместить классы модели, контроллера и представления в отдельных сборках?В действительно больших веб-приложениях не очень реально поместить все в одну сборку/проект.
Итак, мой вопрос:Можно ли указать платформе ASP.NET MVC искать в другой сборке представления и/или контроллеры, не теряя встроенной гибкости механизма маршрутизации?
Решение
(неизвестно) верно.Создайте два проекта: библиотеку классов и веб-проект 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
Помните о разных пространствах имен.Затем вы можете создать несколько веб-сайтов-примеров, ссылающихся на один и тот же код.Это позволяет вам эффективно оформить ваш сайт совершенно по-другому.
Другие советы
Создайте отдельный проект библиотеки классов для каждого уровня ответственности, скомпилируйте его для создания сборки, а затем ссылайтесь на каждый из них в своем приложении, где это необходимо.
Да, если вы используете один из поддерживаемых внедрение зависимости контейнеры, то их данные конфигурации обычно указывают не только класс, который будет загружен в ответ на конкретный запрос, но и сборку, из которой он должен быть загружен.Это позволяет вам разделить ваши классы на произвольные сборки, и MVC все равно сможет их найти.
Хотя, конечно, и более простой ответ, предоставленный Неизвестным (Google), тоже подойдет!
Я понимаю, что это действительно старый вопрос, но я написал статью о том, как именно то, что вы просите.
Только завершая ответ @David:
Если вашим проектом управляет NuGet
, после создания библиотек классов выполните копию вашего packages.config
файл в корень библиотеки классов.После этого вам следует отредактировать каждый packages.config
добавлять или удалять пакеты файлов в соответствии с потребностями каждой библиотеки классов.