c# - C# 中的可查询性和延迟加载是否模糊了数据访问与业务逻辑的界限？

Question

我正在经历职业生涯中期的哲学架构危机。我看到被认为是客户端代码(UI、Web 服务、MVC、MVP 等)和服务层之间的界限非常清晰。不过，服务层后面的界线越来越模糊。这一切都始于使用 Linq 查询代码的能力和延迟加载的概念。

我创建了一个由契约和实现组成的业务层。然后，实现可以依赖于其他契约(Contract)等。这是通过带有 DI 的 IoC 容器处理的。有一个处理数据访问的服务，它所做的只是返回一个 UnitOfWork。此 UnitOfWork 在具体化时创建一个事务，并在 Commit 方法上提交数据。 [ View this Article (Testability and Entity Framework 4.0) ]:

public interface IUnitOfWork : IDisposable {
   IRepository<T> GetRepository<T>() where T : class;
   void Commit();
}

存储库是通用的，适用于两种实现(EF4 和 InMemory DataStore)。 T 由从数据库架构或 EF4 映射生成的 POCO 组成。可测试性内置于存储库设计中。我们可以利用内存中的实现来断言符合预期的结果。

public interface IRepository<T> where T : class {
   IQueryable<T> Table { get; }
   void Add(T entity);
   void Remove(T entity);
}

虽然数据源是抽象的，但 IQueryable 仍然让我能够在业务逻辑中的任何地方创建查询。这是一个例子。

public interface IFoo {
   Bar[] GetAll();
}

public class FooImpl : IFoo {
   IDataAccess _dataAccess;
   public FooImpl(IDataAccess dataAccess) {
      _dataAccess = dataAccess;
   }

   public Bar[] GetAll() {
      Bar[] output;
      using (var work = _dataAccess.DoWork()) {
          output = work.GetRepository<Bar>().Table.ToArray();
      }
      return output;
   }
}

现在您可以看到，当您使用复杂的过滤器执行连接时，查询如何变得更加复杂。

因此，我的问题是:

1. BLL 和 DAL 之间没有明确的区别是否重要？。
2. 在类似于 InMemory 抽象的存储库层后面时，可查询性是否被视为数据访问或业务逻辑？

补充:我越想越觉得应该问的只有第二个问题。

Answer 1

我认为回答您的问题的最佳方式是退后一步，考虑一下为什么业务逻辑层和数据访问层之间的分离是推荐的做法。

在我看来，原因很简单:将业务逻辑与数据层分开，因为业务逻辑是值(value)所在，数据层和业务逻辑需要随着时间的推移或多或少地相互独立地发生变化，并且业务逻辑需要可读，而无需详细了解所有数据访问层的功能。

因此，您的查询体操的试金石归结为:

1. 您能否在不扰乱大部分业务逻辑的情况下更改系统中的数据架构？
2. 您和其他 C# 开发人员可读您的业务逻辑吗？