适用于中小型项目的 ASP.NET MVC、Nhibernate 和存储库

Question

我目前正在开发一个小型 ASP.NET MVC 项目。
我正在尝试实现 Nhibernate 以持久保存在 MS Sql Server 数据库上。 在花了很长时间研究 DDD 和在 Internet 上找到的其他项目后，我决定采用存储库模式。 现在我面临着两难的境地。
使用 Nhinbernate 时我真的需要存储库吗？
拥有一个与 Nhinbernate 交互的服务层（我目前没有服务层），避免多次编写类似的内容不是更好吗：

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

我发现了一个旧的 Ayende 的 POST，它是针对存储库的。
我知道围绕这些主题存在着巨大的争论，答案总是......取决于，但在我看来，由于抽象层太多，事情会变得更加复杂且难以理解。
我错了吗？

Answer 1

Ayende 反对以您的方式编写存储库，因为您提出这个问题的原因是，它是重复的代码，而 NH 无论如何都可以处理所有这些代码。他主张像调用存储库一样直接调用 NH，而不必担心它。

我非常同意他的观点。除了付出更多的努力之外，确实没有什么收获。

Answer 2

请改用通用存储库。每个类一个存储库很容易被过度杀伤。

我使用一个包含 Get、Load、Save 方法和各种匹配方法的存储库（一种用于 Linq，一种用于我的域查询）。

public class NHibernateRepository : IRepository
{
    private readonly ISession _session;

    public NHibernateRepository(ISession session)
    {
        _session = session;
    }

    public T Load<T>(Guid id)
    {
        return _session.Load<T>(id);
    }

    public T Get<T>(Guid id)
    {
        return _session.Get<T>(id);
    }

    public void Save<T>(T obj)
    {
        _session.SaveOrUpdate(obj);
    }

    public void Delete<T>(T obj)
    {
        _session.Delete(obj);
    }

    //Get all T
    public IEnumerable<T> Matching<T>() where T : DomainObject
    {
        return _session.CreateCriteria<T>().List<T>();
    }

    //NHibernate 3.0 Linq
    public IQueryable<T> Matching<T>(Expression<Func<T, bool>> predicate)
    {
        return _session.Query<T>().Where(predicate);
    }

    public IEnumerable<T> Matching<T>(ICreateCriteria<T> query, params IAppendCriterion[] extraCriterias)
    {
        var criteria = query.GetCriteria();
        foreach (var criterion in extraCriterias)
        {
            criterion.Append(criteria);
        }

        return criteria.GetExecutableCriteria(_session).List<T>();
    }
}

最后一个方法接受 ICreateCitiera 实现。下面是接口及其一种实现。

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

这让我可以将查询分解到他们自己的类中，并轻松地在我的项目中重用它们。

Answer 3

我发现了一些你应该使用 Repository/DAO/Whatever 的原因。

1. 单元测试。我从未尝试过模拟/存根 ISession，但我想说它应该比模拟或存根存储库/DAO 接口复杂得多。
2. 代码的重用。如果您将查询直接写入服务/控制器中，那么当您需要重用特定查询时，您最终会重复它。如果您将其包装到存储库中，只需调用它的方法即可。
3. 单一职责原则。将查询分散到控制器中会让您打破这一原则。
4. NHibernate 依赖。好吧，这很难发生，但如果您需要更改 ORM，存储库会让事情变得更容易（看，这更容易，而不是容易:)）。或者甚至当您需要将用户数据源从数据库更改为 Microsoft Active Directory 时，也会更容易。

知道的就这些了，其他的想不起来了。