所以需要给DAL抽象出一个统一的接口，供其他层来操作，而底层我们可以分别使用各种ORM工具，或者原生SQL去实现。
我们希望底层的股票交易行情数据接口,数据库操作对其他层来说是透明的。
非工作单元
例如BLL将感受不到ORM工具的存在，他也不需要知道我们操作的股票交易行情数据接口,数据库是Oracle，还是MSSQLServer。
一个比较好的设计是底层实现依赖与高层抽象，而DAL不能去依赖EFDAL/NHDAL，这里使用IOC工具就能轻松实现。
它的主要功能也体现在中了：增删改服务、查询、事务管理、并发，另外事务中包括工作单元，查询中包括延迟加载。
在非工作单元的事务中，Add之后立即写入了数据库，可以看到user1已经写入数据库，并且持久化了。
关于上下文的类：
[Test]publicvoidQueryTest(){IDataContextcontext=DataContextFactory.GetDataContext();Queryquery=newQuery();//条件query.AddCriteria('Name','%yan',CriteriaOperator.Lik;query.AddCriteria('IsDelete',true,CriteriaOperator.NotEq);//排序query.AddOrderClause('CreateTime',fals;query.AddOrderClause(newOrderClause(){ascending=true,PropertyName='ID'});//根据条件查询IList
在上一篇BLL调用DAL的演示中，主要为了说明业务层事务控制方法，这次贴一个更加具体的例子。
工作单元
[Test]publicvoidPageListTest(){Queryquery=newQuery();query.AddCriteria('IsDelete',true,CriteriaOperator.NotEq);query.AddOrderClause('ID',tru;IDataContextcontext=DataContextFactory.GetDataContext();IList
你会发现许多人都在BLL直接使用ORM的上下文，那是因为DAL并没有提供统一的上下文接口，只是提供了一个统一的仓储接口。
也许你已经见过许多实用EF的架构了，它是一套基于领域模型架构中的DAL。
其中BaseDataContext就是实现了一些通用的功能，比如事务管理、工作单元、唯一标识。
所以BLL只能使用仓储接口，而不能使用上下文中事务管理和工作单元，为了的条件查询要么让仓储提供更多的查询方法，DAL中ORM特定的上下文贯穿所有层。
大致结构如中，DAL就是最下面的那一层。
园子看到过很多easyui+MVC+EF的文章，在早期，我的设计也类似。
看到中，会发现设计好DAL统一的上下文是重点，因为它将会提供给其他层统一的接口，接口的定义是一个难点。
上面的例子已经可以看到，统一的上下文能够支持条件查询和延迟加载。可以看出我使用的是那种ORM吗？
但是后来为了增强它，想加点功能通用的功能进去，就耗费了非常多的时间。
这是一个怎么样的DAL？
小结：中午时间真是短暂，时间关系就先写到这里吧，有兴趣再接下去分析。
id:1name:lucyid:3name:Lilyid:9name:ndddid:10name:13yanid:11name:yanid:41name:adama3sum:6
文章为作者独立观点，不代表股票交易接口观点
股民评论