Pregunta

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 respuesta buena, pero proporcionaré algunas pautas sobre lo que estoy buscando. En 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 debo seguir ese camino o usar uno de los marcos existentes. Los criterios que estoy buscando, en orden de importancia son:

  1. El código del cliente debe funcionar con objetos limpios, sin conocimiento de la base de datos. Al usar 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 (); detalle.Producto = producto; // Otras propiedades

    // Confirma 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. Las relaciones de uno a muchos y de muchos a muchos deben manejar la herencia, el soporte para la carga perezosa.
  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 necesita mucho esfuerzo.
  2. Entity Framework de ADO.NET: no tengo 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. nHibernar: parece una buena opción, pero algunos usuarios reportan demasiados errores arcaicos.
  5. SubSonic: de una breve introducción, parece demasiado flexible. No quiero eso.

¿Qué sugerirás?

EDIT:

Gracias Craig por la respuesta elaborada. Creo que ayudará más 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 el Los conjuntos de datos y las consultas de escritura que necesita allí.
  2. Crea un archivo de configuración XML que especifica cómo se asignan las tablas de DataSet a los objetos y también especifica las asociaciones entre ellos (compatibilidad con todos los tipos de asociaciones). 3.Una herramienta personalizada analiza la configuración XML y genera el código necesario. 4. Las clases generadas se heredan de una clase base común.

Para ser compatible con nuestro marco, la base de datos debe cumplir con 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 una sola tabla. 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 de base de datos.
  • Soporte más robusto para las jerarquías de herencia.
  • Integración opcional con LINQ.

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

¿Fue útil?

Solución

  

Mejore nuestro marco actual: el problema es que necesita mucho esfuerzo

En tu pregunta, no has dado una razón por la que deberías reescribir la funcionalidad que está disponible en tantos 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.

  

Entidad Framework ADO.NET

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

Entity Framework y NHibernate adoptan enfoques claramente diferentes al problema de salvar la brecha relacional entre el objeto. He escrito sobre esto con más detalle en esta publicación de blog . Debe considerar qué enfoque tiene más sentido para usted.

Ha habido muchos comentarios sobre el Entity Framework, tanto positivos como negativos. Algunos de ellos están bien fundados y algunos parecen provenir de personas que están impulsando otras soluciones. Las críticas bien fundadas incluyen

  • Falta de soporte de POCO. Esto no es un problema para algunas aplicaciones, es un problema para otras. 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 extrañar el bosque por los árboles. Es decir, hablan de características distintas a la funcionalidad esencial de la asignación relacional de objetos, que Entity Framework nos ha demostrado que funciona 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.

  

nHibernar: parece una buena opción, pero algunos usuarios reportan demasiados errores arcaicos.

Bueno, lo bueno de NHibernate es que hay una comunidad muy dinámica a su alrededor, y cuando encuentra esos errores esotéricos (y créame, el Entity Framework también tiene su parte de errores esotéricos; parece que viene con El territorio) a menudo se pueden 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, así que voy a dejar que otras personas con experiencia más 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 un ORM, y los usuarios de SubSonic tienen la opción de elegir una implementación de ORM diferente en lugar de utilizar ActiveRecord de SubSonic. Como marco de una aplicación web, lo consideraría. Sin embargo, su función ORM no es su razón de ser, y creo que es razonable sospechar que la parte ORM de SubSonic recibirá menos atención que los marcos ORM dedicados.

Otros consejos

LLBLGen es una muy buena herramienta ORM que hará casi todo lo que necesitas.

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

Objetos de persistencia de Developer Express o XPO como es más conocido. Lo uso durante 3 años. Proporciona todo lo que necesita, excepto que es comercial y se vincula con otra (única empresa) para su desarrollo. Aparte de eso, Developer Express es uno de los mejores proveedores de componentes y marcos 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();
}

Sugiero que echen un vistazo a ActiveRecord from Castle No tengo experiencia en producción con eso, solo he jugado con su aplicación de muestra. Parece muy fácil trabajar con él, pero no lo conozco lo suficiente como para saber si cumple con todos sus requisitos

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top