Question

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

我创建了一个由合同和实现组成的业务层。然后，实现可能依赖于其他合同等。这是通过带有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();
}

Repository是通用的，适用于两种实现（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抽象？

补充：我想的越多，也许第二个问题是唯一应该被问到的问题。

Answer 1

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

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

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

您是否可以更改系统中的数据架构而不会破坏大部分业务逻辑？
您和其他C＃开发人员的业务逻辑是否可读？

Answer 2

1。只有你更关心哲学而不是完成任务。：）

2。我会说这是业务逻辑，因为你之间有一个抽象。我将该存储库层称为DAL的一部分，以及使用它的任何东西，BL。

但是，这对我来说也很模糊。我不认为这很重要。使用这样的模式的目的是编写一个易于同时通信的干净，可用的代码，并且无论如何都可以实现这一目标。

Answer 3

1. BLL与DAL之间没有明显的区别是否重要？

确实很重要！任何使用Table属性的程序员都需要了解分支（数据库往返，查询转换，对象跟踪）。这也适用于程序员阅读业务逻辑类。

2.可查询性是否在Repository层后面考虑了数据访问或业务逻辑，其作用类似于InMemory抽象？

抽象是我们隐藏我们的问题的毯子。

如果您的抽象是完美的，那么查询可以被抽象地视为针对内存中集合进行操作，因此它们不是数据访问。

然而，抽象泄漏。如果您想要在数据世界中有意义的查询，必须努力在抽象之上和之外工作。额外的努力（这会破坏抽象）会产生数据访问代码。

一些例子：

output = work.GetRepository<Bar>().Table.ToArray();

这是代码（抽象地）罚款。但是在数据世界中，它导致扫描整个表格，并且（至少一般）是哑巴！

badquery = work.GetRepository<Customer>().Table.Where(c => c.Name.Contains("Bob")).ToArray(); 
goodquery = work.GetRepository<Customer>().Table.Where(c => c.Name.StartsWith("Bob")).ToArray();

当Customer.Name上有索引时，Goodquery比查询错误更好。但除非我们取消抽象，否则我们无法获得这一事实。

badquery = work.GetRepository<Customer>().Table
  .GroupBy(c => c.Orders.Count())
  .Select(g => new
  {
    TheCount = g.Key,
    TheCustomers = g.ToList()
  }).ToArray();
goodquery = work.GetRepository<Customer>().Table
  .Select(c => new {Customer = c, theCount = c.Orders.Count())
  .ToArray()
  .GroupBy(x => x.theCount)
  .Select(g => new
  {
    TheCount = g.Key,
    TheCustomers = g.Select(x => x.Customer).ToList()
  })
  .ToArray();

goodquery优于错误查询，因为badquery将按组键重新查询数据库，对于每个组（更糟糕的是，有一个索引可以帮助按c.Orders.Count()过滤客户。）

可测试性内置于Repository设计中。我们可以利用InMemory实现来预期结果。

如果您实际针对内存中的集合运行它们，请不要幻想您的查询正在进行测试。除非涉及数据库，否则这些查询是不可测试的。

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

3 个答案:

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

3 个答案:

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