Al elegir un ORM, ¿es LINQ to SQL o LINQ to Entities mejor que NHibernate?

Question

Me parece que puedo hacer más con NHibernate, e incluso Castle que con Linq to Entities, o linq to SQL.

¿Estoy loco?

Answer 1

No, no estás loco. nHibernate es un OR Mapper completo, Linq to SQL y Linq to Entities no implementan todo lo que esperarías de un correlacionador OR y están dirigidos a un grupo ligeramente diferente de desarrolladores.

Pero no dejes que eso te desanime. LINQ sigue siendo una muy buena idea .. Trate de LINQ to NHibernate :-)

Answer 2

Los grandes inconvenientes a NHibernate, Castillo, etc., es que no son exactamente ligero (especialmente NHibernate.)

Linq to SQL es bueno para un ORM liviano y de uso limitado.

Answer 3

Una cosa a tener en cuenta es que NHibernate puede ser un cerdo para configurar, especialmente porque está basado principalmente en archivos de configuración XML debido a sus raíces como el Hibernate original.

Fluent NHibernate hace que esto sea menos doloroso.

Sin duda, Linq encaja con la 'manera' general en que funciona .NET.

Answer 4

He usado NHibernate y LINQ to SQL. Desde mi punto de vista, depende del proyecto, si necesito algo rápido, elegiría L2S, es tan simple crear la asignación de dbml y comenzar a usarla. Si estoy desarrollando una solución empresarial de más alto nivel, optaría por la probada y confiable ORM - NHibernate. Las operaciones de registro & me parecen fáciles de usar.

LINQ to SQL tiene una curva de aprendizaje relativamente corta, NHibernate tiene una curva de aprendizaje mucho más pronunciada.

LINQ to SQL solo es compatible con SQL Server, por lo que si tiene una base de datos Oracle, entonces la decisión ya está tomada - NHibernate.

Recomiendo consultar http://www.summerofnhibernate.com/ para obtener excelentes capturas de pantalla para aprender NHibernate.

Answer 5

No he probado Entity Framework, pero definitivamente recomendaría NHibernate sobre Linq a SQL; La razón más grande que puedo dar es solo el control. A Linq to SQL le gusta tener mucho más control sobre todo, cargar el objeto y mantener todo tipo de información de seguimiento sobre el objeto. Si serializa/deserializa, la información de seguimiento puede perderse y pueden ocurrir cosas extrañas al guardarla nuevamente. NHibernate funciona más como un repositorio: usted le entrega el objeto que desea (que lo haya configurado para que lo entienda, por supuesto) y lo guarda en la base de datos, independientemente de lo que haya hecho con él.

Answer 6

cita en bloque LINQ aunque ciertamente encaja con el 'camino' general en el que funciona .NET

Ay, este tipo de sentimiento me asusta. El material RAD incorporado en .net NO es cómo funciona dot net, es solo un conjunto de herramientas para generar prototipos. .NET nos permite hacer aplicaciones completas de DDD, con altos niveles de cohesión, separaciones de preocupaciones, y nos permite escribir código desacoplado, a pesar de todos los intentos que hacemos para juntar cosas. Estoy totalmente en desacuerdo con que a .net le guste estar acoplado, a las herramientas certian les gusta estar acopladas, incluiré linq a sql en esta refriega. linq to sql destruye la idea de tener un modelo de dominio separado.Me estremezco ante la idea de utilizar mi esquema de base de datos como objetos del modelo subyacente. Las herramientas adecuadas de ORM deberían permitirnos modelar nuestro dominio primero, luego vincular nuestra base de datos relacional a estos modelos. No de la otra manera.