业务层，你不能知道数据库的实现细节
这个话题也是网上谈论的非常多的，你的业务层是否会包含你的数据层的相关架构技术，如，你的数据层的持久化通过ＥＦ来实现，那么你的业务层是否也应该引入EntityFrameworks程序集？占占还是会告诉你，不应该，因为这样会使你的业务不再是纯粹的业务，它会依赖由你的数据层的持久化实现的技术，这是不对的，我们需要把业务层解藕出来，只有这样，你的数据层在进行技术切换时，业务层才不会受到影响，当然，这是理所当然的，如果你的数据库换技术了，还会影响到你的业务层，那么，你这个架构本身就是失败的！
我的EF架构失败了
在我的EF架构里，业务层使用了数据层实现的entityframeworks程序集，它知道了太多持久化的方式，所以，它是失败的，你失败，因为你让我无法简单的从一种ＯＲＭ切换到别一种ＯＲＭ。
失败的原因，可以理解
之所以在业务层引用entityframeworks，原因是“事务”，为了保证数据一致性，我们会在程序中加入事务块，而有时，sql2005来说，它会将本地事务不可理解的提高为分布式事务，这对于系统来说，无疑是一种负担，所以，我只能把这个事务块进行重写，重写后使它不会触发分布式事务，但同样也出现了一个惨痛的代价，那就是，一个本地事务需要具体同一个“数据上下文”，即entityframeworks里的DbContext对象，所以，BLL层就这样，依赖了EF，失败是可以理解的。
理想的事务应该放在数据层（基础设施层，持久化层）
事务总是和数据库相关，似乎与业务没什么关系，而业务层也不应该知道你的数据采用什么样的方式进行一致性的处理，一可以用SqlTransaction,也可以用TransactionScope，或者用第三方的事务组件，但归根到底，它们都是与持久化方式（ado.net的SqlTransaction,ef,linq2sql的TransactionScope)有关的，所以，放在业务层是绝对杜绝的，以下是从《Microsoft .NET企业级应用架构设计》一书中选自的一段话
数据访问层的4种主要职责：持久化、查询、管理事务、维护并发
SQL2008是美丽的
当ＳＱＬＳＥＲＶＥＲ升级到２００８，它似乎查觉到了什么，可能是一种坏味道，一种代码的坏味道，在ＳＱＬ２００５里，一个语句被发到ＳＱＬ端，会reset一个ＳＱＬ链接，正是一个reset导致我们的net把这个过程当成是一个分布式事务来处理，而ＳＱＬ２００８里，如果你的数据库是一个，那个它就会认为，你的这个过程是一个Local session的过程，即，本地会话，本地事务！
我的贡献
下面贡献一下我的ＳＱＬ２００５同一上下文不触发ＭＳＤＴＣ的解决方案代码
/// Author:zhang.zhanling
/// 同步文章：http://www.cnblogs.com/lori/p/3455393.html
/// 对TransactionScope，让它对同一个数据库不产生msdtc服务
/// 环境：sql2005,sql2008本身已经解决了这个问题
/// </summary>
public class TransactionScopeNoMsdtc
{
/// <summary>
/// 产生包裹事务
/// 维持一个connection连接对象
/// </summary>
/// <param name="db">数据上下文</param>
/// <param name="isOutest">是否为最外层，默认为false</param>
/// <param name="action">处理代码块</param>
public static void UsingNoMsdtc(IUnitOfWork db, bool isOutest, Action action)
{
var objectContext = ((System.Data.Entity.Infrastructure.IObjectContextAdapter)db).ObjectContext;
try
{
if (objectContext.Connection.State == System.Data.ConnectionState.Closed)
objectContext.Connection.Open();
using (TransactionScope trans = new TransactionScope())
{
action();
trans.Complete();
}
}
finally
{
if (isOutest)//如果是最外层事务，再将连接关闭！内部事务与外部事务需要共用一个Connection的连接
objectContext.Connection.Close(); //只能关闭,不能dispose,因为dispose之后,上下文就无法得到链接串了
}
}
/// <summary>
/// 产生包裹事务，它不是最外层的，如果是最外层的需要调用其它重载
/// </summary>
/// <param name="db"></param>
/// <param name="action"></param>
public static void UsingNoMsdtc(IUnitOfWork db, Action action)
{
UsingNoMsdtc(db, false, action);
}
}
本文转自博客园张占岭（仓储大叔）的博客，原文链接：标准架构~业务层到底是否应该关注数据持久化的方式，如需转载请自行联系原博主。
