ASP.NET MVC, Nhibernate y repositorios para proyectos pequeños/medianos

Question

Estoy trabajando en un pequeño proyecto ASP.NET MVC en este momento.
Estoy tratando de implementar Nhibernate para persistir en una base de datos de MS Sql Server. Después de haber pasado largas horas estudiando DDD y otros proyectos encontrados en Internet, he decidido ir al patrón de repositorio. Ahora estoy enfrentando un dilema.
¿Realmente necesito un repositorio cuando uso Nhinbernate?
¿No sería mejor tener una capa de servicio (no tengo una capa de servicio en el momento) que interactúa con Nhinbernate evitando escribir muchas veces algo así:

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); 
} 

me encontré con un viejo POST de Ayende que está en contra de los repositorios.
Sé que hay un gran debate sobre estos temas y la respuesta es siempre ... depende, pero me parece que con demasiadas capas de abstracciones las cosas se vuelven más complicadas y difíciles de seguir.
¿Estoy equivocado?

Answer 1

Ayende estaba en contra de escribir un repositorio de la forma en que lo hizo debido a las razones por las que hizo esta pregunta, es un código repetitivo y NH puede manejarlo de todos modos. Él aboga por simplemente llamar a NH directamente como lo haría con un repositorio, y dejar de preocuparse por ello.

Estoy bastante de acuerdo con él. Realmente no hay mucho que ganar, excepto por más trabajo.

Answer 2

Encontré algunas razones por las que debería usar Repository/DAO/Whatever.

1. Unit Testing. Nunca intenté burlarme o ponerme un trozo de ISession, pero diría que debería ser MUCHO más complejo que burlar o pegar un Repositorio/Interfaz DAO.
2. Reutilización del código. Si escribe su consulta directamente en sus Servicios/Controladores terminará duplicándola cuando necesite reutilizar una consulta específica. Si lo tiene envoltorio en un repositorio, simplemente llame a su método.
3. Single Responsibility Principle. Difundir sus consultas alrededor de sus Controladores le hace romper este principio.
4. NHibernate Dependency. Ok, esto es difícil de pasar, pero si necesitas cambiar tu ORM, los repositorios lo hacen más fácil (mira, es más fácil, no fácil :)). O incluso cuando necesite cambiar el usuario DataSource de una Base de datos a Microsoft Active Directory, sería más fácil.

Eso es todo, no recuerdo nada más.

Answer 3

Use en su lugar un repositorio genérico. Un repositorio por clase puede ser exagerado.

Utilizo un repositorio con Get, Load, Save métodos y varios métodos de coincidencia (uno para Linq y otro para mis consultas de dominio).

El último método acepta una implementación de ICreateCritiera. A continuación se muestra la interfaz y una implementación de la misma.

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; 
    } 
} 

Esto me permite dividir las consultas en sus propias clases y volver a utilizarlas en todo mi proyecto con facilidad.