数据访问层——模块化和可重用性

Question

我对此非常陌生，我正在努力寻找最适合我的数据访问层架构。 我的解决方案有 3 层：

1. 表示层 - ASP.net 应用程序
2. 业务逻辑层 - C# 对象和逻辑
3. 数据访问层 - 调用存储过程的函数。

我想更换数据访问层。

例如，如果我使用实体框架或 NHibernate，什么将确保稍后我能够替换该数据访问层而不需要更改业务逻辑层？
实体框架或 NHibernate 中的接口的使用从何而来？

Answer 1

设计一个接口来映射您将在 DAL 中使用的所有关键方法。然后仅通过接口引用 DAL 类。这将通过将各层相互解耦来赋予其模块化性。

每当您需要交换所述DAL时，您只需插入一个实现所述接口的新DAL即可。您的其余代码不会因更改而变得更明智。

只是解决您的问题的一种方法。

Answer 2

为了保留业务层，您还必须保留模型。因为业务和模型有着非常紧密的联系。

您可以更改是将模型映射到数据库的层。

NHibernate 和 Entity Framework 4.1 都允许我们所说的 POCO 对象。 POCO 对象是纯 CLR 对象，不引用任何特定于持久性的类。也就是说：它不包含任何属性或基类，或将该类耦合到程序集的方法调用。使用 NHibernate 时，您可以使用 XML 文件或使用 Fluent NHibernate 的流畅方法将这些 POCO 类映射到数据库。在 EF4.1 中，您只能使用 Fluent 方法。

您必须关心的一件事是存储过程的使用。这本质上会损害持久层替换。 EF4.1 POCO 方式目前不支持存储过程。 NHibernate 可能会，但我不确定。

编辑

正如马修·考克斯提到的。当然，当涉及到 DAL 类时，就需要接口。因为CRUD操作在持久层之间会有所不同。这些接口将允许持久性替换。

例子：

public class IPersonDAL {
    IList<Person> GetPeople();
    void InsertPerson(Person person);
    ...
}

Answer 3

具体来说，nHibernate (3.0+) 和 EF 支持 LINQ，因此您可以通过代码创建一个简单的 IRepository 接口，该接口接受 Expression> 并避免使用具有 GetPersonByID、getPersonByName 等的存储库虽然这可能会妨碍您交换 ORM，但我认为您不会使用不支持 LINQ 的 ORM。

这个界面可能看起来像这样（这不是一个完整的实现！这只是一个演示，真正的界面需要更好的改进！这只是我的东西）现在已经模拟了！这可能还需要实现 IDisposable 等）：

interface IRepository<TPersistant>
{
      void Save(TPersistant item);
      void Delete(TPersistant item);

      TPersistant Find(Expression<Func<TPersistant,bool>> predicate); 
      // maybe findOne or findMany

      // maybe something like this
      IQueryable<TPersistant> Query();
      /* Other stuff like updating, transactions, commiting, etc.*/
}

但是，我想提一下人们在抽象 DAL 时忽略的一些事情。 此o/c仅是我的意见。

虽然抽象可以帮助你在未来“交换”DAL，但我会认真思考你是否能从中获得任何东西，除了创建遵循“最佳实践”和“人们说你应该做什么”的软件，另一方面搬起石头砸自己的脚。

当您完全抽象 DAL 时，您可能会失去其他 ORM 特定功能，这些功能实际上使一个 ORM 比另一个更好，甚至可能会丢失未来为了抽象而进行的性能优化。 i/e nHibernate 中的未来查询（在我看来这是一个巨大的功能），如果你将其抽象出来，你基本上会丢失它。您还可能会失去延迟初始化优化（选择 N+1 问题），因为您无法使用 Fetch (nHibernate) 或 Include (EF)。即使是像枚举支持这样的小事情（我相信 EF 仍然不支持）。

我还想补充一点，许多开发人员为了未来的变化而创建抽象，而实际上这些变化几乎永远不会发生。

因此，虽然我不是说不要抽象 DAL，因为它有很多优点，例如单元测试、解耦等（尽管您始终可以创建一个耦合的-to-dal 存储库，这将有助于单元测试），如果值得为某些实际上使 nhibernate/EF 比其他更好的功能付出代价，那么应该认真考虑。