¿Dónde deberían vivir mis modelos? ¿Nivel web o Nivel de datos? (MVC + NHibernate)

Estoy configurando una aplicación de n niveles con MVC, Ninject y NHibernate (mi primer uso de estas tecnologías). En aras de la claridad, los niveles son un nivel de "Datos", un nivel de "Servicios" y un nivel "Web" (todos son proyectos separados).¿Dónde deberían vivir mis modelos? ¿Nivel web o Nivel de datos? (MVC + NHibernate)

Con MVC, tiene sus modelos que se encuentran en la carpeta "Modelos". Parece necesario poner mis modelos aquí para crear vistas fuertemente tipadas y, en general, mantener la filosofía de MVC.

Sin embargo, con NHibernate, también necesito mis modelos en el nivel "Datos" para que la asignación pueda tener lugar y que NHibernate pueda instanciar objetos reales para regresar a la capa de servicios.

Duplicar las clases en los proyectos no es muy seco y abstraerlas en su propia biblioteca no parece funcionar bien con MVC (ni en la práctica ni en la filosofía).

¿Alguna idea? ¿Cómo se estructuran los objetos O/RM frente a los modelos MVC?

Fuente

2009-02-13 Jeffrey Harrington

estoy curioso cómo el pasaje de 2 años ha confirmado, (refinado, reforzado, et al) esta pregunta. ¿MVC3 cambia la ecuación? Me estoy preparando para crear un híbrido entre un legacy nH data tier - to - EF para soportar andamios. ¿Cuál es la agrupación de proyectos VS al mezclar NH y EF hoy? - thx – justSteve

¿Qué tal ahora? ¿Hace casi 2 años desde que se hizo la pregunta anterior? –

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

Fuente

2009-02-13 17:56:00

Bien. Por lo tanto, parece que el consenso es mantener los modelos de presentación en el nivel web y mis modelos de dominio en el nivel de datos. Entonces, ¿qué debería devolver mi nivel de Servicios al nivel Web? ¿Debería saber sobre los modelos de presentación? ¿O debería devolver modelos de dominio? –

No, no creo que los servicios deban conocer modelos de presentación. De hecho, probablemente no haya forma de que un servicio pueda saber acerca de cada posible modelo de presentación necesario. El servicio debería devolver objetos de transferencia, que podrían ser tipos de entidad. El nivel web puede convertirlo en un modelo de presentación. –

Eso tiene sentido. Sin embargo, aun así, este mapeo de Modelos de Dominio a Modelos de Presentación no parece muy SECO, especialmente cuando los dos Modelos serán similares. –

Guardo todos mis modelos en el nivel de datos debido a NHibernate. Eche un vistazo a S#arp Architecture para una excelente manera de mantener su presentación limpia. No es necesario que los modelos estén físicamente ubicados en su proyecto web para que sus vistas sean fuertemente tipadas.

Fuente

2009-02-13 18:14:03

El modelo de datos es lo suyo. El modelo en MVC es algo diferente. Es el modelo de lo que vas a mostrar, que puede ser o no tu modelo de datos. Tu modelo de datos puede trascender las capas, o no.
Tome por ejemplo el formulario de registro estándar. El modelo de datos puede incluir el nombre de usuario, la contraseña y un conjunto de clases de historial de inicio de sesión, un indicador que indica que está activo y muchas otras cosas. El modelo en MVC, realmente solo se preocupa por el nombre de usuario y la contraseña, y porque el usuario escribe la contraseña dos veces. ¿Su modelo de datos realmente necesita dos campos de contraseña? No. Sin embargo, el modelo en el MVC sí lo hace. Por lo tanto, dos criaturas diferentes.

Fuente

2009-02-13 18:27:51

Bien. Por lo tanto, parece que el consenso es mantener los modelos de presentación en el nivel web y mis modelos de dominio en el nivel de datos. Entonces, ¿qué debería devolver mi nivel de Servicios al nivel web? ¿Debería saber sobre los modelos de presentación? ¿O debería devolver modelos de dominio? –

El nivel de servicios debe devolver el modelo de datos. O bien, pregúntese ... ¿qué sucede si tengo una interfaz diferente para acceder a mis servicios? Cuanto menos sepa su nivel de servicio sobre la interfaz, mejor será a largo plazo. –

Con MVC, tiene sus modelos que se encuentran en la carpeta "Modelos". Parece que es necesario poner mis modelos aquí Crear vistas fuertemente tipadas y en general mantener la filosofía de MVC.

Ningún modelo puede ser lo que usted desee. Todavía usaría un modelo de presentación si fuera necesario, pero no tengo inconveniente en usar sus entidades nhibernate en sus puntos de vista.

Con NHibernate realmente no necesita un nivel de datos ya que la sesión en sí es el nivel de datos.

El nivel de servicio parece ser una idea válida, pero solo si planea tener varios clientes para esta capa.

De lo contrario, solo tendría 1 proyecto y usar espacios de nombres para separar mis capas. Se construye más rápido y es más fácil de implementar.

Fuente

2009-02-13 18:57:40

"Con NHibernate, realmente no necesita un nivel de datos, ya que la sesión en sí misma es el nivel de datos". Para implementar el patrón Repositorio, estoy abstrayendo el nivel Datos. De esta forma, mis servicios se programan contra una interfaz y el nivel de Datos es fácilmente intercambiable (es decir, conmutando O/RM). –

Luego puede colocar sus entidades en una biblioteca central y poner sus repositorios con sus servicios. Los repositorios son servicios. –

Tiene razón acerca del principio DRY aquí. Mantengo mis objetos LINQ-to-SQL separados de mis objetos comerciales y tengo algo de duplicación y no me hace sentir bien, pero parece que no hay una solución simple.

tuve un momento 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 me decidí a ir por este camino (objetos ORM y objetos de negocio)

Fuente

2009-02-21 12:59:14

¿Dónde deberían vivir mis modelos? ¿Nivel web o Nivel de datos? (MVC + NHibernate)

Respuesta

Cuestiones relacionadas