Je suis effectivement coincé dans la structure à trois niveaux. J'ai surfé sur Internet et trouvé deux terminologies "Database Abstraction Layer" & "Data Access Layer".Quelle est la différence entre la couche d'abstraction de la base de données et la couche d'accès aux données?
Quelles sont les différences entre les deux?
Ma compréhension est qu'une couche d'accès aux données ne fait pas abstraction de la base de données, mais rend plutôt la base de données opérations et la construction de requêtes plus facile.
Par exemple, les couches d'accès aux données ont généralement des API très similaires à la syntaxe SQL qui nécessitent encore la connaissance de la structure de la base de données afin d'écrire:
$Users->select('name,email,datejoined')->where('rank > 0')->limit(10);
couches d'abstraction de données sont généralement épanouie (Object-Relational ORM Mappers) qui théoriquement empêchent de comprendre toute structure de base de données sous-jacente ou qui ont des connaissances en SQL. La syntaxe est peut-être quelque chose comme ceci:
Factory::find('Users', 10)->filter('rank > 0');
Et tous les objets peut être entièrement rempli tous les champs, peut-être jointes avec des objets parent ou un enfant si vous définissez cette façon.
Cependant, cette abstraction a un prix. Personnellement, je trouve que la doctrine ou la propension à l'ORM est inutile et inefficace. Dans la plupart des cas, une simple couche d'accès aux données fera l'affaire, avec le SQL manuel pour tout ce qui nécessite une attention particulière, au lieu d'avoir à détruire les performances de votre application pour du sucre syntaxique. Cette zone est un débat assez houleux, donc je ne vais plus y aller.
Si vous vouliez dire des données base couche d'abstraction, alors ce serait quelque chose dans le sens de PDO, de sorte que votre code peut être utilisé pour un plus grand nombre de fournisseurs de bases de données. PDO fonctionne avec MySQL, PostgreSQL et mysqli parmi d'autres, je crois.
Data Access layer = Create, Read, Update, Delete (CRUD) spécifiques à votre domaine d'application
données Abstraction Layer = effectue des opérations de base de données génériques comme les connexions, les commandes, paramètres d'isolation des bibliothèques de données spécifiques des fournisseurs et fournir une API de haut niveau pour accéder aux données indépendamment du fait que vous utilisiez MySQL, Microsoft SQL Server, Oracle, DB2, etc ...
Courte et sucrée. Bien joué. –
De Wiki:
Une couche d'accès aux données (DAL) dans le logiciel de l'ordinateur, est une couche d'un programme d'ordinateur qui fournit un accès simplifié à des données stockées dans stockage persistant de certaines type, comme une base de données Par exemple, le DAL peut renvoyer une référence à un objet (en termes de programmation orientée objet) complète avec ses attributs à la place d'une rangée de champs d'une table de base de données. Cela permet aux modules client (ou utilisateur) d'être créés avec un niveau d'abstraction supérieur. Ce type de modèle pourrait être mis en œuvre en créant une classe de méthodes d'accès aux données qui référencent directement un ensemble correspondant de procédures de base de données stockées .Une autre implémentation pourrait potentiellement récupérer ou écrire des enregistrements vers ou depuis un système de fichiers. La DAL cache cette complexité du magasin de données sous-jacente à partir du monde externe. Par exemple, au lieu d'utiliser des commandes comme insert, delete et update pour accéder à une table spécifique dans une base de données, une classe et quelques procédures stockées peuvent être créées dans la base de données. Les procédures seraient appelées à partir d'une méthode à l'intérieur de la classe, ce qui retournerait un objet contenant les valeurs demandées. Ou, les commandes de mise à jour insert, delete et peuvent être exécutées dans des fonctions simples telles que registeruser ou loginuser stockées dans la couche d'accès aux données.
En bref, votre base CRUD fonctionnalités/logiques sur objets métier pour pousser à/traction de la couche Persistance/stockage tombe ici. Dans la plupart des cas, vous pourriez vouloir juste cela. La cartographie ORM, les interfaces des objets métier du modèle etc tombent ici.
Une couche d'abstraction de base de données est une interface de programmation d'application qui unifie la communication entre une application informatique et bases de données telles que SQL Server, DB2, MySQL, PostgreSQL, Oracle ou SQLite. Traditionnellement, tous les fournisseurs de bases de données fournissent leur propre interface adaptée à leurs produits, ce qui laisse au programmeur d'application le soin de mettre en œuvre le code pour toutes les interfaces de base de données qu'il aimerait prendre en charge. Les couches d'abstraction de base de données réduisent la quantité de travail en fournissant une API cohérente au développeur et masquent autant que possible les spécificités de base de données derrière cette interface. Il existe de nombreuses couches d'abstraction avec différentes interfaces dans de nombreux langages de programmation.
Fondamentalement, sa couche supplémentaire d'abstraction afin que vous CRUD contre fournisseur interfaces indépendantes et inquiètent moins les détails de mise en œuvre des différents fournisseurs de bases de données. Vous en aurez besoin seulement si vous voulez supporter plus d'une base de données. ORM, Micro ORM, wrappers, classes de pilotes génériques, quel que soit le nom, etc. qui traite de l'établissement de la connexion, de la gestion des paramètres, de l'exécution, etc. tombe ici. C'est juste une couche supplémentaire juste avant la couche Persistance/Stockage. Dans la terminologie à trois niveaux, ces deux couches tombent sous une, car elles ne sont pas logiquement séparées.
Pour résumer, DAL est sur les données, DbAL est sur la base de données. DAL définit les opérations, DbAL fonctionne. DAL se trouve derrière DbAL qui est juste derrière Db réel. DAL appelle DbAL. DAL est une bonne chose pour séparer les logiques commerciales (dans Model) des logiques CRUD, alors que DbAL est rarement nécessaire (mais j'adore). DAL est un mappage de conception de plus haut niveau, DbAL est une architecture et une implémentation de plus bas niveau. Les deux séparent les responsabilités. Les ORM sont des structures massives qui font les deux pour vous. Je ne suis pas sûr de la façon dont vous les séparez lorsque vous utilisez des ORM. Vous n'avez pas besoin puisque les ORM gèrent tout cela pour vous. Idéalement, je voudrais de toute façon avoir DAL dans un projet, et Dbal dans un autre que j'appellerais simplement couche de persistance car il n'y a aucune raison de séparer Db et les opérations sur elle.
Je suis un peu confus par votre réponse. Pouvez-vous le rendre un peu plus simple.Peut être d'autres exemples pourraient aider. Je suis vraiment confus. – kamal