¿Cuáles son los criterios para evaluar un ORM para .NET? [cerrado]

Estoy buscando evaluar ORM.

He usado SubSonic , Linq-to-SQL y Entity Framework . Tengo un equipo de desarrolladores que van desde juniors hasta seniors.

¿Cuáles son los criterios para evaluar un ORM para .NET?

Es una pregunta cargada.
Hay muchos ORM muy buenos que abordan el tema con diferentes filosofías.
Ninguno es perfecto y todos tienden a volverse complejos tan pronto como te desvías de su camino dorado (y a veces incluso cuando te apegas a él).

Lo que debe preguntarse al seleccionar un ORM:

1. ¿Qué necesita hacer por ti?
   Si ya tiene un conjunto de requisitos para su aplicación, debe seleccionar el ORM que mejor se ajuste a estos en lugar de un "mejor" hipotético.

2. ¿Sus datos son compartidos o solo locales?
   Gran parte de la complejidad de ORM se debe a la forma en que manejan la concurrencia y los cambios en los datos de la base de datos cuando varios usuarios tienen versiones de los mismos datos.
   Si su almacén de datos es para un solo usuario, entonces la mayoría de los ORM harán un buen trabajo. Sin embargo, hágase algunas preguntas difíciles en un escenario multiusuario: ¿cómo se maneja el bloqueo? ¿Qué sucede cuando elimino un objeto? ¿Cómo afecta a otros objetos relacionados? ¿Está el ORM trabajando cerca del metal del backend o está almacenando muchos datos en caché (mejorando el rendimiento a expensas de aumentar el riesgo de estancamiento)?

3. ¿El ORM está bien adaptado para su tipo de aplicación? Puede ser difícil trabajar con un ORM en particular (mucha sobrecarga de rendimiento, difícil de codificar) si se usa en un servicio o se encuentra dentro de una aplicación web. Por el contrario, puede ser excelente para aplicaciones de escritorio.

4. ¿Tiene que renunciar a mejoras específicas de la base de datos?
   Los ORM tienden a utilizar el conjunto de denominador común más bajo de SQL para asegurarse de que funcionan con muchos backend de bases de datos diferentes.
   Todos los ORM comprometerán las características disponibles (a menos que se dirijan específicamente a un único backend), pero algunos le permitirán implementar comportamientos adicionales para explotar mejoras específicas disponibles en el backend elegido.
   Una mejora típica específica de db son las capacidades de búsqueda de texto completo, por ejemplo; asegúrese de que su ORM le brinde una forma de acceder a estas funciones si las necesita.

5. ¿Cómo gestiona el ORM los cambios en el modelo de datos?
   Algunos pueden actualizar la base de datos automáticamente dentro de cierta medida, otros no hacen nada y usted mismo tendrá que hacer el trabajo sucio; otros proporcionan un marco para manejar el cambio que le permite controlar las actualizaciones de la base de datos.

6. ¿Piensa acoplar su aplicación a los objetos de ORM o prefiere manejar POCO y usar un adaptador para persistencia?
   El primero es generalmente fácil de manejar, pero crea dependencias en sus objetos de datos específicos de ORM en todas partes, el último es más flexible, a costa de un poco más de código.

7. ¿Alguna vez necesitarás transferir tus objetos de forma remota?
   No todos los ORM son iguales cuando se trata de recuperar objetos de un servidor remoto, observe de cerca lo que es posible o imposible de hacer. Algunos son eficientes, otros no.

8. ¿Hay alguien a quien puedas recurrir para pedir ayuda?
   ¿Hay buen soporte comercial? ¿Qué tan grande y activa es la comunidad alrededor del proyecto?
   ¿Cuáles son los problemas que los usuarios existentes tienen con el producto?
   ¿Obtienen soluciones rápidas?

Algunos ORM que miré:

• XPO del
  desarrollador Express: es pequeño y simple, centrado en el código. Lo usan para su marco de aplicación eXpressApp .
• NHibernate
  es gratis, pero la curva de aprendizaje es bastante empinada. Muchas cosas buenas, pero a veces es difícil encontrar lo que es realmente relevante en toda la documentación fragmentada.
• 
  Proyecto muy maduro de LLBLGen Pro , no el más simple pero se ha pensado mucho en él.
• Entity Framework
  GEtting there. Los últimos lanzamientos son bastante buenos y MS está escuchando, aunque todavía es un poco joven en comparación con otros ORM más maduros.
• DataObject.Net
  parece prometedor, pero también es un poco nuevo para arriesgar un proyecto importante en mi humilde opinión. Aunque bastante activo.

Hay muchos otros, por supuesto.

Puede echar un vistazo al controvertido sitio ORM Battle que enumera algunos puntos de referencia de rendimiento, aunque debe tener en cuenta que la velocidad bruta no es necesariamente el factor más importante para su proyecto y que los productores del sitio web son DataObject.Net.

Estoy usando NHibernate y lo he encontrado bastante bueno.

En mi caso, vinculado a una base de datos MS SQL, pero puede conectarse a otras bases de datos.

No tarda mucho en ponerse en marcha, simplemente asigne su objeto al modelo; uso un archivo xml pero puede hacerlo con fluidez en el código. Hay una gran comunidad, y personalmente he encontrado que el trabajo de Ayende es muy útil: uso NHProf, que es una herramienta de creación de perfiles sql.

Principalmente uso las funciones listas para usar: mapeo directo de objetos, pero también uso el lenguaje de consulta Hibernate, que es bastante fácil de conseguir.

Lamentablemente, en mis últimos tres trabajos, tuvimos tres ORM locales. En cada caso, apestaron principalmente por diferentes razones.

