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

我正在经历一场职业生涯中期的哲学建筑危机.我看到了被认为是客户端代码(UI,Web服务,MVC,MVP等)与服务层之间的界限.尽管如此,服务层背面的线条越来越模糊.这一切都始于能够使用 Linq查询代码和Lazy加载的概念.

我创建了一个由合同和实现组成的业务层.然后,实现可能依赖于其他合同等.这是通过带有DI的IoC Container处理的.有一个服务处理DataAccess,它所做的就是返回一个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组成.可测试性内置于Repository设计中.我们可以利用内存中的实现来满足期望的结果.

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

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

因此,我的问题是：

> BLL和DAL之间没有明显的区别是否重要？
>在可以像InMemory抽象一样的Repository层后面,可查询性是否被视为数据访问或业务逻辑？

另外：我想的越多,也许第二个问题是应该被问到的唯一问题.

解决方法

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

在我看来,原因很简单：将业务逻辑与数据层分开,因为业务逻辑是价值所在,数据层和业务逻辑需要或多或少地相互独立地改变,并且业务逻辑需要是可读的,而不必详细了解所有数据访问层的功能.

所以你的查询体操的试金石归结为：

>您是否可以更改系统中的数据模式而不会破坏业务逻辑的重要部分？>您和其他C#开发人员的业务逻辑是否可读？