Quelle est la différence entre un ORM, AR, QB et DM?

Question

Ok, donc tout le monde a décidé (et pour une bonne raison) Strait SQL est du diable. Cela nous laisse de nombreuses méthodes pour placer un "intermédiaire" dans notre code pour séparer notre code de la base de données. Je vais maintenant cracher toutes les informations que j'ai recueillies dans l'espoir que quelqu'un puisse me mettre en détresse et me dire ce que j'ai construit.

Un ORM (Object-Relational Mapping) est une série d'outils (dépend étroitement ou étroitement liés) qui mappe les lignes de base de données aux objets de l'application. Dans un AR (Active-Record) est un type d'ORM dans lequel une table ou une vue de base de données est enveloppée dans une classe, ainsi une instance d'objet est liée à une seule ligne dans la table. Le mappage de données (DM) est un type d'ORM qui consiste à créer des mappages d'éléments de données entre deux modèles de données distincts.

Tous les trois prétendent travailler comme ceci:

$user = new User(); 
$user->name = 'Fred'; 
$user->save(); 

Habituellement avec quelque chose de classe utilisateur comme ceci:

class User extends Model { 
    // Specify the database table 
    protected $table = "users"; 

    // Define your fields 
    protected $fields = array(
     'id' => array('type' => 'int', 'primary' => true), 
     'name' => array('type' => 'string', 'required' => true), 
     'email' => array('type' => 'text', 'required' => true) 
    ); 
} 

Avec cette configuration, vous pouvez facilement récupérer les lignes sans le besoin d'écrire SQL.

// users 
$users = $user->fetch(array('id' => 3)); 

Certaines classes AR semblent en fait plus comme ceci:

$db->where('id' => 3); 
$db->join('posts', 'posts.user_id = users.id'); 
$results = $db->get('users'); 

Ok, ceci est maintenant où il obtient poilue. Tout le monde et son frère semblent avoir un point de vue différent sur le type de code qui tombe là. Alors que la plupart conviennent qu'un AR ou DM est un type d'ORM - mais parfois les lignes qui indiquent les AR des DM semblent étaler.

J'ai écrit une classe qui utilise un seul objet ($ db) dans lequel vous faites des appels à cet objet et il gère la création SQL pour l'enregistrement/la récupération des résultats. Donc, la question est "qu'est-ce que c'est?", Et pourquoi les gens ne sont pas d'accord sur ces termes?

Answer 1

Vous pourriez aussi bien faire les acronymes ORM, RM DM quel que soit ... il est tout simplement état transféré d'un milieu à un autre et enveloppé dans la fonction/sémantique.

Sun Microsystems et Microsoft le font tout le temps avec Java et C#. Prenons quelque chose de simple et donne-lui un nouveau nom! Quelle bonne idée.

Si vous dites ORM ... tout le monde sait ce que c'est, sous ses nombreuses formes. Votre code ressemble à celui de Linq.

Pas de magie, mais beaucoup de mots à la mode et de l'embarras à mon humble avis.

Answer 2

D'accord avec @Aiden Bell. Mais je pense que vous avez raison de souligner les différences. J'utilise LINQ to SQL qui dans votre définition est simplement le style Active-Record d'ORM. Pour moi, cela fonctionne très bien car je travaille sur beaucoup d'applications greenfield et commence à la base de données pour construire mes classes. De là, j'ai tendance à suivre une approche de Domain Driven Design (je sais ... c'est un concept de première classe) en travaillant avec mes classes générées. Pour moi, cela m'amène rapidement sur la route.Cela dit, j'ai également travaillé avec Entity Framework et NHybernate. Entity Framework est le mappeur de données UBER et NHybernate est également un mappeur de données mais sans autant de complexité! Personnellement, je pense que Entity Framework a beaucoup de chemin à faire. Si je devais avoir besoin de plus de complexité, comme dans une application de friche industrielle où la base de données était assez figée et que je devais obtenir mes cours pour représenter mon application plutôt que ma base de données, je préférerais passer à autre chose. NHybernate et sa fonctionnalité de mappage de données.

Je pense que chacun de ces outils a sa place. Il n'est pas juste de dire qu'ils sont tous pareils. Un enregistrement actif est génial en ce qu'il génère pour moi des classes qui représentent directement ma base de données. Cela fonctionne lorsque j'ai créé la base de données ou la base de données représente de près mes termes omniprésents et les concepts de l'application. Les types de mappage d'orms fonctionnent quand j'ai une base de données fixe qui n'a pas de sens ou mappe clairement à mon application auquel cas je peux encapsuler la complexité ou le manque de ma base de données pour créer un domaine riche via les fonctionnalités de mappage Outil ORM.

Answer 3

Ce n'est pas si simple que ça, le SQL est le diable - parfois, il faut à peu près écrire du SQL brut pour obtenir une requête qui fonctionne comme vous le souhaitez. Pour moi, les ORM sont beaucoup plus sur l'élimination du travail manuel qu'autre chose (comme éviter le SQL à tout prix). Je ne veux simplement pas avoir à configurer tous mes objets de code avec toutes les requêtes créées manuellement pour chaque projet. C'est juste une quantité ridicule de travail et de réflexion. Au lieu de cela, les outils ORM fournissent une manière agréable et automatisée de créer des objets de données qui auraient nécessité beaucoup de travail manuel sinon. Maintenant, je peux avoir des objets de ligne individuels automatiques que je peux étendre et créer des fonctions personnalisées, sans y penser. Je peux récupérer des lignes associées à partir de tables différentes sans avoir à coder à la main cette requête. Il semblerait que votre exemple de classe d'utilisateur soit de phpDataMapper, et si c'est le cas, il a aussi d'autres subtilités intégrées comme les migrations de tables automatiques, donc vous n'avez pas besoin de distribuer un fichier SQL pour vos structures de table ainsi que quelques fonctions d'aide et d'autres choses. Toutes les fonctionnalités incluses destinées à vous faire gagner du temps - c'est l'objectif principal. La distinction la plus importante entre AR et DM est qu'une ligne ActiveRecord (AR) connaît son propre magasin de données, et a donc des fonctions de sauvegarde/mise à jour sur chaque objet ligne - $ user-> save() - The "record " c'est actif". En revanche, avec DataMapper (DM), chaque ligne individuelle ne connaît PAS son propre stockage de données, par définition. La ligne est plus d'un objet de valeur stupide qui peut être travaillé avec dans votre code. Le mappeur est responsable de la traduction des modifications apportées à cette ligne vers le magasin de données - $ mapper-> save ($ user). C'est la différence la plus significative - vous trouverez la plupart des fonctionnalités ORM de base pour être la même dans presque toutes les implémentations. C'est juste une question de comment il est construit au niveau architectural de base.