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之间没有明显的区别是否重要? 另外:我想的越多,也许第二个问题是应该被问到的唯一问题. 解决方法
我认为回答问题的最佳方法是退一步,考虑为什么业务逻辑层和数据访问层之间的分离是推荐的做法.
在我看来,原因很简单:将业务逻辑与数据层分开,因为业务逻辑是价值所在,数据层和业务逻辑需要或多或少地相互独立地改变,并且业务逻辑需要是可读的,而不必详细了解所有数据访问层的功能. 所以你的查询体操的试金石归结为: >您是否可以更改系统中的数据模式而不会破坏业务逻辑的重要部分?>您和其他C#开发人员的业务逻辑是否可读? (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |