Je viens des recherches sur le modèle ActiveRecord, et sur cette base (http://en.wikipedia.org/wiki/Active_record_pattern), il semble Linq 2 Sql plus ou moins implémente ce, je me trompe? ou que faudrait-il changer pour se conformer au modèle ActiveRecord?LINQ to SQL utilise-t-il le modèle ActiveRecord?
D'une certaine façon, il peut se sentir comme un motif d'enregistrement actif, mais il est vraiment pas. Exemple simple:
//load the entity
var c = myDataContext.Customers.FirstOrDefault(c => c.Id == 1876);
c.Name = "George Armstrong Custer";
// saves the entity
myDataContext.SubmitChanges();
Active Record
//load the entity
var c = Customer.GetCustomer(9);
c.Name = "Varus";
//save the entity
c.Save();
Active Record vraiment implique une seule classe qui couvre le modèle et fournit l'interface de données Linq à Sql suit un chemin différent où il y a quelques classes de modèle et une interface de données séparée, également appelée référentiel.
PS: Pour un bon exemple d'un ORM qui utilise le modèle d'enregistrement actif, consultez Subsonic.
+1 C'est plus clair quand on lui présente l'exemple :) –
LINQ to SQL n'est pas une implémentation du modèle ActiveRecord. Dans une implémentation réelle du modèle ActiveRecord de Fowler, l'objet lui-même serait responsable de l'enregistrement et du chargement de son état à partir de la base de données. Lors de l'utilisation de LINQ to SQL Objects, DataContext est responsable de la récupération de la base de données, du suivi de l'état de l'objet et de l'enregistrement de ces modifications dans la base de données.
Vous auriez du mal à encapsuler ces classes LINQ to SQL dans plus de code pour en faire une véritable implémentation du modèle ActiveRecord (il n'y a pas de moyen facile de retirer la responsabilité du DataContext).
Je ne suis pas sûr que ce soit entièrement correct. L'objet entité et la responsabilité du partage DataContext: DataContext fournit une fonctionnalité standard pour traduire des données d'attributs génériques en SQL, mais l'objet entité fournit les mappages entre les membres d'objet et la base de données. En outre, l'état de l'entité * est * stocké dans l'objet - encore une fois, le DataContext a seulement une fonctionnalité générique standard pour l'état de réconciliation. –
Vous avez raison. Mais le fait est que la responsabilité est toujours partagée plutôt que l'objet qui gère tout pour lui-même (comme vous le feriez dans une vraie implémentation du pattern ActiveRecord). –
Linq to sql donne-t-il le mappage 'une classe par table'? Ce serait une caractéristique d'ActiveRecord. Ce qui conduit loin des autres modèles OO tels que Domain Driven Design. –
LINQ to SQL n'est pas une implémentation de Active Record, ce qui signifie que les entités sont entièrement responsables de la gestion de leur propre persistance (c'est-à-dire Persistence Aware). Ce que LINQ to SQL est réellement est une implémentation de Unit of Work. Une unité de travail signifie qu'une sorte de registre ou de contexte suit l'état des entités, implicitement ou explicitement, permettant aux entités d'ignorer complètement leur mécanisme de persistance (c'est-à-dire Persistence Ignorant). Unité de travail prend en charge un style de programmation appelé POCO (plain old clr object), qui vous permet de gérer separation of concerns et de gérer le . Lorsque ces deux principes sont rencontrés, votre logiciel est généralement plus facile à maintenir. Active Record rompt réellement ces deux principes, ce qui conduit à un logiciel plus étroitement couplé qui peut être plus difficile à maintenir.
@jrista Intéressant ... – GONeale
Bonne question, j'espère que nous nettoyons cela et votons la réponse de 26971 vers le bas. – jfar