【求助】事务应该写在三层架构中哪一层啊？

时间：2021-11-09 05:22:54

12 个解决方案

#1

这要看你的所谓“三层架构”是哪一种。

如果你的DAL真的是专业的DAL，跟具体业务逻辑没有关系，那么你的调用事务处理的代码当然是在BLL啦，因为DAL是用来实现事务的层次，不是仅仅用来调用事务的。

有些所谓的“三层代码”，在DAL中再次搞一遍BLL功能，这种DAL根本没有存在的必要。

#2

引用 楼主 huik909 的回复:
批量插入数据至商品信息表后要求更新库存表。不知道该怎么写 
 
 
 




 事务控制当然要放在中间层
							     

							  
                        
                           
							  

							    
#3

							    



							      


引用 2 楼 lzp_lrp 的回复: 
 

   事务控制当然要放在中间层 
 
 





 能不能给个示例代码看看？ 
【求助】事务应该写在三层架构中哪一层啊？


							  
                        
                           
							  

							    
#4

							    



							      你的DAL，应该是你用来提高数据库操作效率而研发的中间件平台，跟业务逻辑并不捆绑在一起。换句话说，DAL是跟具体应用程序的BLL脱离开的，完全毫无关系的两套BLL系统可以使用同一套DAL系统。 


 例如最简单的SQL Helper就是一种DAL，当然使用EF等等也是。也可以采取任何一种自己定义的DAL中间件平台。 




							  
                        
                           
							  

							    
#5

							    



							      


引用 3 楼 huik909 的回复: 
 

   能不能给个示例代码看看？ 
  【求助】事务应该写在三层架构中哪一层啊？

 




 你的所谓DAL类型有“事务”类型的接口吗？ 


 BLL中不过就是这样写的，例如 

public void 设置任务类型(任务[] tasks)

{

    using(var conn=DAL.创建数据库连接())

    using(var tran = DAL.创建事务(conn))

    {

        foreach(var t in tasks)

        {

            conn.Save(t);

        }

        tran.Commit();

    }

}
 


 毫无疑问，你自己定义的DAL跟DAO.NET的通用的事务处理模式是一样的，因为DAO.NET也是一种DAL。
							     

							  
                        
                           
							  

							    
#6

							    



							      


引用 5 楼 sp1234 的回复: 
 
 
  

Quote: 引用 3 楼 huik909 的回复: 
   
 
    
 能不能给个示例代码看看？ 
    【求助】事务应该写在三层架构中哪一层啊？

 
  



 你的所谓DAL类型有“事务”类型的接口吗？ 
  

 BLL中不过就是这样写的，例如 
  
public void 设置任务类型(任务[] tasks)

{

    using(var conn=DAL.创建数据库连接())

    using(var tran = DAL.创建事务(conn))

    {

        foreach(var t in tasks)

        {

            conn.Save(t);

        }

        tran.Commit();

    }

}
 
  

 毫无疑问，你自己定义的DAL跟DAO.NET的通用的事务处理模式是一样的，因为DAO.NET也是一种DAL。 
 
 












 DAL没有接口
							     

							  
                        
                           
							  

							    
#7

							    



							      上面代码如果说有什么比ADO.NET更有意义的部分，就是代码 

conn.Save(t)
可以直接将 
任意实体保存到数据库中，而这其实就跟EF之类的新的框架一样、是比ADO.NET更好的地方。 


 有些8、9年前从微软模仿java而写的小项目“PetShop”的代码所抄袭到的所谓DAL的程序员，整出一个所谓的DAL来，就是针对每一个业务对象都自己再手工写一堆的DAL，这可以把人麻烦死，而且纠结不断。他们搞的其实是“四层”而不是“三层”，他们的所谓的DAL层多余的出来一层，所以会问出你的这个问题。
							     

							  
                        
                           
							  

							    
#8

							    



							      


引用 6 楼 huik909 的回复: 
 

   DAL没有接口 
 
 




 这说明你们根本不懂设计自定义设计DAL层，那就别想当然地纠结什么“三层”概念，尽量使用成熟的、高效率各种ORM数据库接口工具（用来弥补.net内存对象跟关系数据库之间差别的强大工具），而不要再来自己纠结什么DAL。 


 你不会设计自己的DAL，就用成熟的DAL类库。只要你注重BLL层设计开发，这就是“三层”开发，因为你将UI层与关系数据库真正隔离开了！ 


 千万不要把精力扯到DAL层上。整天纠结DAL层的人大概是不懂“三层”的。如果想写好三层代码，那么就算你根本不自己写一行DAL层代码，你也照样是进行三层设计和开发。
							     

							  
                        
                           
							  

							    
