MVC 3 project structure

Question

Estoy tratando de encontrar la mejor forma de diseñar mi proyecto MVC 3. Al buscar en línea, encontré una sugerencia que decía básicamente hacer clic derecho en el proyecto y agregar área. Lo que esto hizo fue crear una carpeta de área con la misma estructura de controlador/vista/modelo en el mismo proyecto. Esto no es lo que quiero. Quiero la flexibilidad de tener proyectos separados. Mantendré solo las vistas en el proyecto web principal. Todo lo demás en un proyecto separado.

Para ese intento creé un proyecto separado para mis controladores. Ahora estoy atascado con señalar una acción de controlador a una vista. En todos los ejemplos en línea, se hizo clic con el botón derecho y se agregó una vista. Siendo este un proyecto de biblioteca de clase, no tengo esa flexibilidad. ¿Dónde me estoy equivocando?

Todos los ejemplos que he encontrado, incluidos los que he visto en Asp.net, básicamente explican cómo crear aplicaciones de estudio, lo que solo es bueno para fines de aprendizaje. Una gran aplicación comercial no puede tener todas las vistas/modelos/controladores en un solo proyecto. ¿O es así como se supone que debe ir en MVC? No estoy seguro de si hacer todo con los clics del mouse también es una buena idea. En el mundo de los formularios web también hubo muchas aplicaciones de estudio para principiantes que usaban clics del mouse para crear aplicaciones CRUD básicas, pero en proyectos comerciales reales, nunca usamos esos métodos.

¿Cuáles son sus pensamientos, orientación sobre esto?

Gracias por su tiempo ...

Answer 1

MVC está basado en una convención; la convención es que pone todas las vistas en/vistas, los modelos en/modelos y los controladores en/controladores. Puede cambiar la convención pero no hará su vida más fácil.

Desde un punto de vista conceptual esto tiene sentido. Si mantiene toda la lógica de dominio y el acceso a los datos en proyectos separados, todo lo que le queda es el material relacionado con la web, sus controladores, ver modelos y vistas. Ese es tu proyecto MVC.

Tenga en cuenta que si desea dividir partes en proyectos separados, puede encontrar útil portable areas.

Answer 2

no veo por qué no puede utilizar el incorporado en los generadores como base para sus puntos de vista y los controladores? Nada dice que debes dejarlos tal como se generaron. Personalmente, creo que es realmente bueno generar una base para mí (con clics del mouse).

El proyecto MVC es solo una capa de interfaz de usuario. Es una locura poner la lógica en él para aplicaciones a gran escala. Por lo tanto, está bien tener un proyecto para toda la interfaz de usuario. De hecho, hace que sea más fácil obtener una visión general de la IU.

Dicho esto, hay formas de obtener una solución basada en un complemento donde puede mover los controladores (, modelos y vistas) a las bibliotecas de clases. Pero no es fácil.

1. Es necesario crear un proveedor de ruta virtual (para encontrar los puntos de vista)
2. Hacer todas las vistas incrustadas
3. Modificar el archivo de proyecto para obtener el "Añadir punto de vista"
4. Use áreas de diálogo, etc (lo hace más fácil)
5. Dígale al BuildManager que existe su DLL de complemento.

También necesita modificar el proveedor de ruta virtual para acceder a las vistas desde sus carpetas de complementos si desea poder modificar las vistas durante el tiempo de ejecución en Visual Studio. Cualquier cambio requeriría una reconstrucción del plugin DLL.

actualización

de Video en MVC2 (áreas MvC3 funciona de la misma): http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-areas

tenga en cuenta que el video es para áreas en el mismo proyecto. Tener áreas en bibliotecas de clases separadas es más complejo. La solución más fácil es usar las áreas portátiles como lo sugirió otra persona.

Answer 3

¿Por qué mantener solo sus vistas en el 'proyecto web principal'? Creo que se está perdiendo el sentido con MVC.

Son los controladores los que forman parte de su 'web principal'. Son lo que sus usuarios solicitan y vuelven a publicar, no la vista.

La vista está solo allí para proporcionar un medio para el diseño de HTML para que el controlador presione en el navegador.

Los modelos que creo que deberían ser realmente ViewModels, están ahí para proporcionar contenido (es decir, datos reales) para sus vistas.

Por lo tanto, puede ver que el diseño de MVC realmente quiere que los tres se agrupen sensiblemente. Los controladores interactúan con su usuario, obtienen la vista (el diseño) y la llenan con su ViewModel/Model (los datos). Esta es su interfaz de usuario, las tres partes de MVC (si usa el ViewModel de todos modos) son solo para UI.

De dónde provienen los datos, sus modelos reales y lo que quiera hacer con ellos pueden residir fácilmente en un dll en algún lugar o en el otro lado de un conjunto de servicios web o lo que sea.