Modèle de référentiel par rapport aux objets métier "intelligents"

Question

Je vois deux principales "écoles de pensée" quand il s'agit de la création à grande échelle de l'échelle de l'entreprise applications sur .NET (Winforms, WPF, ASP.NET).

Certaines personnes utilisent le référentiel "pattern" qui utilise un référentiel qui sait chercher, insérer, mettre à jour et supprimer des objets. Ces objets sont plutôt des "muets", en ce qu'ils n'ont pas nécessairement contenir tout un tas de logique - par exemple, ils sont plus ou moins de transfert de données objets.

L'autre camp utilise ce que j'appelle "smart" des affaires objets de savoir comment charger eux-mêmes, et ils ont généralement un Save(), Update() ou encore la méthode Delete (). Ici, vous n'avez pas vraiment besoin de tout dépôt - les objets, eux, savent comment charger et enregistrer eux-mêmes.

La grande question est: est-ce que vous utilisez ou que vous préférez? Et pourquoi?

Utilisez-vous la même approche dans toutes vos applications, ou avez-vous des critères pour choisir une approche plutôt que l'autre? Si ce sont ces critères?

Je ne suis pas d'essayer de démarrer une flamme de guerre ici - juste essayer de savoir ce que tout le monde pense à ce sujet et quels sont vos avis, et pourquoi vous utilisez l'un (ou les deux) des motifs sur les autres.

Merci pour les commentaires constructifs!

Answer 1

J'utilise le modèle de référentiel en raison du principe de responsabilité unique. Je ne veux pas que chaque objet individuel sache comment enregistrer, mettre à jour, se supprimer lui-même, lorsque cela peut être géré par un seul référentiel générique

Answer 2

Le modèle de référentiel n'est pas nécessaire de conduire à des objets muets. Si les objets ont pas de logique à l'extérieur de sauvegarde/mise à Jour, vous êtes probablement en faire trop à l'extérieur de l'objet.

Idéalement, vous ne devriez jamais utiliser les propriétés pour obtenir des données à partir de votre objet, de calculer, de choses, et de mettre les données dans l'objet. C'est une rupture de l'encapsulation.

De sorte que les objets ne doivent pas être anémique, sauf si vous utilisez simple DTO objets avec les opérations CRUD.

Puis la séparation de la persistance des préoccupations de votre objet de préoccupations est un bon moyen d'avoir de Responsabilité Unique.

Answer 3

Voici deux articles intéressants que j'ai rencontrés

Repository-is-the-new-singleton

Le DAL devrait aller jusqu'à l'interface utilisateur

Answer 4

Je pense que le plus important des effets secondaires de l'utilisation du modèle de Référentiel vs le ActiveRecord modèle est de le tester et de l'extensibilité.

Sans avoir votre ActiveRecord objet contient un référentiel lui-même comment vous isoler de la récupération des données dans vos cas de test? Vous ne pouvez pas vraiment faux ou de s'en moquer facilement.

En plus des tests, il serait également s'avérer beaucoup plus difficile à échanger des technologies d'accès aux données, par exemple à partir de Linq-to-SQL pour NHibernate ou EntityFramework (bien que cela n'arrive pas souvent il est vrai).

Answer 5

Cela dépend vraiment des besoins de l'application, mais lorsqu'il s'agit d'un complexe modèle d'affaires, je préfère ActiveRecord. Je peux encapsuler (et de tester) la logique d'affaires en un seul endroit.

La plupart des ORM (EF, nHibernate, etc...) servent de Référentiel. Beaucoup de gens considèrent comme une couche au-dessus d'un ORM qui encapsule toutes les données de l'interaction d'un Référentiel, qui, je crois, à être incorrect. Selon Martin Fowler, un Référentiel encapsule les données d'accès que d'une collection. Donc, avoir des méthodes individuelles pour toutes les données de récupération de mutation peut-être l'aide d'un Mappeur de Données ou un Objet d'Accès aux Données.

Utiliser ActiveRecord, j'aime avoir une "Entité" de la classe de base. En général, je utiliser un ORM (référentiel) avec cette classe de base, de sorte que tous mes entités ont un GetById, AsQueryable, Enregistrer et Supprimer des méthodes.

Si je suis en utilisant plus d'une Architecture Orientée Service, je vais utiliser un référentiel (masques d'accès direct aux données ou un ORM) et de l'appeler directement par mes services.