linq - Marco de persistencia?

nhibernate ado.net

Question

Estoy tratando de decidir la mejor estrategia para acceder a la base de datos. Entiendo que esta es una pregunta genérica y no hay una sola buena respuesta, pero proporcionaré algunas pautas sobre lo que estoy buscando. Los últimos años hemos estado utilizando nuestro propio marco de persistencia, que aunque limitado también ha servido. Sin embargo, necesita algunas mejoras importantes y me pregunto si debería ir por ese camino o utilizar uno de los marcos existentes. Los criterios que estoy buscando, en orden de importancia son:

1. El código del cliente debería funcionar con objetos limpios, ancho sin conocimiento de la base de datos. Al utilizar nuestro marco personalizado, el código del cliente se ve así:

   SessionManager session = new SessionManager (); Orden de pedido = session.CreateEntity (); order.Date = DateTime.Now; // Establecer otras propiedades OrderDetail detail = order.AddOrderDetail (); detail.Product = producto; // Otras propiedades

   // Confirmar todos los cambios ahora session.Commit ();

2. Debería ser lo más simple posible y no "demasiado flexible". Necesitamos una forma única de hacer la mayoría de las cosas.

3. Debería tener un buen soporte para la programación orientada a objetos. Debe manejar las relaciones uno a muchos y muchos a muchos, debe manejar la herencia, compatibilidad con la carga diferida.
4. Se prefiere que la configuración esté basada en XML.

Con mi conocimiento actual veo estas opciones:

1. Mejore nuestro marco actual. El problema es que requiere un gran esfuerzo.
2. ADO.NET Entity Framework: no tiene una buena comprensión, pero parece demasiado complicado y tiene malas críticas.
3. LINQ to SQL: no tiene un buen manejo de las prácticas orientadas a objetos.
4. nHibernate: parece una buena opción, pero algunos usuarios informan demasiados errores arcaicos.
5. SubSonic: a partir de una breve introducción, parece demasiado flexible. No quiero eso.

¿Qué vas a sugerir?

EDITAR:

Gracias Craig por la elaborada respuesta. Creo que será más útil si doy más detalles sobre nuestro marco personalizado. Estoy buscando algo similar. Así es como funciona nuestro marco personalizado:

1. Se basa en DataSets, por lo que lo primero que debe hacer es configurar los DataSets y escribir las consultas que necesita allí.
2. Se crea un archivo de configuración XML que especifica cómo las tablas de DataSet se asignan a los objetos y también se especifican las asociaciones entre ellos (soporte para todo tipo de asociaciones). 3.Una herramienta personalizada analiza la configuración XML y genera el código necesario. 4. Las clases generadas heredan de una clase base común.

Para ser compatible con nuestro marco, la base de datos debe cumplir estos criterios:

1. Cada tabla debe tener una sola columna como clave principal.
2. Todas las tablas deben tener una clave principal del mismo tipo de datos generado en el cliente.
3. Para manejar la herencia, solo se admite la herencia de tablas únicas. También el archivo XML, casi siempre ofrece una única forma de lograr algo.

Lo que queremos apoyar ahora es:

• Eliminar la dependencia de DataSets. El código SQL debe generarse automáticamente, pero el marco NO debe generar el esquema. Quiero controlar manualmente el esquema DB.
• Soporte más robusto para jerarquías de herencia.
• Integración opcional con LINQ.

Espero que ahora esté más claro lo que estoy buscando.

Answer 1

Mejore nuestro marco actual. El problema es que necesita una gran cantidad de esfuerzo

En su pregunta, no ha explicado por qué debe volver a escribir la funcionalidad que está disponible en muchos otros lugares. Sugeriría que reinventar un ORM no es un buen uso de su tiempo, a menos que tenga necesidades únicas para el ORM que no haya especificado en su pregunta.

ADO.NET Entity Framework

Estamos utilizando Entity Framework en el mundo real, software de producción. ¿Complicado? No más que la mayoría de los otros ORM, por lo que puedo decir, es decir, "bastante complicado". Sin embargo, es relativamente nuevo y, como tal, hay menos experiencia y documentación en la comunidad que NHibernate. Entonces, la falta de documentación puede hacer que parezca más complicado.

El Entity Framework y NHibernate toman enfoques claramente diferentes del problema de tender un puente sobre la división objeto-relación. He escrito sobre eso con un poco más de detalle en esta publicación de blog . Debería considerar qué enfoque tiene más sentido para usted.

Ha habido una gran cantidad de comentarios sobre el Marco de la Entidad, tanto positivos como negativos. Algunos de ellos están bien fundamentados, y algunos de ellos parecen provenir de personas que están impulsando otras soluciones. Las críticas bien fundadas incluyen

• Falta de soporte POCO. Esto no es un problema para algunas aplicaciones, es un problema para otros. El soporte de POCO probablemente se agregará en una versión futura, pero hoy, lo mejor que puede ofrecer Entity Framework es IPOCO.
• Un archivo de mapeo monolítico. Esto no ha sido un gran problema para nosotros, ya que nuestros metadatos no están en constante cambio.

Sin embargo, algunas de las críticas me parecen perder el bosque por los árboles. Es decir, hablan de funciones distintas de la funcionalidad esencial del mapeo relacional de objetos, que el Marco Entity nos ha demostrado que lo hace muy bien.

LINQ to SQL: no tiene un buen manejo de las prácticas orientadas a objetos

Estoy de acuerdo. Tampoco me gusta el enfoque de SQL Server.

nHibernate: parece una buena opción, pero algunos usuarios informan demasiados errores arcaicos.

Bueno, lo bueno de NHibernate es que hay una comunidad muy vibrante a su alrededor, y cuando encuentras esos errores esotéricos (y créeme, el Entity Framework también tiene su cuota de errores esotéricos, parece venir con el territorio) a menudo puede encontrar soluciones muy fácilmente. Dicho esto, no tengo mucha experiencia personal con NHibernate más allá de la evaluación que hicimos, lo que nos llevó a elegir el Entity Framework, por lo que voy a permitir que otras personas con más experiencia directa comenten sobre esto.

SubSonic: a partir de una breve introducción, parece demasiado flexible. No quiero eso.

SubSonic es, por supuesto, mucho más que solo un ORM, y los usuarios de SubSonic tienen la opción de elegir una implementación de ORM diferente en lugar de usar ActiveRecord de SubSonic. Como marco de aplicación web, lo consideraría. Sin embargo, su característica ORM no es su razón de ser, y creo que es razonable sospechar que la parte de ORM de SubSonic recibirá menos atención que los marcos de ORM dedicados.

Answer 2

Desarrollador Express Persistence Objects o XPO como se lo conoce. Lo uso por 3 años. Proporciona todo lo que necesita, excepto que es comercial y se relaciona con otra (única compañía) para su desarrollo. Aparte de eso, Developer Express es uno de los mejores proveedores de componentes y framework para la plataforma .NET.

Un ejemplo de código XPO sería:

using (UnitOfWork uow = new UnitOfWork())
{
Order order = new Order(uow);
order.Date = DateTime.Now();
uow.CommitChanges();
}

Answer 3

Sugiero echar un vistazo al ActiveRecord de Castle . No tengo experiencia en producción, he jugado con su aplicación de muestra. Parece realmente fácil trabajar con él, pero no lo conozco lo suficiente como para saber si se ajusta a todos sus requisitos.

Answer 4

iBATIS es mi favorito porque obtienes un mayor control sobre el SQL

Answer 5

LLBLGen hace una herramienta ORM muy buena que hará casi todo lo que necesita.