2009-05-29 18 views
10

Estamos a punto de embarcarnos en un desarrollo ASP.NET MVC y hemos estado utilizando nuestro propio marco de entidades durante años. Sin embargo, necesitamos apoyar más de lo que nuestro marco de entidad es capaz de hacer, por lo que me gustaría obtener algunas opiniones sobre el uso de MVC con un marco más sólido. Hemos reducido o seleccionado NHibernate (con las API Fluent) o LINQ to SQL.Qué marco de datos es mejor para un sitio ASP.NET MVC - LINQ to SQL o NHibernate

¿Qué marco se presta mejor para el desarrollo de estilo MVC (sé que SO usa LINQ to SQL)?

Si queremos admitir SQL Server, Oracle, MySQL, ¿eso excluye LINQ to SQL?

+1

También hay 3 subsónicos con plantillas de mvc. –

+0

¿No devuelve un objeto IQueryable que Linq-to-SQL sea una API fluida? – Nick

Respuesta

4

He tenido un gran éxito usando Fluent NHibernate y la inyección de dependencia (Ninject, en mi caso) con MVC.

Me parece que cualquier ORM maduro debería funcionar bien con MVC. Dado que la naturaleza de MVC (Modelo/Vista/Controlador) separa las tres preocupaciones, cualquier ORM debe encajar bastante bien en el rol de "Modelo".

+0

Esa es la pila a la que me inclino actualmente. ¿Dónde hay problemas que debería tener en cuenta? –

+0

Ninguno que se le ocurra inmediatamente, o al menos eso no se resuelve ahora. Originalmente implementé mi propio módulo para d-inyectar los controladores MVC, pero ahora hay una implementación oficial de Ninject: http://github.com/enkari/ninject.web.mvc/tree/master Estoy seguro de que ahora MVC es Ganar popularidad rápidamente, los otros marcos DI tienen módulos similares si no vas con Ninject. Dependiendo de cuán compleja sea la configuración de su NH, es posible que tenga un trabajo adicional para que las fábricas de la sesión se inyecten, pero FNH juega muy bien con DI por la naturaleza de su interfaz DSL. –

+0

Stuart: ¿Por qué se prefiere un tipo de infraestructura/tecnología de acceso a los datos a otro en el desarrollo ASP.NET MVC? Pensé que ASP.NET MVC no hace suposiciones (ni tiene ningún sesgo) sobre el tipo de acceso a datos utilizado. Dado que el acceso a los datos está ocurriendo en alguna parte del Modelo, podría utilizar ADO.NET tradicional si tuviera un código de acceso a datos sólido que ya había escrito y quería volver a utilizar. – Matt

2

LINQ to SQL es para SQL Server. Entity Framework también es compatible con otras bases de datos.

NHibernate es una buena opción. Puede usar Castle ActiveRecord (está construido sobre NH) si está haciendo una aplicación basada en datos o Sharp Architecture para la guía del proyecto.

1

Entity Framework se integra muy bien con MVC y es compatible con otras bases de datos.

1

La respuesta corta (y no tan útil) es que los dos ORM que ha mencionado funcionarán con MVC. Una respuesta más larga es que debe pensar cómo quiere trabajar con sus objetos modelo. Por ejemplo, ¿desea hacer primero el desarrollo del objeto de dominio (a un enfoque de Diseño impulsado por dominio), o está implementando una aplicación de tipo "formularios sobre datos" en la que podría querer generar una capa de acceso a datos desde un db existente? ¿Cuál es su preferencia para especificar mapeos? ¿Desea utilizar una interfaz fluida o está satisfecho con los archivos de mapeo (o los atributos en los objetos de su dominio)?

Estos son el tipo de preguntas que debe investigar al elegir un ORM, y son en su mayoría independientes de si está utilizando MVC o Winforms.

6

