Можно ли получить доступ к MVC Views, расположенным в другом проекте?

Ответ 1

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

Поскольку представления - это файлы, когда вы разбиваете их на отдельный проект, они не будут существовать в вашем основном проекте веб-приложений. Таким образом, механизм просмотра не может их найти. При компиляции приложения любые ссылки на проекты будут копировать только DLL (и, возможно, несколько других вещей, например, pdb и т.д.).

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

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

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

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

Ответ 2

Для включения контроллеров вам необходимо изменить регистрацию маршрута, чтобы сообщить им, где искать контроллеры:

routes.MapRoute(name: "Default", url: "{controller}/{action}/{id}",
                namespaces: new[] {"[Namespace of the Project that contains your controllers]"},
                defaults: new {controller = "Home", action = "Index", id = UrlParameter.Optional});

для включения View вы создаете пользовательский ViewEngine:

public class CustomViewEngine: RazorViewEngine
{
    public CustomViewEngine()
    {
        MasterLocationFormats = new string[]
        {
            "~/bin/Views/{1}/{0}.cshtml",
            "~/bin/Views/{1}/{0}.vbhtml",
            "~/bin/Views/Shared/{0}.cshtml",
            "~/bin/Views/Shared/{0}.vbhtml"

        };
        ViewLocationFormats = new string[]
        {
             "~/bin/Areas/{2}/Views/{1}/{0}.cshtml",
             "~/bin/Areas/{2}/Views/{1}/{0}.vbhtml",
             "~/bin/Areas/{2}/Views/Shared/{0}.cshtml",
             "~/bin/Areas/{2}/Views/Shared/{0}.vbhtml"
        };
        .
        .
        .
    }
}
protected void Application_Start()
{
    ViewEngines.Engines.Add(new CustomViewEngine());

для получения дополнительной информации см. стандартную реализацию RazorViewEngin.

Вот несколько хороших статей:

Сохранение контроллеров и представлений ASP.NET MVC в отдельных сборках

ASP.NET MVC: установка ваших контроллеров в отдельную сборку

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

Ответ 3

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

Как это сделать:

• Переместить представления в другой проект
• Установка расширения Razor Generator в Visual Studio
• Измените настраиваемый инструмент на RazorGenerator для тех просмотры
• Добавить пакет RazorGenerator.Mvc NuGet в проект вида
• Проект справочного представления из вашего основного проекта

Что это!

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

Другим недостатком является то, что всем, кто будет работать с представлениями, потребуется расширение Razor Generator.

Как это работает, в основном вы делаете Visual Studio генерировать файлы .cs из ваших представлений во время разработки, и они являются частью скомпилированной DLL, как и любой другой фрагмент кода.