Modèle de conception pour la Couche d'Accès aux Données

Normalement, si je ne peux pas utiliser n'importe quel cadre, j'utilise à la fois le Référentiel et Active modèles.

Pour des raisons de simplicité, vous pouvez utiliser uniquement le modèle de Référentiel. J'ai l'habitude de le définir comme ceci:

// Define a generic repository interface
public interface IRepository<Key, E> where E:IEntity<Key>>{
    void Add(E entity);
    void AddRange(IEnumerable<E> entities);
    IEntity<Key> Get(Key key);
    IEnumerable<E> GetRange(IEnumerable<Key> keys);
    IEnumerable<E> GetAll();
    // ..., Update, Delete methods
}

// Create an abstract class that will encapsulate the generic code
public abstract class Repository<K, E> where E:IEntity<K>>:IRepository<K, E>{

    protected Repository(/*parameter you may need to implement the generic methods, like a ConnectionFactory,  table name, entity type for casts, etc */){}

    public override void Insert(IEntity<Key> entity){
        // do the insert, treat exceptions accordingly and encapsulate them in your own and more concise Exceptions, etc
    }
    // ...
}

// Create the entities classes, one for each table, that will represent a row of that table
public class Car: IEntity<String>{/* Properties */}

// Create a specific repository for each table
// If the table have a composed key, just create a class representing it
public CarRepository: Repository<String, Car>{

    public CarRepository(){/* pass the base parameters */}

    //offer here your specific operations to this table entity
    public IEnumerable<Car> GetByOwner(PersonKey ownerKey){
        // do stuff
    }
}

Vous avez maintenant assez d'outils pour manipuler la base de données, mais si vous le souhaitez, vous pouvez utiliser la configuration Active.
Un exemple simple:

public class Person:IEntity<PersonKey>{
    public PersonKey Key{get;}
    public IEnumerable<Car> OwnedCars{
        get{
            CarRepository rep = DBSingletons.Cars;
            return rep.GetByOwner(this.Key);
        }
        set{
            // do stuff
        }
    }
}

Évidemment, au moment de faire vos propres mises en œuvre, vous devez prendre en compte la sécurité des threads faisant une bonne utilisation de transactions, spécialement à travers les différentes entité dépôts.

// simple example
ITransaction t = TransactionFactory.GetNewTransaction();
t.begin();
try{
    // create person entity
    personRepository.Add(person, t);
    // create cars assigned to person
    carRepository.AddRange(cars, t);
    t.commit();
}catch(Exception){
    t.rollback();
}

Juste être sûr que vous voulez vraiment créer votre propre DAL, car il peut mettre fin à être généralement complexe, spécialement en essayant de développer le plus de solution générique.

OriginalL'auteur João Simões

Tout d'abord, je tiens à vous recommander l'article Les Modèles de conception pour la Persistance des Données par Jeremy Miller.

Il y a quelques couche d'accès aux données sur les tendances:

1. Modèle d'enregistrement Active (wiki, Les informations détaillées).
2. Modèle de référentiel (Les informations détaillées).

OriginalL'auteur Sergey Brunov

Son trop vieux, mais juste venu autour de cette question et ne pouvait pas résister à poster mes pensées.

J'ai trouvé Référentiel avec UnitOfWork avec certains descente ORM est une bonne approche. Cela minimise la plupart des questions.

La UoW mentionné dans le lien ci-dessus peut être injecté dans le Dépôt. Qui augmente la flexibilité de l'utilisation. Aussi, tous les DB code de Communication est centralisée en un seul lieu. L'exemple n'est pas complète, mais un point de départ.

Modèle de référentiel mentionné dans le lien ci-dessus est en fait une classe générique de base. Vous pouvez créer une nouvelle classe pour chaque béton Référentiel qui en découle.

Générique dépôt est considéré comme un anti-modèle; il y a beaucoup beaucoup d'articles sur internet qui l'explique.

Pourquoi générique référentiel est l'anti-modèle?

1. Un référentiel est une partie du domaine modélisé, et ce domaine n'est pas générique.
   • Pas chaque entité peut être supprimé.
   • Pas chaque entité peut être ajouté
   • Pas chaque entité dispose d'un référentiel.
   • Requêtes varier énormément; le référentiel de l'API devient aussi unique que l'entité elle-même.
   • Pour GetById(), identifiant les types peuvent être différentes.
   • La mise à jour des champs spécifiques (DML) pas possible.
2. Générique mécanisme de requête est de la responsabilité de l'ORM.
   • La plupart des Orm exposer une mise en œuvre qui ressemblent étroitement à des Génériques de Référentiel.
   • Dépôts devrait être mise en œuvre de la requêtes SPÉCIFIQUES pour les entités en utilisant la requête générique mécanisme exposés par l'ORM.
3. De travail avec des clés composites n'est pas possible.
4. Il fuit DAL logique dans les Services de toute façon.
   • Prédicat critères, si vous accepter en tant que paramètre doit être fourni à partir de la couche de Service. Si c'est ORM classe spécifique, il fuit l'ORM dans les Services.

Je vous suggère de lire ces (Un, Deux, Trois, Quatre, Cinq) articles expliquant pourquoi générique référentiel est un anti-pattern.

Solution:

1. Écrire un résumé Générique Référentiel qui est enveloppé par un béton de référentiel. De cette façon, vous pouvez contrôler l'interface publique mais qui ont encore l'avantage de réutiliser le code qui vient de générique référentiel.
2. Utilisation d'un Générique de Dépôt mais ne utilisez la composition à la place de l'héritage et ne pas l'exposer au domaine en tant que contrat.

Dans tous les cas, ne pas exposer Générique Référentiel de code d'appel. Aussi, ne pas exposer IQueryable de béton dépôts.

OriginalL'auteur Amit Joshi