Generisches Repository, Data Access Layer

Dem repository-Muster ist eine große Muster zu verwenden, aber wenn es nicht richtig gemacht wird, anstatt das Leben leichter, es wird ein großer Schmerz!

So, die beste Möglichkeit, dies zu tun (da Sie nicht verwenden möchten, EF oder anderen ORM) ist durch die Schaffung einer generischen Schnittstelle, und dann eine base abstrakten Implementierung. Auf diese Weise brauchen Sie nicht, um code-repository, können Sie einfach instanziieren Sie von der Art!

Und nach diesem, wenn Sie bestimmte spezifische Methode, um einige Ihrer Einheiten, Sie können alle Erben aus dem Repository und Methoden überschreiben oder hinzufügen und die Eigenschaften als benoetigten.

Wenn Sie möchten, verwenden Sie das Repository-Muster, das ich auch empfehlen, dass Sie die IUnitOfWork Muster, und halten Sie es getrennt aus dem repository.

Beide interfaces sollte wie folgt Aussehen:

Sehr einfache IUnitOfWork:

Public interface IUnitOfWork
{
    bool Save();
}

Und Ihnen, den Repository-interface, Verwendung von Generika:

public interface IRepository<TEntity> : IDisposable where TEntity : class

    IUnitOfWork Session { get;}

    IList<TEntity> GetAll();
    IList<TEntity> GetAll(string[] include);
    IList<TEntity> GetAll(Expression<Func<TEntity, bool>> predicate);

    bool Add(TEntity entity);
    bool Delete(TEntity entity);
    bool Update(TEntity entity);
    bool IsValid(TEntity entity);
}

Methoden .Add(), .Löschen (), sollten Sie nicht senden Sie alles an die Datenbank, aber Sie sollten immer senden die änderungen an der IUnitOfWork (, die Sie implementieren können, in der Sie DAL-Klasse), und nur, wenn Sie rufen .Save () - Methode der IUnitOfWork Sie speichern Dinge in der Datenbank.

Implementierte ich meine Repository-Klasse mit EntityFramework, und das macht die Dinge einfacher, aber Sie können es tun, wie Sie wollen.

Den code ein, den Sie verwenden werden somethin wie diese:

void SomeMethod()
{
    using (IUnitOfWork session = new YourUnitOfWorkImplementation())
    {
        using (var rep = new Repository<Client>(session))
        {
            var client1 = new Client("Bob");
            var client2 = new Cliente("John");
            rep.Add(client1);
            rep.Add(client2);
            var clientToDelete = rep.GetAll(c=> c.Name == "Frank").FirstOrDefaut();
            rep.Delete(clientToDelete);

            //Now persist the changes to the database
            session.Save();

        {
    {
}

Wie gesagt, mit EF und den DbContext, das ist viel einfacher, hier sind ein kleiner Teil meiner Repository-Klasse:

public class Repository : Component, IRepository
{


    protected DbContext session;
    {
        get
        {
            if (session == null)
                throw new InvalidOperationException("A session IUnitOfWork do repositório não está instanciada.");
            return (session as IUnitOfWork);
        }
    }

    public virtual DbContext Context
    {
        get
        {
            return session;
        }
    }

    public Repository()
        : base()
    {
    }

    public Repository(DbContext instance)
        : this(instance as IUnitOfWork)
    {


    #endregion


    public IList<TEntity> GetAll<TEntity>() where TEntity : class
    {
        return session.Set<TEntity>().ToList();
    }


    public bool Add<TEntity>(TEntity entity) where TEntity : class
    {
        if (!IsValid(entity))
            return false;
        try
        {
            session.Set(typeof(TEntity)).Add(entity);
            return session.Entry(entity).GetValidationResult().IsValid;
        }
        catch (Exception ex)
        {
            if (ex.InnerException != null)
                throw new Exception(ex.InnerException.Message, ex);
            throw new Exception(ex.Message, ex);
        }
    } ...

Diese Weise werden Sie nicht brauchen, um zu bauen ein GetEmployeeByAge, Sie würde einfach schreiben:

IEnumerable<Employee> GetEmployee(int age)
{
 return  rep.GetAll<Employee>(e=> e.Age == age);
}

Oder Sie könnten einfach direkt anrufen (keine Notwendigkeit zu schaffen, die Methode)

Ja, man könnte einfach schreiben Sie eine elegante DAL-layer, basierend auf einer generischen Konstante repository-Schnittstelle.

Wäre es wahrscheinlich eine lächerlich schlechte Leistung, obwohl.

In einer perfekten Welt, wo alle Informationen abgerufen werden konnten, von der DB ohne Kosten, eine einfache und generische repository genug sein würde. Leider ist das nicht der Fall - es ist besser, bestimmte query-Methoden, für jeden query-operation, die wir wissen, dass unsere Datenbank verarbeiten kann, als ein generisches repository, die generische Abfrage-Methoden, so dass alle Arten von verrückt-Abfragen, die aus der business-Schicht.

Bearbeiten

Ich glaube, Sie scheinen falsch zu sein in Bezug auf einen ganz bestimmten Punkt: das vermeiden der Verwendung einer generischen ORM-Mapping-Bibliothek bedeutet, dass Sie nicht tun, ORM. Dies ist nicht unbedingt wahr.

Es sei denn, Sie setzen generische array-ähnliche Objekte, um die Benutzeroberfläche (das würde auch diese Diskussion über das Repository-Muster komplett nutzlos ist), Sie sind Transformation von relationalen Daten in die Domänen-Objekte. Und das ist genau das, was ORM ist über: die Tatsache, dass Sie nicht mit NHibernate, EF noch LINQ to SQL bedeutet nur, Sie haben viel mehr Arbeit. 🙂

So, Nein, mit dem Repository-Muster noch Sinn macht, egal, ob man mit einer automatischen ORM-tool ist oder nicht.

Natürlich gibt es andere Optionen, wie die Active Record. Dies ist eine einfachere Muster, die mischt das domain-Objekt mit Daten zugreifen, die Logik (und die Verwendung eines ORM-tool ist hier ebenfalls optional).