@H_301_1@我正在经历一场职业生涯中期的哲学建筑危机.我看到了被认为是客户端代码(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层后面,可查询性是否被视为数据访问或业务逻辑？
另外：我想的越多,也许第二个问题是应该被问到的唯一问题.
