¿Es posible acceder a MVC Views ubicado en otro proyecto?

Quiero separar mi proyecto MVC en varios proyectos

Entonces, antes que nada, he creado dos proyectos Front y Views

El proyecto Front es una aplicación web que contiene controladores y modelos

El proyecto Views es un proyecto de biblioteca de clase que contendrá solo las vistas

Mi pregunta es cómo puedo hacer que los controladores llamen a las vistas ubicadas en el proyecto Vistas

Tengo controladores como este:

public ActionResult Default() { return this.View(); } 

MVC no comstack vistas en DLL, sino que las referencia como archivos desde la raíz de su directorio de sitio. La ubicación, por convención, es ~ / Views y se sigue una ruta de búsqueda. Esto está más o menos codificado en los motores de vista por defecto.

Como las Vistas son archivos, cuando los divide en un proyecto separado, no existirán en su proyecto de aplicación web principal. Por lo tanto, el motor de vista no puede encontrarlos. Cuando comstack la aplicación, los proyectos a los que se hace referencia solo copiarán los DLL (y potencialmente algunas otras cosas, como pdb’s, etc.)

Ahora, hay formas de evitar esto, pero para ser honesto, generalmente son más problemas de lo que valen. Puede buscar en “Áreas portátiles” en el proyecto contrib mvc, pero estos no son bien compatibles y se ha hablado de reemplazarlos con el paquete NuGet.

También puede seguir los consejos de @mo.esmp y crear un motor de visualización personalizado, pero igual tendrá que encontrar maneras de copiar las Vistas en algún lugar al que el sitio pueda acceder una vez comstackdas o implementadas.

Mi sugerencia sería NO dividir proyectos de la manera que usted describe. No veo ningún valor en eso. Si su proyecto se vuelve tan grande, en su lugar, separaría su código en áreas, y mantendría todo su código de área y datos juntos.

¿Qué valor hay en separar elementos que son claramente dependientes uno del otro en asambleas separadas cuyo único propósito es recoger cosas en función de su propósito? Veo algún valor al separar los modelos en su propio proyecto, ya que los modelos pueden ser utilizados por más de un ensamblaje. Controladores y vistas, sin embargo, solo son utilizados por el sitio principal de MVC.

Para incluir controladores, debe cambiar los registros de ruta para indicarles dónde buscar los controladores:

 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}); 

para incluir View usted crea ViewEngine personalizado:

 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()); 

para obtener más información, consulte la implementación predeterminada de RazorViewEngin.

Aquí algunos buenos artículos:

Almacenamiento de Controladores y Vistas ASP.NET MVC en ensamblajes separados

ASP.NET MVC: poner sus controladores en una asamblea separada

Cómo llamar controladores en ensamblados externos en una aplicación ASP.NET MVC

Puede precomstackr sus vistas, de esa manera se incluyen en el dll y puede hacer referencia a ellas desde otro proyecto.

Cómo hacerlo:

  1. Mueva las vistas a otro proyecto
  2. Instalar la extensión Razor Generator en Visual Studio
  3. Cambie la herramienta personalizada a RazorGenerator por esas vistas
  4. Agregue el paquete RazorGenerator.Mvc NuGet al proyecto de visualización
  5. Proyecto de vista de referencia de su proyecto principal

¡Eso es!

Aunque tendrá que hacer algo con sus modelos, colóquelos junto con vistas o tenga un tercer proyecto para ellos; de lo contrario, tendrá una dependencia circular.

Otro inconveniente es que todos los que trabajarán con las vistas necesitarán la extensión Razor Generator.

La forma en que esto funciona es básicamente hacer que Visual Studio genere archivos .cs desde sus puntos de vista en tiempo de diseño y que sean parte del dll comstackdo, igual que cualquier otro fragmento de código.