it-swarm-es.com

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

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?

30
Nickz

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 usted?
    Si ya tiene un conjunto de requisitos para su aplicación, entonces debe seleccionar el ORM que mejor coincida con estos en lugar de un "mejor" hipotético.

  2. ¿Sus datos se comparten o son solo locales?
    Gran parte de la vellosidad en 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 una versión 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? Un ORM en particular puede ser difícil de trabajar (mucha sobrecarga de rendimiento, difícil de codificar) si es usado en un servicio o sentado 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 es la capacidad 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 del ORM o prefiere manejar POCO y usar un adaptador para la 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á transferir sus 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 es difícil encontrar lo que es realmente relevante a veces en toda la documentación fragmentada.
  • LLBLGen Pro
    proyecto muy maduro, no el más simple pero se ha pensado mucho en él.
  • Entity Framework
    Llegar allí. 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 sitio controvertido 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 es DataObject.Net.

43
Renaud Bompuis

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 toma mucho tiempo comenzar a funcionar, 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.

14
Sam J

Lamentablemente, en mis últimos tres trabajos, tuvimos tres ORM locales. En cada caso, en su mayoría apestaron por diversas razones.

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

6
Jesse C. Slicer
6
Amir Rezaei

[DESCARGO DE RESPONSABILIDAD: Trabajo para DevExpress]

Puede ver capturas de pantalla de aplicaciones típicas creadas por los marcos de aplicación 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í es una buena explicación de 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.

3
Dennis Garavsky

Me gusta mucho Linq to Sql. Es simple y tiene un diseñador decente. Sin embargo, espero terminarlo en 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 estos tienen sobre los demás (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 la EM (consulte Linq to Sql).

3
Jeremy Roberts

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.

2
fjxx

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 puede continuar escribiendo código de manera normal, sin tener que estar realmente al tanto de Linq que no sea tener los archivos dbml. 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 básico a Sql, 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 a 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.

1
Wayne Molina

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.

1
Yogi Yang 007

No hay 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 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.

1
Murph

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.

1
TMN

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.

1
rmac

ECO :) Es mucho más que un ORM e incluye máquinas de estado y soporte OCL ejecutable (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.

0
William