2010-02-09 10 views
8

¡¡¡Así que estoy teniendo problemas con la cabeza contra la pared y esperando que alguien pueda ayudarme ya sea a quitar la pared o evitar que se mueva la cabeza !!¿Qué tiene de bueno ORM?

En las últimas 3/4 semanas he estado investigando los ORM en preparación para un nuevo proyecto. El ORM debe mapear a una base de datos SQL existente, grande y antigua.

Así que probé Subsonic. Realmente me gustó v2 y v3 después de que el modding funcionara bien con VB y los esquemas con nombre en SQL funcionaban correctamente. Sin embargo, su falta de flexibilidad para tener nombres de propiedades de entidades separadas y nombres de columnas me hizo sacarme el pelo (lo siento, Rob).

Intenté Entity Framework pero encontré que faltan otros en ciertas áreas.

Así que mordí la bala y probé nHibernate, pero después de una semana más o menos poniéndolo en funcionamiento como me gustaba (con la ayuda de Codesmith para generar clases/hbms) estoy frustrado con el tiempo que lleva iniciarlo un objeto de configuración), a pesar de intentar una serie de trucos para reducir este tiempo.

Básicamente estoy construyendo una clase DAL que puedo compartir entre aplicaciones y sitios web. ¿Estoy ladrando el árbol equivocado? Para un proyecto heredado con cientos de tablas, ¿debería volver a ado.net y usar DTOs? ¡Aarrgh!

Perdón por el estilo de pregunta ranty. ¡No me queda mucho pelo y me gustaría conservar lo que tengo!

Gracias de antemano, Ed

PS. Debo añadir que sé SQL muy bien y no tengo miedo de ensuciarme las manos para escribir consultas rápidas. En todo caso, no es necesario que me oculté de SQL

+2

¿Qué tipo de aplicación tiene usted de manera que el tiempo de inicio nhibernate es un problema? OMI, solo debería molestarlo si accede directamente a la base de datos desde el escritorio, no en el caso de un servicio de nivel medio. –

+0

@Dmitry: tiene razón +1 –

+1

Puede simplificar este delirio simplemente preguntando "¿Cómo puedo acelerar el tiempo de inicio de una aplicación NHibernate?". –

Respuesta

8

ORM le permiten:

  1. Para asignar filas de la tabla a objetos, que son los de las piezas factibles de programación orientada a objetos.
  2. Para navegar de forma automática a través de las relaciones de objeto
  3. Para añadir, editar y eliminar filas de la tabla
  4. Para consultar la base de datos de una manera más intuitiva, ya que no tiene que pensar en une (éste dependerá de la ORM y el método de consulta)
  5. Para manejar de forma transparente caché L1 y L2.

Todo lo anterior tendría que manejarse a mano si no usaba ORM.

PD: Acepto a Dmitry en cuanto al horario de inicio de NHibernate (ver comentarios de la pregunta). Además, ¿probaste Fluent NHibernate? Fluidez NHibernate es impresionantemente fácil. No podía creer lo que veía cuando diseñé por primera vez una base de datos. Es incluso más fácil que los ORM propietarios como DevExpress XPO.

+1

+1 para recomendar FluentNHibernate. Actualmente lo está usando en un proyecto y realmente es "impresionantemente fácil". –

1

En mi experiencia, la mayoría de los ORM terminan siendo mucho más complejos que SQL. Lo cual frustra todo el propósito de usarlos.

Una solución que me entusiasma es LINQ2SQL. Se destaca como una capa delgada sobre procedimientos almacenados o vistas. Es realmente fácil de usar y no intenta ocultar SQL.

+0

Puedo simpatizar con el tema de la complejidad; la mayoría de las herramientas ORM son extremadamente complejas de configurar. Yo argumentaría que ellos resuelven una gama significativamente compleja de problemas para justificar su complejidad, y que el valor ganado al usarlos supera la pena de aprender a usarlos. –

+0

Andomar: los ORM, en general, están exponiendo objetos, no SQL. Ese es el punto. ¿Por qué estás usando un ORM si no es para mapear tablas relacionales en objetos? Quizás ADO.NET sea más adecuado para sus necesidades. –

+0

Andomar: ¿Has visto @ PLINQO? Asigné la misma base de datos con él y con Codesmith y terminé con menos errores y un tiempo de ejecución mucho más rápido, sin demoras en el inicio. – CResults

2

El mayor beneficio de una herramienta ORM es que le ayudará a capaar su aplicación correctamente. La mayoría del proyecto hoy en día usa una capa de datos para conectarse a la base de datos.Comienza desde la herramienta ORM para producir clases que corresponden a los objetos de su base de datos. Luego defines una interfaz usando estos métodos. Todo el código de persistencia usa los métodos de esta interfaz. De esta forma, la capa de lógica de negocios solo se acopla a esta interfaz de capa superior y no necesita saber nada sobre la base de datos. De hecho, no debería haber dependencia en ADO.NET o incluso NHibernate.

Otra ventaja de las herramientas ORM es que desacopla su aplicación del servidor de la base de datos. Puede cambiar el motor de db y seguir usando el mismo código. Además, no solo se oculta la complejidad del SQL que oculta el ORM. También puede ayudarlo con la lógica de transacciones y la agrupación de conexiones.

Yo diría que para los proyectos nuevos una herramienta de ORM es una necesidad. Para proyectos heredados, no es tan beneficioso, a menos que, por supuesto, tenga tiempo/dinero para comenzar de cero.

+0

+1 para enfatizar el desacoplamiento. Solo esto es la razón por la que defiendo con firmeza las herramientas ORM y el uso del patrón de repositorio. –

+3

Las herramientas ORM no ayudan con el desacoplamiento. La lógica de presentación aún puede usar ADO.NET o SQL a través de mecanismos ORM para comunicarse con la base de datos. LinqToSql quiere ser su capa de negocios y, de hecho, hace que sea complicado separar la lógica de negocios y de datos. En la mayoría de los casos, los ORM no pueden ocultar ningún SQL de usted que no sea CRUD muy básico y búsqueda por nombre/tipo de identificación de consultas. Los ORM pueden ser útiles para proyectos heredados y no siempre tienen sentido para nuevos proyectos. –

+0

Las herramientas ORM * do * ayudan a desacoplar. Como escribí, esto no es lo único que debe hacer, ya que todavía necesita definir métodos de interfaz, que ocultará las dependencias de las bibliotecas ORM. Sin embargo, estos métodos pueden utilizar clases como 'Cliente' o 'Orden' que se han creado con la herramienta ORM y se asignan a la base de datos. – kgiannakakis

Cuestiones relacionadas