Recomiende .NET ORM para desarrollo de N niveles

Question

Necesito elegir cuidadosamente .NET ORM para aplicaciones de N niveles. Eso significa que tendré el servidor (servicio WCF), que expone los datos, y el cliente, que lo muestra. El ORM debe soportar todos los problemas de serialización relacionados sin problemas: los objetos o colecciones de objetos, o lo que sea, deben viajar a través de los límites del proceso. Idealmente, el uso en el entorno de multiprocesos debería ser el mismo que en un solo proceso.

Los criterios son:

1. flexibilidad de asignación de esquema db a los objetos (preferidos)
2. facilidad de uso
3. libre, de código abierto (preferido)
4. debe ser adecuado para N-tier (aplicaciones multidominio multiproceso)
5. Rendimiento
6. Herramientas para integrar con Visual Studio (preferido)
7. Testabilidad
8. Adopción, disponibilidad de documentación
9. Amplia gama de RDBMS compatibles (preferido; estamos usando MSSQL, pero no me gustaría estar atado a ella)
10. DB agnóstico - DB diferente, misma API

Answer 1

Recomendaría Entity Framework v4. Se ha mejorado dramáticamente desde allá v1, y es compatible con todo lo necesario, excepto ser de código abierto:

1. EF es compatible con una amplia variedad de asignaciones, incluyendo TPH, TPT, y TPC. Admite la asignación POCO, lo que le permite mantener su lógica de persistencia separada de su dominio.
2. EF cuenta con un amplio y excelente soporte para LINQ, lo que proporciona una consulta verificada de su modelo fácil de usar y en tiempo de compilación. Los componentes EF Futures como Code-Only simplifican aún más el trabajo con EF, ya que proporcionan un código puro, verificación de tiempo de compilación y una API fluida para definir su modelo. Al optar por la convención en lugar de la configuración, Code-Only puede reducir radicalmente el tiempo de diseño de su modelo, lo que le permite comenzar a trabajar sin tener que lidiar con un modelo visual y múltiples archivos de mapeo XML.
3. Es libre como parte de .NET 4. (En este momento, la preferencia Open Source no puede ser conocido aquí.)
4. EF proporciona una excelente OOB solución N-Tier través self-tracking entities
   • Self-información de seguimiento utiliza un formato xml abierto para transferir datos de seguimiento, por lo que el soporte de seguimiento podría agregarse a no-.plataformas NET
5. Rendimiento de EF v4 es muy bueno, tan extenso trabajo fue realizado en el generador de consultas
   • Véase el ADO.NET Blog entry sobre el tema
6. EF ofrece extremadamente ricas herramientas de diseño visual, y permite una amplia personalización de la generación de código a través de T4 templates and workflows
7. EF v4 introdujo numerosas interfaces, incluyendo las interfaces IObjectSet<T> y IDbSet<T>, que g Mejorar la capacidad de prueba de sus contextos personalizados
8. EF v4 es una parte integral de .NET 4 y un componente central de todas las iniciativas de datos actuales y futuras de Microsofts. Como parte de .NET, su documentación es bastante extensa: MSDN, EFDesign Blog, ADO.NET Blog, docenas de .NET y sitios de programación y blogs proporcionan una gran cantidad de documentación y soporte para la plataforma.

Answer 2

Por qué no pruebas NHibernate?

Answer 3

Otro voto para EF aquí.

• Unidad fácilmente comprobable de la unidad. Puede escribir sus propias Entidades de Dominio y hacer que estén razonablemente libres de conocimiento de persistencia usando POCO approach. A continuación, puede simular la interfaz de la base de datos y probar la lógica de la aplicación sin una base de datos real.

• Admite LINQ para que si escribe su LINQ correctamente, solo traduzca una sola instrucción SQL que se envíe al servidor.

Answer 4