Recientemente he estado evaluando Entity Framework 4 y su soporte POCO (un buen tutorial está aquí ) y estoy realmente impresionado por lo bien que se mantiene fuera de mi rostro y me hace sentir que estoy programando nuevamente en lugar de reunir datos.

Comparación de ORM y puntos de referencia en ORMBattle.NET

Me gusta mucho Linq to Sql. Es simple y tiene un diseñador decente. Sin embargo, espero terminarlo a favor del marco de Entity. Me gustaría poder aprovechar la capacidad de modificar los generadores para poder tener objetos personalizados.

El mayor beneficio que tienen sobre otros (en mi opinión) es que están listos para usar con VS. Esto también es negativo en el sentido de que está a merced de MS (consulte Linq to Sql).

[RENUNCIA: Trabajo para DevExpress]

Puede ver capturas de pantalla de aplicaciones típicas creadas por los marcos de aplicaciones DevExpress aquí . Esta página también contiene una breve reseña de nuestros productos. Para obtener información más detallada sobre por qué , le sugiero que consulte las respectivas páginas de productos en nuestro sitio web.

En cuanto a DevExpress XAF y XPO, aquí hay una buena explicación sobre por qué elegir nuestros marcos de aplicación. Además, brindamos soporte y documentación, lo cual también es importante y vale la pena mencionar. No dude en contactarnos en caso de cualquier pregunta.

Utilizamos NHibernate + NHibernate fluido, con Linq-to-Sql en pequeños proyectos. La razón de esto es:

1) (No es la razón principal) NHibernate parece tener un mayor factor de "respeto" entre los desarrolladores (¿es esto cierto?),

2) En comparación con linq-to-SQL, nHibernate permite el mapeo ORM entre objetos Db y entidades que no mapean 1-a-1,

3) No hemos comparado ampliamente nHibernate con Entity Framework 4.0, pero aquí hay una buena comparación: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate tiene una curva de aprendizaje bastante pronunciada y sus mapas XML pueden ser bastante detallados, pero comience con la documentación del sitio Fluent Nhibernate y avance hacia atrás.

No existe un "mejor" marco ORM porque todos tienen diferentes combinaciones de fortalezas y debilidades y tiende a ser el caso de que si los desarrolladores eligen enfocarse en mejorar un área, hay otras áreas que sufren en comparación (código primero vs modelo primero vs base de datos primero).

Hay, por otro lado, una serie de muy buenas, algunas de las cuales se adaptarán mejor a sus circunstancias personales y filosofía que otras.

Editar: para lo que vale, actualmente estoy usando Linq to SQL, principalmente porque está allí, aunque en parte porque hace mucho bien por un esfuerzo mínimo y probablemente progresará a Entity Framework nuevamente "porque está allí" (aunque de manera similar también hay mucho sobre EF4 que está bien, así como algunas cosas que están mal). La preocupación, especialmente con este último, tendría que ser el rendimiento, pero para la mayoría de mis casos eso no es un gran problema y la capacidad de ejecutar Dynamic Data y OData desde los modelos (L2S y EF) tiene beneficios considerables para mí en términos de " barato "gana.

Le aconsejaría que eche un vistazo a DevExpress XPO . Esto junto con DevExpress XAF facilitará la vida de cualquier desarrollador una vez que se cruce su curva de aprendizaje.

Hemos tenido buena suerte con Entity Framework. Sin embargo, nuestra situación es algo inusual: recopilamos datos para el equipo de informes, por lo que en realidad diseñan la base de datos. Obtenemos el DB y luego usamos EF para generar las clases de acceso a datos a partir de él. Funciona muy bien para nosotros, pero solo hacemos cargas de datos masivas, por lo que no puedo garantizar lo bien que funciona en un entorno más transaccional.

NHibernate (+ FluentNHibernate) sería la opción predeterminada para mí. Es muy flexible, extensible y robusto. Tiene una gran cantidad de usuarios y se mantiene de forma muy activa. La desventaja es la curva de aprendizaje empinada.

LightSpeed ​​de MindScape es simple y fácil de usar, pero sigue siendo bastante flexible y capaz. Tiene una superficie de diseño como L2S / EF y una implementación de UnitOfWork.

Bueno, no hay una "mejor" opción, pero diría que el viejo Linq to SQL normal satisface sus necesidades. No es un ORM "verdadero" per se, pero es muy liviano y le brinda la flexibilidad de escribir código sin darse cuenta, si eso tiene sentido. Lo que quiero decir es que puedes continuar escribiendo código de manera normal, sin tener que estar realmente al tanto de Linq que no sea tener los dbmlarchivos. Todavía puede escribir abstracciones sobre él, utilizando los patrones de repositorio o puerta de enlace, y L2S cumple la función principal de un ORM, que consiste en sortear la discordancia de relación de objeto.

Entity Framework es un poco pesado, y aunque solo he incursionado un poco, es más "en tu cara" que Linq a Sql básico, pero EF es mucho más un verdadero ORM que Linq. Vería todos los criterios que está buscando en un ORM. ¿Es solo porque quiere evitar tener que escribir SQL sin formato o, lo que es peor, tener cientos de procedimientos almacenados? ¿Necesita algunas características adicionales que Linq to Sql sin procesar no puede proporcionar? Debe responder esas preguntas, pero según su breve requisito ("ligero y fácil de usar"), creo que Linq es un poco más fácil que algo como Subsonic y está integrado en Visual Studio.

ECO :) Es mucho más que un ORM e incluye máquinas de estado y soporte ejecutable de OCL (es decir, EAL). Existe una versión gratuita con una limitación de 12 clases de dominio que creo que debería ser bastante buena para pequeños proyectos.