ASP.NET MVC, Nhibernate e repository per piccoli/medi progetti

Question

Attualmente sto lavorando su un piccolo progetto ASP.NET MVC.
Sto cercando di implementare NHibernate a persistere su un database MS SQL Server. Dopo aver passato lunghe ore a studiare DDD e altri progetti trovati su Internet, ho deciso di scegliere il modello di repository. Ora sto affrontando un dilemma.
Ho davvero bisogno di un repository quando uso Nhinbernate?
Non sarebbe meglio avere un livello di servizio (non ho un livello di servizio al momento) che interagisce con Nhinbernate evitando di scrivere quante volte qualcosa di simile:

public Domain.Reminder GetById(Guid Code) 
{ 
    return (_session.Get<Domain.Reminder>(Code)); 
} 

public Domain.Reminder LoadById(Guid Code) 
{ 
    return (_session.Load<Domain.Reminder>(Code)); 
} 

public bool Save(Domain.Reminder Reminder) 
{ 
    _session.SaveOrUpdate(Reminder); 
    return (true); 
} 

public bool Delete(Domain.Reminder Reminder) 
{ 
    _session.Delete(Reminder); 
    return (true); 
} 

ho trovato un vecchio Il POST di Ayende che è contro i repository.
So che c'è un grande dibattito intorno a questi temi e la risposta è sempre ... dipende, ma mi sembra che con troppi strati di astrazioni le cose si fanno più complicate e difficile da seguire.
Mi sbaglio?

Answer 1

Ayende era contro la scrittura di un repository nel modo in cui l'hai fatto per i motivi per cui hai fatto questa domanda, è un codice ripetitivo e NH può gestirlo comunque. Egli sostiene semplicemente chiamando l'NH direttamente come se fosse un deposito, e smettila di preoccupartene.

Ho praticamente d'accordo con lui. Non c'è davvero molto da guadagnare se non per più lavoro.

Answer 2

ho trovato alcuni motivi per cui si dovrebbe usare Repository/DAO/qualunque cosa.

1. Test unità. Non ho mai provato a simulare/stub un ISession, ma direi che dovrebbe essere molto più complesso di una copiatura o di un'ostruzione di un repository/interfaccia DAO.
2. Riutilizzo del codice. Se scrivi la tua query direttamente nei tuoi Servizi/Controller, finirai per duplicarla quando dovrai riutilizzare una query specifica. Se lo hai wrapper in un repository, basta chiamare il suo metodo.
3. Single Responsibility Principle. Diffondere le tue domande attorno ai tuoi Controller ti fa infrangere questo principio.
4. Dipendenza di NHibernate. Ok, questo è difficile, ma se hai bisogno di cambiare il tuo ORM, i repository lo rendono più facile (guarda, è più facile, non facile :)). O anche quando è necessario modificare l'origine dati utente da un database a Microsoft Active Directory, sarebbe più semplice.

Questo è tutto per sapere, non ricordo altro.

Answer 3

Utilizzare un repository generica, invece. Un repository per classe può facilmente essere eccessivo.

Io uso un repository con i metodi Get, Load, Save e vari metodi Matching (uno per Linq e uno per le mie query di dominio).

L'ultimo metodo accetta un'implementazione ICreateCritiera. Di seguito l'interfaccia e una sua implementazione.

public interface ICreateCriteria<T> : ICreateCriteria 
{ 
    DetachedCriteria GetCriteria(); 
} 

public class ChallengesAvailableToRound : ICreateCriteria<Challenge> 
{ 
    private readonly Guid _roundId; 

    public ChallengesAvailableToRound(Round round) 
    { 
     _roundId = round.Id; 
    } 

    public DetachedCriteria GetCriteria() 
    { 
     var criteria = DetachedCriteria.For<Challenge>(). 
      CreateAlias("Event", "e"). 
      CreateAlias("e.Rounds", "rounds"). 
      Add(Restrictions.Eq("rounds.Id", _roundId)); 

     return criteria; 
    } 
} 

Questo mi consente di suddividere le query nelle proprie classi e riutilizzarle facilmente in tutto il mio progetto.