Como alguien que acaba de cambiar de LINQ to SQL a (Fluido) NHibernate, he aquí algunas cosas que he notado.

  1. LINQ a     SQL tomó tanto tiempo para encontrar la manera de hacer el equivalente de un join-subclase. Después de muchas modificaciones, leí en algún lado que no es posible. Solo puede asignar herencia si TODAS las columnas están en esa misma tabla. Esto es genial si hay algunas columnas, pero hay toneladas en mi caso y las subclases son padres de otras sub clases, y así sucesivamente. ¿Por qué debería ponerlos todos en una sola tabla por el bien de mi ORM?

  2. NHibernate de la experiencia ha sido robusto (a veces demasiado para pequeños proyectos rápidos) y aunque familiarizado con él a través de proyectos pequeños, sentí que podría ser demasiado y fui la ruta de LINQ  -  SQL ya que podría generar un archivo DBML y listo dentro de minutos.

  3. Fluido NHibernate. Toma lo mejor de ambos mundos (en mi caso). Puedo mapear de la manera que quiero y tener mi base de datos de la manera que quiero y no tener que comprometer mi dominio o mis modelos de datos. También una palabra: Automapping ... icing on the cake.

habría tenido que ir con otro ORM Una vez que encontré limitaciones y golpear algunas baches en la carretera con LINQ     a SQL, pero Fluido NHibernate hecho esta elección fácil, y no creo que voy déjalo a menos que ocurra algo que haga el trabajo aún mejor.

Entonces, como dijo Rob Scott, la pregunta es ¿cómo estás abstrayendo tu dominio => modelo de datos? ¿Y comienzas con un dominio o una base de datos? ¿Cuán complejas son las relaciones? Si tienes algo de herencia, diría que solo vas con un marco de ORM más rico y te ahorres el dolor.

Fluido NHibernate tiene la mejor documentación que he encontrado y hay mucho apoyo, notas, blogs y recursos. Odio a mí mismo hacer cualquier cosa menos ... ¡OMI! Estaba funcionando en menos de 24 horas.

Ah, y si eres nuevo en NHibernate, elige el libro NHibernate in Action para ayudar a engrasar las ruedas, aunque también hay mucha ayuda para ese marco.

La mejor indicación de que una herramienta no funciona es cuando tienes que TRABAJAR con la herramienta ... LINQ   a   SQL Estaba personalizando, leyendo documentos, todo tipo de locura y se negó a generar consultas apropiadas, justo cuando tuve la tentación de modificar mi mesa y mi dominio, dije: déjeme darle un giro a Fluido, y estoy feliz de haberlo hecho.

Buena suerte para ti ... Perdón por la larga respuesta; esto ha sido todo en los últimos cinco o más días, así que creo que todavía estoy atrapado :-)

+2

Este es exactamente el tipo de experiencia que estaba buscando para aprender. Tiendo a pensar en el modelo de dominio - no db.La herramienta ORM que creamos internamente maneja bien la herencia en varias tablas, así que estoy acostumbrado a tenerla disponible. Parece que mi elección de seguir con fluidez nHibernate fue la correcta. –

+0

5x1llz: ¿Por qué es preferible un tipo de infraestructura/tecnología de acceso a los datos en lugar de otro en el desarrollo ASP.NET MVC? Pensé que ASP.NET MVC no hace suposiciones (ni tiene ningún sesgo) sobre el tipo de acceso a datos utilizado. Dado que el acceso a los datos está ocurriendo en alguna parte del Modelo, podría utilizar ADO.NET tradicional si tuviera un código de acceso a datos sólido que ya había escrito y quería volver a utilizar. – Matt

+0

También encontré que el Fluent es actualmente la mejor solución disponible. :) @Matt, MVC realmente no hace suposiciones, pero aún así, un ORM puede ser más conveniente que otro. – Venemo

0

Entity Framework hace las cosas complejas. Use NHibernate con Fluent, con patrón Repository y inversion of control en controladores.

NHibernate hará que todo sea más fácil. Recientemente hemos migrado de Entity Framework a Fluent Nhibernate, y Fluither NHibernate es definitivamente el mejor candidato.

Cuestiones relacionadas