#9

							    



							      


引用 3 楼 huik909 的回复: 
 
 
  

Quote: 引用 2 楼 lzp_lrp 的回复: 
   
 
    

 事务控制当然要放在中间层 
   
 
  




 能不能给个示例代码看看？ 
  【求助】事务应该写在三层架构中哪一层啊？

 




 目前正在做的项目，中间层用Java写的，部署在Jboss、Tomcat、websphere或weblogic上，客户端是用c#写的 


 所有的事务控制都在中间层
							     

							  
                        
                           
							  

							    
#10

							    



							      在asp.net中许多人喜欢纠结什么“三层”。 


 实际上早在.net出现之前10年，就已经有很成熟的“三层”设计。那个时候主要是因为“客户-服务器”架构逐步取代了“终端机-主大型机”概念（那个时候有许多大公司的中型计算机或者小型计算机负责为几百个远在百公里以外的终端服务），其概念还比较明显，就是c/s架构网络业务系统要有一个前端客户端程序，然后访问集中服务器（叫做业务服务器），而业务服务器又在“背后”连着一台或者许多台数据库服务器。 


 到了java衰落而web兴起的时候，它们整出了几个经典的开源系统供大家抄袭，其中PetShop算是一个。而过了许多年，微软为了抄袭java，而也用asp.net写了一个PetShop小程序，于是asp.net程序员开始追捧起其相关的“三层”概念了，开始僵化地模仿其代码了。 


 实际上，三层概念是异常简单、层次较低的东西，只要把握原则就好了。你应该多做实际的、实用的分层设计。
							     

							  
                        
                           
							  

							    
#11

							    



							      ORM DAL仅仅是一个比SQLHelper更方便的DataHelper，不是一个可以随意添加方法改来改去的业务逻辑层。
							     

							  
                        
                           
							  

							    
#12

							    



							      事务大多数加在service层，但配置文件中一般会给dao层的加事务。也有特别特殊的会将事务加在action层
							     

							  
                        
                           
                        
                 
							    
#1

							    



							      这要看你的所谓“三层架构”是哪一种。 


 如果你的DAL真的是专业的DAL，跟具体业务逻辑没有关系，那么你的调用事务处理的代码当然是在BLL啦，因为DAL是用来实现事务的层次，不是仅仅用来调用事务的。 


 有些所谓的“三层代码”，在DAL中再次搞一遍BLL功能，这种DAL根本没有存在的必要。
							     

							  
							    
#2

							    



							      


引用 楼主 huik909 的回复: 
 

   批量插入数据至商品信息表后要求更新库存表。不知道该怎么写 
  
 
 
 




 事务控制当然要放在中间层
							     

							  
							    
#3

							    



							      


引用 2 楼 lzp_lrp 的回复: 
 

   事务控制当然要放在中间层 
 
 





 能不能给个示例代码看看？ 
【求助】事务应该写在三层架构中哪一层啊？


							  
							    
#4

							    



							      你的DAL，应该是你用来提高数据库操作效率而研发的中间件平台，跟业务逻辑并不捆绑在一起。换句话说，DAL是跟具体应用程序的BLL脱离开的，完全毫无关系的两套BLL系统可以使用同一套DAL系统。 


 例如最简单的SQL Helper就是一种DAL，当然使用EF等等也是。也可以采取任何一种自己定义的DAL中间件平台。 




							  
							    
#5

							    



							      


引用 3 楼 huik909 的回复: 
 

   能不能给个示例代码看看？ 
  【求助】事务应该写在三层架构中哪一层啊？

 




 你的所谓DAL类型有“事务”类型的接口吗？ 


 BLL中不过就是这样写的，例如 

public void 设置任务类型(任务[] tasks)

{

    using(var conn=DAL.创建数据库连接())

    using(var tran = DAL.创建事务(conn))

    {

        foreach(var t in tasks)

        {

            conn.Save(t);

        }

        tran.Commit();

    }

}
 


 毫无疑问，你自己定义的DAL跟DAO.NET的通用的事务处理模式是一样的，因为DAO.NET也是一种DAL。
							     

							  
							    
