data access layer - patron - ¿Cuál es la diferencia entre la Capa de abstracción de base de datos y la Capa de acceso a datos?
programacion en 4 capas (3)
En realidad estoy atrapado en la estructura de 3 niveles. Navegué por Internet y encontré dos terminologías "Capa de abstracción de base de datos" y "Capa de acceso a datos".
¿Cuáles son las diferencias entre los dos?
Capa de acceso a datos = Operaciones de creación, lectura, actualización y eliminación (CRUD) específicas de su dominio de aplicación
Capa de abstracción de datos = realiza operaciones de base de datos genéricas como conexiones, comandos, parámetros que lo aíslan de las bibliotecas de datos específicas del proveedor y proporcionan una api de alto nivel para acceder a los datos, independientemente de si utiliza MySQL, Microsoft SQL Server, Oracle, DB2, etc.
De Wiki:
Una capa de acceso a datos (DAL) en un software de computadora, es una capa de un programa de computadora que proporciona acceso simplificado a datos almacenados en almacenamiento persistente de algún tipo, como una base de datos relacional de entidades.
Por ejemplo, el DAL puede devolver una referencia a un objeto (en términos de programación orientada a objetos) completa con sus atributos en lugar de una fila de campos de una tabla de base de datos. Esto permite que los módulos del cliente (o usuario) se creen con un nivel más alto de abstracción. Este tipo de modelo podría implementarse creando una clase de métodos de acceso a datos que hagan referencia directa al conjunto correspondiente de procedimientos almacenados de la base de datos. Otra implementación podría potencialmente recuperar o escribir registros en o desde un sistema de archivos. El DAL oculta esta complejidad del almacén de datos subyacente del mundo externo.
Por ejemplo, en lugar de usar comandos como insertar, eliminar y actualizar para acceder a una tabla específica en una base de datos, se puede crear una clase y algunos procedimientos almacenados en la base de datos. Los procedimientos se llamarían desde un método dentro de la clase, que devolvería un objeto que contenga los valores solicitados. O bien, los comandos de inserción, eliminación y actualización podrían ejecutarse dentro de funciones simples como registeruser o loginuser almacenadas dentro de la capa de acceso a datos.
En resumen, sus funcionalidades / lógicas de CRUD básicas en los objetos de negocio para presionar / tirar de la capa de persistencia / almacenamiento se encuentran aquí. Para la mayoría de los casos es posible que desee simplemente esto. La asignación de ORM, las interfaces de los objetos de negocios del Modelo, etc. caen aquí.
Capa de abstracción de base de datos
Una capa de abstracción de base de datos es una interfaz de programación de aplicaciones que unifica la comunicación entre una aplicación informática y bases de datos como SQL Server, DB2, MySQL, PostgreSQL, Oracle o SQLite. Tradicionalmente, todos los proveedores de bases de datos proporcionan su propia interfaz adaptada a sus productos, lo que deja al programador de la aplicación implementar el código para todas las interfaces de base de datos que le gustaría admitir. Las capas de abstracción de la base de datos reducen la cantidad de trabajo al proporcionar una API consistente al desarrollador y ocultan los detalles de la base de datos detrás de esta interfaz tanto como sea posible. Existen muchas capas de abstracción con diferentes interfaces en numerosos lenguajes de programación.
Básicamente, es una capa adicional de abstracción para que CRUD contra las interfaces independientes del proveedor y se preocupe menos por los detalles de implementación de varios proveedores de bases de datos. Solo lo necesitará si desea admitir más de una base de datos. ORMs, Micro ORMs, envolturas, clases de controladores genéricos, cualquiera que sea el nombre, etc., que trata sobre el establecimiento de la conexión, el manejo de parámetros, la ejecución, etc. Es solo una capa adicional justo antes de la capa de persistencia / almacenamiento. En la terminología de 3 niveles, ambas capas se incluyen en una, ya que no están separadas lógicamente.
Para resumir, DAL es sobre datos, DbAL es sobre base de datos. DAL define operaciones, DbAL opera. DAL se encuentra detrás de DbAL, que está justo detrás de Db real. DAL llama a DbAL. DAL es una buena cosa para separar las lógicas de negocios (en Modelo) de las lógicas de CRUD, mientras que DbAL rara vez se necesita (pero me encanta). DAL es un mapeo de diseño de más alto nivel, DbAL es una arquitectura e implementación de más bajo nivel. Ambos separa las responsabilidades. Los ORM son estructuras masivas que hacen ambas cosas por ti. No estoy seguro de cómo se separan cuando se usan ORM. No es necesario que los ORM se encarguen de todo eso por ti. Idealmente, de todos modos tendría DAL en un proyecto, y DbAL en otro que simplemente llamaría capa de persistencia ya que no tiene sentido separar Db y las operaciones en él.
Según entiendo, una capa de acceso a datos no abstrae realmente la base de datos, sino que facilita las operaciones de la base de datos y la creación de consultas.
Por ejemplo, las capas de acceso a datos suelen tener API muy similares a la sintaxis de SQL que aún requieren conocimiento de la estructura de la base de datos para escribir:
$Users->select(''name,email,datejoined'')->where(''rank > 0'')->limit(10);
Las capas de abstracción de datos suelen ser ORM''s (Mapeadores relacionales de objetos) que, en teoría, impiden la necesidad de comprender cualquier estructura de base de datos subyacente o tener conocimientos de SQL. La sintaxis podría ser algo como esto:
Factory::find(''Users'', 10)->filter(''rank > 0'');
Y todos los objetos pueden estar completamente rellenados con todos los campos, posiblemente unidos con cualquier objeto principal o secundario si lo configura de esa manera.
Sin embargo, esta abstracción tiene un precio. Personalmente, considero que la doctrina o la propulsión de ORM es innecesaria e ineficiente. En la mayoría de los casos, una capa de acceso a datos simple funcionará bien, con SQL manual para cualquier cosa que requiera atención especial, en lugar de tener que destruir el rendimiento de su aplicación para un poco de azúcar sintáctica. Esta área es un debate bastante acalorado, así que no voy a entrar más en él.
Si se refería a la capa de abstracción de la base de datos, sería algo así como PDO, de modo que su código se pueda usar para un mayor número de proveedores de bases de datos. PDO funciona con MySQL, PostgreSQL y mysqli entre otros, creo.