Question

Je bricole CodeIgniter et je suis tombé sur Active Records pour la première fois. Au début, j’ai considéré que c’était quelque chose qui convient aux personnes qui ne savent pas vraiment écrire en SQL. Je me rends compte maintenant que mon analyse était erronée et qu'Active Records est assez important, en particulier dans Rails.

Mais à quoi servent Active Records? S'agit-il d'abstraire des différentes individualités de SGBDR? Si c'est le cas, je pensais que ce n'est pas ce que SQL est censé faire. De plus, quelle est la meilleure pratique, devrais-je les utiliser?

Merci d'avance

Était-ce utile?

La solution

Le " Modèle d’enregistrement actif " devient une partie essentielle de la plupart des cadres de programmation. Cela simplifie la réalisation des tâches CRUD (création, mise à jour, lecture, suppression) plus simples. Par exemple, plutôt que d'avoir à écrire de nombreux SQL pour insérer, mettre à jour et supprimer de nombreux objets de données courants et simples, cela vous permet d'affecter simplement les valeurs à l'objet de données et d'exécuter une commande, par exemple. $ object- > save (), le code SQL est compilé et exécuté pour vous.

La plupart des frameworks implémentent également des relations de données dans leurs modèles Active Record respectifs, ce qui peut grandement simplifier l'accès aux données liées à votre objet. Par exemple, dans CodeIgniter, si vous avez spécifié qu'une catégorie " en a plusieurs " Après avoir chargé l’objet Category dans la base de données, vous pouvez répertorier ses produits enfants avec une simple ligne de code.

foreach ($category->products as $product) {
  echo $product->name;
}

Un autre avantage d’Active Record est, comme vous le dites, de rendre votre code facilement portable sur différentes plates-formes de base de données (tant que la structure que vous utilisez possède un pilote pour la base de données choisie) et bien que cela ne soit pas susceptible de se produire. semble important en ce moment, il sera peut-être plus utile si votre application devient populaire!

J'espère que cela aura aidé. Wikipedia décrit bien Active Record ( http://en.wikipedia.org/wiki/Active_record_pattern ) et les documents CodeIgniter seront également. Personnellement, j'utilise KohanaPHP ( http://www.kohanaphp.com ), qui est un fork de CodeIgniter en PHP5 et Je trouve que ses modèles ORM sont très utiles!

Autres conseils

Active Record est un modèle de conception pour l'accès aux données ...

À l'heure actuelle, il me semble que deux principaux modèles de conception concernant l'accès aux données existent: ActiveRecord et le modèle de référentiel

Enregistrement actif

Vos objets contiennent des méthodes permettant de conserver leur état dans une base de données (ou un autre mécanisme de persistance), ainsi:

Vous pouvez avoir un objet client.

L'objet Client aura un tas de méthodes telles que Customer.Save () ;, Customer.Get (int id); et d'autres.

Ces méthodes n’ont vraiment rien à voir avec un client dans le monde réel. Ils concernent réellement l’infrastructure de votre application.

Modèle de référentiel

Dans le modèle de référentiel, votre objet client serait un objet POCO ou un objet muet. Il ne dispose que des méthodes et des propriétés dont il a réellement besoin pour représenter un client (nom, adresse électronique, commandes, etc.)

Lorsque vous souhaitez conserver le client, vous le transmettez simplement à votre référentiel

Repository.Save (MyCustomer).

Le modèle d’enregistrement actif est facile et rapide à utiliser. Malheureusement, votre modèle de domaine est surchargé par ces méthodes qui n’ont vraiment rien à voir avec un client. Cela rend légèrement plus difficile la maintenance de votre modèle de domaine au fil du temps.

Dans de nombreuses situations, il est très approprié d’utiliser un modèle d’enregistrement actif. Par exemple, si j'écris une application assez simple qui ne va probablement pas beaucoup changer, je lancerais probablement SubSonic et générerais mon DAL Active Record. Je coderais mon code d'entreprise dans les 20 minutes et tout le contenu de la base de données est déjà pris en charge.

Si, en revanche, je modélise un domaine particulièrement complexe, très sensible au changement, je préfère garder mes modèles de domaine propres et mettre en œuvre un modèle de référentiel avec nHibernate ou similaire ...

Cela fait longtemps que je n'ai pas lancé mon propre accès aux données avec ADO.Net, et je ne le recommande pas vraiment pour l'instant car il existe de si nombreux outils d'accès aux données disponibles.

Je pourrais donner mon point de vue sur ce modèle, mais la meilleure couverture d’Active Record (et de nombreux autres) est Patterns. d’architecture d’applications d’entreprise par Martin Fowler.

Du chapitre 10:

  

Enregistrement actif

     

Un objet qui enveloppe une ligne dans un   table ou vue de base de données, encapsule   l'accès à la base de données et ajoute un domaine   logique sur ces données.

     

Un objet porte à la fois des données et   comportement. Une grande partie de ces données est   persistant et doit être stocké dans un   base de données. Active Record utilise le plus   approche évidente, mettant l'accès aux données   la logique dans l'objet de domaine. Par ici   tout le monde sait lire et écrire   leurs données vers et à partir de la base de données.

     

...

     

Quand l'utiliser

     

Active Record est un bien   choix pour la logique de domaine qui n'est pas trop   complexe, tel que crée, lit,   met à jour et supprime. Dérivations et   validations basées sur un seul enregistrement   fonctionne bien dans cette structure.

     

...

     

L'enregistrement actif a le principal   avantage de la simplicité. C'est facile à   construire Active Records, et ils sont   facile à comprendre. Leur primaire   le problème est qu'ils ne fonctionnent bien que si   les objets Active Record correspondent   directement aux tables de la base de données: un   schéma isomorphique.

     

Si votre entreprise   la logique est complexe, vous voudrez bientôt   utilisez directement votre objet   relations, collections,   héritage, etc. Ceux-ci ne   mapper facilement sur Active Record, et   les ajouter au coup par coup devient très salissant.   C'est ce qui va vous amener à utiliser Data   Mapper à la place

Au contraire, cela facilite la rédaction des requêtes. Je trouve que la syntaxe MySQL normale est sujette aux erreurs de syntaxe (aucune faute mais à la mienne) et avec la syntaxe d'enregistrement actif du CI, cela m'arrive rarement.

Active Record est l’une des fonctionnalités les plus intéressantes de CI IMHO

Active Record est un ORM - Avez-vous examiné la technique de mappage relation-objet? Je pense que si vous comprenez ORM, vous commencerez à en voir les avantages.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top