He estado usando un producto llamado LightSpeed, funciona muy bien y se integra sin problemas en Visual Studio 2010 & 2008. He estado usando con SQLite, sin embargo, compatible con numerosos RDBMS. También tiene una característica muy agradable que le permite crear objetos POCO que se pueden usar con WCF, ¡ahorrando tiempo! Al principio estaba usando la versión Express gratuita, pero pronto me actualicé.

LightSpeed ​​es el mejor modelado de dominio .NET de alto rendimiento y el marco de mapeo O/R disponible. Soporte LINQ de primera clase, Visual Studio 2008 & integración de diseñador de 2010 y nuestro famoso marco central de alto rendimiento significa que puede crear modelos ricos en dominios impulsados ​​de forma más rápida y fácil que nunca.

Answer 5

Después de haber trabajado con lo siguiente:

• NHibernate

• Marco LLBLGen

• Entidad

• LINQ a SQL

• DataObjects.Netos

• OpenACCESS

• DataTables

que pueden sin duda dicen que son superiores tablas de datos ... no es broma. Todos ellos tienen sus fortalezas y debilidades.

Principalmente, he encontrado que estos puntos fuertes y wekanesses están asociados con el tipo general de ORM, que cae en las dos categorías siguientes

• Heavy-peso

  • LLBLGen, OpenAccess , Entity Framework (pre 4.0), DataObjects caen dentro de esta categoría. Los ORM pesados ​​suelen tener entidades y colecciones que heredan de una clase base específica del ORM (es decir, EntityBase). Estos ORM a menudo ofrecen un amplio soporte de tiempo de diseño, generación de código y funciones de tiempo de ejecución en profundidad (como seguimiento de estado, seguimiento de transacciones, mantenimiento de asociación, etc.).

  • The Pro: Un desarrollo más rápido y más sencillo aprovechando la API incorporada para interactuar con entidades en tiempo de ejecución (es decir, desde la entidad LLBLGen.Fields ["MyField"]. IsChanged o entity.IsNew o entity.Fields [" MyField "]. DbValue

  • Con: pesadez y dependencias. Con estos ORM, sus objetos comerciales ahora están vinculados directamente con la API de ORM. ¿Qué sucede si desea cambiar a otro ORM? abusando de las características avanzadas de la API de ORM para solucionar un problema simple con una solución compleja (he visto esto como una tonelada) El uso de memoria también es un gran problema con estos ORM. Una colección de más de 5000 entidades puede ocupar fácilmente 100 MB de RAM con algunos de los ORM anteriores. La serialización es otra problema. Con la pesadez de los objetos, la serialización puede ser muy lenta ... y probablemente no funcione correctamente deserializando en el otro lado del cable (WCF o .NET remoto, etc.). Las asociaciones pueden no volver a asociarse correctamente o ciertos campos pueden no conservarse. Varios de los ORM anteriores han incorporado mecanismos de serialización para mejorar el soporte y la velocidad ... pero ninguno de los que he visto ofrecen soporte completo para diferentes formatos (es decir, se obtiene soporte de serialización binario, pero no json o xml).

• ligero

  • LINQ a SQL, Entity Framework POCO, NHibernate (tipo de) entran en esta cateogry. Los ORM livianos generalmente usan POCO que usted mismo puede diseñar en un archivo en VS (por supuesto, también puede usar una plantilla T4 o un generador de códigos).

  • The Pro: Ligero. Lo mantiene simple. Objetos comerciales agnósticos de ORM

  • The Con: Menos características, tales como maintance gráfico entidad, seguimiento de estado, etc.

Independientemente de lo que elija ORM, mi preferencia personal es ceñirse a LINQ, y ORM sintaxis de recuperación independiente (no la propia API de ORM para recuperar, si tiene una).

Con respecto a los específicos mencionados, aquí están mis breves pensamientos: - NHibernate: Detrás de los tiempos tecnológicamente sabio. Un montón de mantenimiento de archivos de mapeo xml (aunque Fluent NHibernate lo alivia).

• LLBLGen: ORM más maduro con el que he trabajado. Es fácil comenzar un nuevo proyecto y ponerse en marcha. Mejor diseñador. MUY peso pesado Rich MUY potente API. La mejor velocidad que he encontrado. Debido a que no es el nuevo niño en el bloque, algunas de las características más nuevas que aprovechan la tecnología más nueva no se implementan tan bien como deberían (LINQ específicamente).

• Entity Framework: La clase POCO en 4.0 parece prometedora. 3.5 no tiene esto y ni siquiera lo consideraría. Incluso en 4.0, no tiene un gran soporte LINQ y genera un SQL pobre (puede generar cientos de consultas DB para una única consulta LINQ). El soporte del diseñador es pobre cuando se trata de proyectos más grandes.

• LINQ to SQL: excelente soporte LINQ (mejor que cualquier otro excepto DataObjects.Net). Soporte de persistencia mediocre (guardar/actualizar). Muy ligero (POCO). El soporte del diseñador es pobre en todos lados (no hay actualización de DB). Rendimiento bajo en consultas LINQ avanzadas (puede hacer cientos de consultas DB)

• DataObjects.Net: Soporte y rendimiento realmente excelentes de LINQ. Ofrece lo más parecido que he visto a POCO en un ORM pesado. Una tecnología realmente nueva, poderosa y prometedora. Muy flexible.

• OpenAccess: No he trabajado mucho, pero me recuerda un poco a LLBLGen, pero no como una característica rica o madura.

• tablas de datos: No comment

Answer 6

Después de haber utilizado OpenAccess en varios proyectos, hay que decir que cumple con todos los criterios anteriores. Un sistema en el que trabajé estaba basado en servicios de WCF que hablaban con varios tipos de clientes (inteligente, web, otros servicios de WCF, etc.). A través de una arquitectura en capas, los servicios de WCF usaban OpenAccess como mecanismo de persistencia. Me gusta especialmente la escala que OpenAccess realiza ... La memoria caché inteligente de Nivel 2 (caché L2) hace un trabajo perfecto allí y es de causa distribuible. En realidad, yo no llamaría mucho a OA ... Ni siquiera heredas de una clase base. También es una gran ventaja que haya herramientas para realizar las tareas diarias del desarrollador (crear un nuevo esquema de base de datos, combinar esquemas, etc.) integradas en Visual Studio.

Answer 7

Acerca de EF4 ... No lo utilice en un proyecto grande, con muchas tablas y muchos datos y muchos usuarios. Cometí este error y ahora estoy buscando un reemplazo.

1-Mala generación de consultas, especialmente en grandes jerarquías TPT. ¡Prepárese para una consulta de 5000 líneas para una jerarquía de 15 tablas!

2-Diseñador extremadamente lento cuando crece el número de tablas. 45 segundos solo para colapsar/expandir una entidad en un modelo con 240 entidades.

3-Problema grave con relaciones x-to-many. Supongamos que tiene Order y Customer entidad. Cada orden tiene un cliente y cada cliente tiene muchas órdenes. Hay una propiedad, llamada Orders en la clase Customer que se completará sin que realmente necesite esa información. Esto significa, en nuestro sistema, que las colecciones de hasta 1800000 entidades se obtienen sin ningún motivo real.Cuando esto ocurre dentro de una transacción con el nivel de aislamiento de instantáneas ... eso hace que todo el sistema falle. No existe una solución real a este problema, que no tenga inconvenientes serios. Simplemente lea la documentación de DataObjects.Net y vea cómo han solucionado este problema. Descubrí que pagar 200 o 500 euros no es nada comparado con lo que obtienes. Incluso puedo obtener la versión con el código fuente.

Si no puedo integrar mi sistema con DO.Net, buscaré otro, pero esto de EF, ¡tiene que irse!