Come utilizzare correttamente il pattern del repository?

Mi chiedo come dovrei raggruppare i miei repository? Come dagli esempi che ho visto su asp.net mvc e nei miei libri usano fondamentalmente un repository per tabella di database. Ma sembra che molti repository ti portino a dover richiamare molti repository in seguito per derisioni e cose del genere.

Quindi immagino che dovrei raggrupparli. Tuttavia non sono sicuro di come raggrupparli.

In questo momento ho creato un repository di registrazione per gestire tutte le mie cose di registrazione. Tuttavia ci sono tipo 4 tabelle che devo aggiornare e prima avevo 3 repository per farlo.

Ad esempio una delle tabelle è una tabella delle licenze. Quando si registrano, guardo la loro chiave e la controllo per vedere se esiste nel database. Ora cosa succede se devo controllare questa chiave di licenza o qualcos'altro da quel tavolo in un altro punto diverso dalla registrazione?

Un punto potrebbe essere il login (controlla se la chiave non è scaduta).

Allora cosa farei in questa situazione? Riscrivi di nuovo il codice (interrompi DRY)? Prova a unire questi 2 repository insieme e spera che nessuno dei metodi sia necessario in un altro momento (come forse potrei avere un metodo che controlla se userName è usato - forse ne avrò bisogno da qualche altra parte).

Inoltre, se li unissi insieme avrei bisogno di 2 livelli di servizio che vadano nello stesso repository poiché penso che avere tutta la logica per 2 parti diverse di un sito sarebbe lungo e dovrei avere nomi come ValidateLogin (), ValdiateRegistrationForm () , ValdiateLoginRetrievePassword () e così via

O chiama comunque il Repository e hai solo un nome strano in giro?

Sembra solo difficile creare un repository che abbia un nome abbastanza generico in modo da poterlo utilizzare per molti punti della tua applicazione e avere ancora senso e non penso che chiamare un altro repository in un repository sarebbe una buona pratica?

Una cosa che ho sbagliato quando ho giocato con il pattern del repository - proprio come te, pensavo che la tabella si riferisse al repository 1: 1. Quando applichiamo alcune regole dal Domain Driven Design, il problema del raggruppamento dei repository spesso scompare.

Il repository dovrebbe essere per radice aggregata e non per tabella. Significa che - se l'entità non dovesse vivere da sola (cioè - se hai una Registrantche partecipa in particolare Registration) - è solo un'entità, non ha bisogno di un repository, dovrebbe essere aggiornato / creato / recuperato attraverso il repository di root aggregato appartiene.

Ovviamente, in molti casi, questa tecnica di riduzione del numero di repository (in realtà, è più una tecnica per strutturare il modello di dominio) non può essere applicata perché si suppone che ogni entità sia una radice aggregata (che dipende molto dal tuo dominio, Posso fornire solo ipotesi cieche). Nel tuo esempio, Licensesembra essere una radice aggregata perché devi essere in grado di controllarli senza contesto di Registrationentità.

Ma questo non ci limita ai repository a cascata (il Registrationrepository può fare riferimento al Licenserepository se necessario). Ciò non ci limita a fare riferimento al Licenserepository (preferibile - tramite IoC) direttamente Registrationdall'oggetto.

Cerca solo di non guidare il tuo progetto attraverso complicazioni fornite dalle tecnologie o fraintendimenti su qualcosa. Raggruppare i repository ServiceXsolo perché non vuoi costruire 2 repository non è una buona idea.

Sarebbe molto meglio dargli un nome proprio, ad RegistrationServicees

Ma i servizi dovrebbero essere evitati in generale: spesso sono causa che porta a un modello di dominio anemico .

EDIT:
inizia a utilizzare IoC. Allevia veramente il dolore di iniettare dipendenze.
Invece di scrivere:

var registrationService = new RegistrationService(new RegistrationRepository(),  
      new LicenseRepository(), new GodOnlyKnowsWhatElseThatServiceNeeds());

potrai scrivere:

var registrationService = IoC.Resolve<IRegistrationService>();

Ps Sarebbe meglio usare il cosiddetto localizzatore di servizi comuni ma questo è solo un esempio.