#6

							    



							      


引用 5 楼 sp1234 的回复: 
 
 
  

Quote: 引用 3 楼 huik909 的回复: 
   
 
    
 能不能给个示例代码看看？ 
    【求助】事务应该写在三层架构中哪一层啊？

 
  



 你的所谓DAL类型有“事务”类型的接口吗？ 
  

 BLL中不过就是这样写的，例如 
  
public void 设置任务类型(任务[] tasks)

{

    using(var conn=DAL.创建数据库连接())

    using(var tran = DAL.创建事务(conn))

    {

        foreach(var t in tasks)

        {

            conn.Save(t);

        }

        tran.Commit();

    }

}
 
  

 毫无疑问，你自己定义的DAL跟DAO.NET的通用的事务处理模式是一样的，因为DAO.NET也是一种DAL。 
 
 












 DAL没有接口
							     

							  
							    
#7

							    



							      上面代码如果说有什么比ADO.NET更有意义的部分，就是代码 

conn.Save(t)
可以直接将 
任意实体保存到数据库中，而这其实就跟EF之类的新的框架一样、是比ADO.NET更好的地方。 


 有些8、9年前从微软模仿java而写的小项目“PetShop”的代码所抄袭到的所谓DAL的程序员，整出一个所谓的DAL来，就是针对每一个业务对象都自己再手工写一堆的DAL，这可以把人麻烦死，而且纠结不断。他们搞的其实是“四层”而不是“三层”，他们的所谓的DAL层多余的出来一层，所以会问出你的这个问题。
							     

							  
							    
#8

							    



							      


引用 6 楼 huik909 的回复: 
 

   DAL没有接口 
 
 




 这说明你们根本不懂设计自定义设计DAL层，那就别想当然地纠结什么“三层”概念，尽量使用成熟的、高效率各种ORM数据库接口工具（用来弥补.net内存对象跟关系数据库之间差别的强大工具），而不要再来自己纠结什么DAL。 


 你不会设计自己的DAL，就用成熟的DAL类库。只要你注重BLL层设计开发，这就是“三层”开发，因为你将UI层与关系数据库真正隔离开了！ 


 千万不要把精力扯到DAL层上。整天纠结DAL层的人大概是不懂“三层”的。如果想写好三层代码，那么就算你根本不自己写一行DAL层代码，你也照样是进行三层设计和开发。
							     

							  
							    
#9

							    



							      


引用 3 楼 huik909 的回复: 
 
 
  

Quote: 引用 2 楼 lzp_lrp 的回复: 
   
 
    

 事务控制当然要放在中间层 
   
 
  




 能不能给个示例代码看看？ 
  【求助】事务应该写在三层架构中哪一层啊？

 




 目前正在做的项目，中间层用Java写的，部署在Jboss、Tomcat、websphere或weblogic上，客户端是用c#写的 


 所有的事务控制都在中间层
							     

							  
							    
#10

							    



							      在asp.net中许多人喜欢纠结什么“三层”。 


 实际上早在.net出现之前10年，就已经有很成熟的“三层”设计。那个时候主要是因为“客户-服务器”架构逐步取代了“终端机-主大型机”概念（那个时候有许多大公司的中型计算机或者小型计算机负责为几百个远在百公里以外的终端服务），其概念还比较明显，就是c/s架构网络业务系统要有一个前端客户端程序，然后访问集中服务器（叫做业务服务器），而业务服务器又在“背后”连着一台或者许多台数据库服务器。 


 到了java衰落而web兴起的时候，它们整出了几个经典的开源系统供大家抄袭，其中PetShop算是一个。而过了许多年，微软为了抄袭java，而也用asp.net写了一个PetShop小程序，于是asp.net程序员开始追捧起其相关的“三层”概念了，开始僵化地模仿其代码了。 


 实际上，三层概念是异常简单、层次较低的东西，只要把握原则就好了。你应该多做实际的、实用的分层设计。
							     

							  
							    
#11

							    



							      ORM DAL仅仅是一个比SQLHelper更方便的DataHelper，不是一个可以随意添加方法改来改去的业务逻辑层。
							     

							  
							    
#12

							    



							      事务大多数加在service层，但配置文件中一般会给dao层的加事务。也有特别特殊的会将事务加在action层
							     
标签：
相关文章