consejos sobre la arquitectura de aplicaciones asp.net mvc

Question

He estado usando ASP.net MVC durante aproximadamente dos años y todavía estoy aprendiendo la mejor manera de estructurar una aplicación.

Quería descartar estas ideas que he reunido y ver si son formas "aceptables" en la comunidad para diseñar aplicaciones MVC.

Aquí está mi diseño básico:

• DataAccess Proyecto - Contiene todas las clases de repositorios, los contextos de datos LINQ a SQL, filtros y objetos de negocio personalizadas para repositorios que no sea MS SQL db (que LINQ-to-SQL no crea). Los repositorios generalmente solo tienen CRUD básico para el objeto que están administrando.

• Proyecto de servicio - Contiene clases de servicio que realizan la lógica empresarial. Toman órdenes de los Controladores y le dicen a los repositorios qué hacer.

• UI Project - Contiene modelos de vista y algunas envolturas sobre cosas como el ConfigurationManager (para pruebas unitarias).

• Main MVC Project - Contiene controladores y vistas, junto con javascript y css.

que sí parece esto como una buena manera de estructurar las aplicaciones ASP.NET MVC 2? ¿Alguna otra idea o sugerencia?

¿Se utilizan los modelos de vista para todos los resultados de las vistas y las entradas de las vistas?

Me inclino por el camino de hacer modelos de vista para cada objeto comercial que necesita mostrar datos en la vista y convertirlos en clases básicas con un conjunto de propiedades que son todas cadenas. Esto hace que tratar con las vistas sea bastante fácil. La capa de servicio necesita administrar las propiedades de mapeo del modelo de vista al objeto de negocio. Esta es una fuente de confusión porque la mayoría de los ejemplos que he visto en MVC/MVC2 no usan un modelo de vista a menos que necesite algo como un cuadro combinado.

Si usa la nueva validación del modelo de MVC 2, ¿validaría el objeto viewmodel y no tendría que preocuparse por poner los atributos de validación en los objetos comerciales?

¿Cómo se prueba unitariamente este tipo de validación o no debo probar por unidad que se devuelvan los mensajes de validación?

Gracias!

Answer 1

Interesante.

Una cosa que hago diferente es que me separé de mi proyecto de DataAccess de mi proyecto de Dominio. El proyecto de dominio todavía contiene todas las interfaces para mis repositorios, pero mi proyecto de DataAccess contiene todas las implementaciones concretas de ellos.

No desea que cosas como DataContext se filtren en su proyecto de dominio. Después del onion architecture su dominio no debería tener dependencias en la infraestructura externa ... Considero que DataAccess tiene eso porque está directamente relacionado con una base de datos.

Dividirlos significa que mi dominio no tiene una dependencia en ningún ORM o base de datos, por lo que puedo cambiarlos fácilmente si es necesario.

Saludos,
Charles

Ps. ¿Cómo se ve la dependencia de tu proyecto? Me he estado preguntando dónde colocar mis ViewModels. Quizás un proyecto de IU separado sea una buena idea, pero no estoy del todo seguro de cómo funcionaría. ¿Cómo fluyen a través de los diferentes niveles de proyecto de su aplicación?