Pregunta

Yo soy la creación de una aplicación de n niveles con MVC, Ninject y NHibernate (mi primer uso de estas tecnologías). Para mayor claridad, los niveles son un nivel de "Datos", un nivel de "Servicios", y un nivel de "Web" (todos son proyectos separados).

Con MVC, que tenga sus modelos que se encuentran en la carpeta "Modelos". Parece necesario poner mis modelos para crear inflexible de Vistas y mantener en general con la filosofía de la MVC.

Sin embargo, con NHibernate, también necesito mis modelos en el nivel de "datos" para que la asignación puede tener lugar y que NHibernate puede crear instancias de objetos reales para volver a la capa de servicios.

La duplicación de las clases a través de proyectos no es muy seco y abstraer a su propia biblioteca no parecen jugar bien con MVC (ni en la práctica ni la filosofía).

¿Alguna idea? ¿Cómo se estructura el O / RM objetos vs modelos MVC?

¿Fue útil?

Solución

guardo modelos de Entity Framework / clases en el nivel de datos y el uso de la carpeta Modelos del proyecto MVC para los modelos de presentación y aglutinantes modelo.

Otros consejos

El modelo de datos es su propia cosa. El Modelo de MVC es algo diferente. Es el modelo de lo que se va a mostrar, que puede o no puede ser el modelo de datos. Eres modelo de datos pueden atravesar las capas, o no.
Tomemos por ejemplo el formulario de registro estándar. El modelo de datos puede incluir el nombre de usuario, contraseña y una gran variedad de clases de historia de inicio de sesión, un indicador que indica que es activo y muchas otras cosas. El modelo de MVC, puede en realidad sólo se preocupan por nombre de usuario y contraseña, y que el usuario escriba la contraseña dos veces. ¿Su modelo de datos realmente necesita dos campos de contraseña? No. Sin embargo, el modelo en la MVC hace. Por lo tanto, dos criaturas diferentes.

guardo todos mis modelos en el nivel de datos debido a NHibernate. Echar un vistazo a S # arp Arquitectura para una gran manera de mantener su presentación limpia . Los modelos no tienen que estar ubicados físicamente en su proyecto web para sus puntos de vista a tener un tipo fuerte.

Tiene usted razón sobre el principio DRY aquí. Mantener mis objetos LINQ a SQL separado de mis objetos de negocio y tengo alguna duplicación y no me hace sentir bien, pero parece que no hay una solución simple esta ..

Yo tenía un tiempo difícil tomar esta decisión, pero vi el blog de Rob Connery, mientras que la construcción de la MVC Storefront y al final decidí ir por este camino (ORM objetos y objetos de negocio)

  

Con MVC, que tenga sus modelos que   se encuentran en la carpeta "Modelos". Parece   hay que poner mis modelos para   crear inflexible de puntos de vista y   en general, mantener la filosofía de   MVC.

Ningún modelo puede ser cualquier cosa que desee. Me gustaría volver a utilizar un modelo de presentación si fuera necesario, pero no tengo ninguna objeción a la utilización de sus entidades de NHibernate en sus puntos de vista.

Con NHibernate que realmente no necesita un nivel de datos desde la propia sesión es el nivel de datos.

El nivel de servicio parece una idea válida pero sólo si usted planea en tener múltiples clientes para esta capa.

De lo contrario, yo sólo tienen 1 del proyecto y el uso de espacios de nombres para separar mis capas. Se basa más rápido y es más fácil de implementar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top