Qué ORMs admite qué estilos de flujo de trabajo

Question

He trabajado con algunos ORM diferentes en algunos idiomas diferentes - No parece haber acuerdo sobre qué tipo de thingy debería ser la fuente y qué se debe generar.

Considere estas cositas :

• Institución: un objeto simple y llano. Hace cosas.
• Mapper: un objeto que crea una entidad de la base de datos o la persiste atrás.
• Tabla: una tabla de base de datos.
• Modelo: Un modelo diferente que describe un abstracto thingy.
• Cableado: A descripción de cómo se relacionan las partes de una tabla y Entidad .

Eso nos da a estos estilos de flujo de trabajo:

• Model Driven: Usted escribe un modelo, y se generan la Entidad, Mapper, y en la tabla.
• Entidad controlada: Escribe una clase y se generan el asignador y la tabla.
• Table Driven: Se crea una tabla y se generan la entidad y el asignador.
• Cableado: Usted escribe Clase, Tabla y Cableado, se genera el Mapper.

las preguntas:

• ¿Hay otro estilo que he fallado a notar?
• ¿Qué ORM admiten qué estilos?
• ¿Hay un vocabulario estándar para esto? (Acabo de inventar lo anterior.)

Answer 1

Según lo que he visto hasta ahora, al utilizar .NET, Entity Framework admite todo lo anterior y NHibernate admite lo que usted denomina "Conducido por modelos, controlado por entidades" y Wire-up (sin utilizar bibliotecas adicionales de terceros).

NHibernate es un puerto de Hibernate de Java, por lo que supongo que admiten los mismos flujos.

Answer 2

El popular patrón de registro activo no tiene la complejidad completa de cableado y mapeo. Una clase de modelo implementa los registros de filas directamente con los métodos de persistencia y los métodos de dominio combinados.

En la biblioteca ActiveRecord de Ruby on Rails, la clase también actúa como modelo para la tabla, con métodos de clase para find() etc. Por lo tanto, normalmente solo se escribe una clase por tabla.

Rubí AR refleja en la tabla dinámica (por nombre de tabla, nombres de columna y los tipos), por lo que las siguientes basta después de crear el esquema de base de alguna manera:

class MyTable << ActiveRecord::Base; end 

row = MyTable.find(7) 
row.my_column1 = "foo" 
row.save() 

http://ar.rubyonrails.org/

Answer 3

Me disculpo si este podría estar un poco fuera del tema, pero es demasiado grande como para hacer un comentario, así que avance la advertencia, si otros piensan que no ayuda, el tema lo eliminaré.

Una cuestión clave es si usted y su aplicación propietario y es el único cliente que accesess la base de datos.

Si necesita trabajar alrededor de una base de datos existente, entonces fuera del bloque, la generación de la base de datos del Modelo probablemente esté descartada.

Si su sistema lo crea o no, será accedido por otros sistemas (lo que significa que no puede cambiar aleatoriamente la base de datos para implementar lógica, o incluso más extrema, pueden agregarse otros campos/tablas para facilitar el Aplicaciones de terceros), entonces debe pensar en qué flujos de trabajo le permitirán abstraer los detalles de la base de datos de su implementación para evitar tener que realizar reescrituras importantes.

Estos requisitos pueden cambiar a lo largo de la vida útil de los proyectos, ya que podría comenzar como el único consumidor y, en el futuro, otras aplicaciones podrían acceder directamente a la misma base de datos. Puede ser que tenga un flujo de trabajo "Entity Based" como lo llama, donde tiene una capa que representa las tablas de bases de datos reales, y los modelos que representan los datos utilizados en su sistema se abstraen de los cambios a estos.

Y a veces es necesario cambiar, por lo tanto, el ORM y el flujo de trabajo que utiliza deben ser conscientes y al menos parcialmente capaces de sobrevivir en un futuro que podría estar fuera de sus manos. Imagine un entorno empresarial (también conocido como político). Un día aparece un DBA y dice, "todo el acceso a los datos ahora es a través de los SPROC". Este tipo de situaciones lo empujan hacia el "Mapeo" como lo llamó.