Una cosa che ho iniziato a fare per risolvere questo problema è sviluppare effettivamente servizi che racchiudono N repository. Si spera che i tuoi framework DI o IoC possano aiutarti a renderlo più semplice.

public class ServiceImpl {
    public ServiceImpl(IRepo1 repo1, IRepo2 repo2...) { }
}

Ha senso? Inoltre, capisco che parlare di servizi in questo maniero possa o meno essere conforme ai principi DDD, lo faccio solo perché sembra funzionare.

Quello che sto facendo è avere una classe base astratta definita come segue:

public abstract class ReadOnlyRepository<T,V>
{
     V Find(T lookupKey);
}

public abstract class InsertRepository<T>
{
     void Add(T entityToSave);
}

public abstract class UpdateRepository<T,V>
{
     V Update(T entityToUpdate);
}

public abstract class DeleteRepository<T>
{
     void Delete(T entityToDelete);
}

Puoi quindi derivare il tuo repository dalla classe base astratta ed estendere il tuo singolo repository fintanto che gli argomenti generici differiscono per esempio;

public class RegistrationRepository: ReadOnlyRepository<int, IRegistrationItem>,
                                     ReadOnlyRepository<string, IRegistrationItem> 

eccetera....

Ho bisogno dei repository separati perché abbiamo restrizioni su alcuni dei nostri repository e questo ci offre la massima flessibilità. Spero che sia di aiuto.

Ho questo come classe di repository e sì, estendo nel repository table / area ma a volte devo rompere DRY.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MvcRepository
{
    public class Repository<T> : IRepository<T> where T : class
    {
        protected System.Data.Linq.DataContext _dataContextFactory;

        public IQueryable<T> All()
        {
            return GetTable.AsQueryable();
        }

        public IQueryable<T> FindAll(Func<T, bool> exp)
        {
            return GetTable.Where<T>(exp).AsQueryable();
        }

        public T Single(Func<T, bool> exp)
        {
            return GetTable.Single(exp);
        }

        public virtual void MarkForDeletion(T entity)
        {
            _dataContextFactory.GetTable<T>().DeleteOnSubmit(entity);
        }

        public virtual T CreateInstance()
        {
            T entity = Activator.CreateInstance<T>();
            GetTable.InsertOnSubmit(entity);
            return entity;
        }

        public void SaveAll()
        {
            _dataContextFactory.SubmitChanges();
        }

        public Repository(System.Data.Linq.DataContext dataContextFactory)
        {
            _dataContextFactory = dataContextFactory;
        }

        public System.Data.Linq.Table<T> GetTable
        {
            get { return _dataContextFactory.GetTable<T>(); }
        }

    }
}

MODIFICARE

public class AdminRepository<T> : Repository<T> where T: class
{
    static AdminDataContext dc = new AdminDataContext(System.Configuration.ConfigurationManager.ConnectionStrings["MY_ConnectionString"].ConnectionString);

    public AdminRepository()
        : base( dc )
    {
    }

Ho anche un datacontext che è stato creato utilizzando la classe Linq2SQL.dbml.

Quindi ora ho un repository standard che implementa chiamate standard come All e Find e nel mio AdminRepository ho chiamate specifiche.

Non risponde alla domanda di DRY anche se non credo.

Di seguito è riportato un esempio di un'implementazione generica del repository utilizzando FluentNHibernate. È in grado di mantenere qualsiasi classe per cui hai scritto un mappatore. È anche in grado di generare il tuo database in base alle classi mapper.

Il modello del repository è un modello di progettazione errato. Lavoro con molti vecchi progetti .Net e questo pattern tipicamente causa errori di "Transazioni distribuite", "Rollback parziale" e "Connection Pool Exhausted" che potrebbero essere evitati. Il problema è che il pattern cerca di gestire internamente le connessioni e le transazioni, ma queste dovrebbero essere gestite a livello del controller. Anche EntityFramework astrae già molta della logica. Suggerirei di utilizzare il modello di servizio invece di riutilizzare il codice condiviso.

Ti suggerisco di guardare Sharp Architecture . Suggeriscono di utilizzare un repository per entità. Lo sto usando attualmente nel mio progetto e sono molto soddisfatto dei risultati.