vehicles - ¿Dónde está la línea entre DAL y ORM?
www.texas.gov en espanol (4)
Los términos a menudo se intercambian indistintamente, y existe una considerable superposición, pero con la misma frecuencia parece implicar que las personas vean algo fuertemente implicado al decir que un sistema es un ORM que no está implícito porque es un DAL. ¿Que es eso? ¿Cuáles son los puntos clave que diferencian estos tipos de sistema?
Por ejemplo, digamos que tengo un código que implementa las clases de Base de datos, Tabla, Columna y Fila, llenándolos por análisis automático de una base de datos existente, lo que permite una interacción simplificada, etc. Comprende, aplica y aprovecha las relaciones estructurales entre las entidades de bases de datos, como las claves externas. Todos los modelos de entidad se pueden subclasificar para cargar funcionalidad específica de tabla en ellos.
¿En qué medida es esto un DAL? ¿En qué medida es un ORM? ¿Por qué?
ORM = Asignación relacional de objetos
En un ORM, las clases / objetos en la aplicación se asignan a las tablas de la base de datos y las operaciones para la persistencia, a veces de forma automática.
DAL = Capa de acceso a datos
En un DAL, las operaciones de la base de datos están ocultas detrás de una fachada de código.
Un ORM es un tipo de DAL, pero no todos los DAL son ORM.
Creo que un ORM es capaz de mapear cualquier conjunto de objetos a una base de datos relacional; mientras que un DAL es específico para su aplicación, y probablemente no podría extenderse naturalmente para admitir otros objetos.
No solo eso, sino que un ORM específicamente se ocupa de asignar clases a / desde las entidades de la base de datos, mientras que un DAL puede ser simplemente una forma de acceder a los datos en una base de datos, sin ningún tipo de mapeo.
Cualquier DAL orientado a objetos que se conecte a cualquier sistema de almacenamiento que no esté guardando objetos implementa un ORM. Por lo general, se entiende que ORM significa algo así como Hibernate, pero lo importante es el manejo de los desajustes de impedancia.
[Expandido]
En un nivel de datos, se producen desajustes de impedancia cuando se mapean datos de un tipo (relacional) en datos de otro (OO).
Por ejemplo, ¿cuántas veces has visto una línea como la siguiente en tu DAL?
db.AddInParameter(dbCommand, "Name", DbType.String, name);
O el otro lado
customerId = Convert.ToInt64(dr["CustomerID"].ToString());
Aparecen muchos problemas al mapear sus tipos de datos primitivos.
A nivel de objeto, su DAL debe devolver las estructuras que tiene la intención de usar. Ya sea una especie de objeto comercial o simplemente un montón de datos en bruto. Tanto su propio DAL como el ORM necesitan manejar esto.
A nivel de diseño, los objetos que construyes reflejan tus datos almacenados. Entonces puede ocurrir una diferencia estructural. Estos también se manejan para usted dentro de las soluciones ORM, pero se lo forzaría a hacer lo mismo dentro de un DAL. Por ejemplo, dentro de su código OO, sería bueno implementar una herencia adecuada, pero eso no se convierte fácilmente en algo relacional.
Solo quería señalar que ORM es un término acuñado para impulsar productos que automatizan gran parte de lo que ya debería hacer dentro de su DAL. Las soluciones ORM le facilitarán la vida y le brindarán una gran cantidad de beneficios de calidad / rendimiento. Pero eso no cambia el hecho de que uno de los principales componentes de su DAL es la creación de su propio ORM.
ORM no existía cuando comencé a programar. Cuando salieron los primeros ORM, fueron herramientas externas utilizadas para crear el DAL. Ahora los días, DAL y ORM se han entremezclado. Es por eso que muchos desarrolladores usan los términos indistintamente.
El ejemplo más conocido de un ORM que funciona como DAL es NHibernate. Otros ejemplos son Subsonic y CSLA.NET. Estas son todas las herramientas .NET. Las herramientas de IIRC y ORM comenzaron en el mundo de Java. Otras pilas de tecnologías copiaron lo que Java ha hecho.