数据访问层应该如何构建？

Question

我最初按照此代码项目文章中概述的s#体系结构示例设计了我的系统(不幸的是,我没有使用NHibernate).基本思想是,对于需要与持久层进行通信的每个域对象,您将在不同的库中具有相应的数据访问对象.每个数据访问对象都实现一个接口,当域对象需要访问数据访问方法时,它始终对接口进行编码,而不是对DAO本身进行编码.

当时,我仍然认为这种设计非常灵活.但是,随着我的域模型中对象数量的增加,我发现自己在质疑这里是否存在组织问题.例如,域中的几乎每个对象都以相应的数据访问对象和数据访问对象接口结束.不仅如此,但如果我想做一些简单的事情,比如转移一些命名空间,那么这些中的每一个都处于一个更难以维护的地方.

有趣的是,许多这些DAO(及其相应的接口)都是非常简单的生物 - 最常见的只有一个GetById()方法.我最终得到了一大堆对象,比如

public interface ICustomerDao {
  Customer GetById(int id);
}

public interface IProductDao {
  Product GetById(int id);
}
public interface IAutomaticWeaselDao {
  AutomaticWeasel GetById(int id);
}

他们的实现者通常也非常琐碎.这让我想知道走向不同的方向是不是更简单,也许通过为简单的数据访问任务设置单个对象来切换我的策略,并为那些需要更多东西的人保留专用数据访问对象的创建复杂.

public interface SimpleObjectRepository {
      Customer GetCustomerById(int id);
      Product GetProductById(int id);
      AutomaticWeasel GetAutomaticWeaselById(int id);
      Transaction GetTransactioinById(int id);
}
public interface TransactionDao {
  Transaction[] GetAllCurrentlyOngoingTransactionsInitiatedByASweatyGuyNamedCarl();
}

有没有人有这样的架构的经验？总的来说,我对设置非常满意,因为现在我唯一担心的是管理所有这些小文件.我仍然想知道存在什么其他方法来构建数据访问层.

Answer 1

我建议不要在简单系统中使用简单的方法，通常我认为你最好为每个聚合创建一个自定义存储库，并在其中封装尽可能多的合适逻辑。

因此，我的方法是为每个需要它的聚合建立一个存储库，例如 CustomerRepository。这将有一个添加（保存）方法，如果适合该聚合，还有一个删除（删除）方法。它还将具有任何其他适用的自定义方法，包括查询 (GetActive)，并且也许其中一些查询可以接受规范。

这听起来需要付出很大的努力，但除了自定义查询之外，大多数代码（至少如果您使用的是现代 ORM）都非常容易实现，因此我使用继承（ReadWriteRepositoryBase，其中 T: IAggregateRoot）和/或组合（调用到 RepositoryHelper 类）。基类可能具有适用于所有情况的方法，例如 GetById。

希望这可以帮助。