c# 业务层事务

步骤:

1.先添加System.Transactions.dll的引用

2.使用System.Transactions命名空间下的类

实例:

using (TransactionScope scope = new TransactionScope()) 

            //你的业务代码 
            scope.Complete(); 
}

备注:

.NET 2.0的隐式事务是比较完美的,特别是在业务逻辑层...非常不推荐用SqlConnection的事务控制,DAL换数据库怎么办?即使自己实现ITransaction接口也比用SqlConnection这种耦合度极高的方案要好得多...

时间: 2024-10-06 04:32:34

c# 业务层事务的相关文章

spring 系列5 为什么在业务层用事务

前面的操作都是在持久层使用事务.下面演示一个例子: 假设账户"小王"和"小张"各1000元. 小王去银行给小张转账100元,结果应该是:小王的金额900元,而小张的金额是1100元. 如果我们这么实现,结果会怎么样? 实体类: package com.mantishell.domain; public class Account { private Integer id; private String name; private Float money; publi

面向对象——三层架构(表现层、业务层、持久层)

三层架构:即表现层.业务层.持久层. ① 持久层:采用DAO模式,建立实体类和数据库表映射(ORM映射).也就是哪个类对应哪个表,哪个属性对应哪个列.持久层 的目的就是,完成对象数据和关系数据的转换. ② 业务层:采用事务脚本模式.将一个业务中所有的操作封装成一个方法,同时保证方法中所有的数据库更新操作,即保证同时成 功或同时失败.避免部分成功部分失败引起的数据混乱操作. ③ 表现层:采用MVC模式. M称为模型,也就是实体类.用于数据的封装和数据的传输. V为视图,也就是GUI组件,用于数据的

业务层架构模式

一:业务层架构模式概述 在三层架构中,业务层负责所有业务相关的工作,包括根据输入数据或已有数据进行计算,对从表示层输入的数据进行验证,以及根据从表示层接收的命令来确定应该调用哪些数据访问逻辑.对于应用系统来说,业务层主要维护业务逻辑,是系统的核心部分.因此,在应用系统开发时,业务层的开发是最为关键的. 业务层的架构模式有多种,最著名的就是以下两种 : 事务脚本模型(面向过程的设计) 领域模型(面向对象的设计) 二:事务脚本模型 事务脚本(Transaction Script)架构模型是按照传统的

表现层(jsp)、持久层(类似dao)、业务层(逻辑层、service层)、模型(javabean)、控制层(action)

转自:http://www.blogjava.net/jiabao/archive/2007/04/08/109189.html 为了实现web层(struts)和持久层(Hibernate)之间的松散耦合,我们采用业务代表(Business Delegate)和DAO(Data Access Object)两种模式.DAO模式为了减少业务逻辑和数据访问逻辑之间的耦合,当一个持久曾框架被应用时,该模式将会减少业务对象和该框架之间的耦合,这样我们可以不修改业务对象而选择不同的持久层框架的实现.实际

七色花基本权限系统(13)- 业务层的设计和实现

解耦WebUI层与EntityFramework 在还未实现实体仓储时,登录功能是在控制器中直接初始化EF数据库上下文来实现的,这样也导致WebUI层必须引用EntityFramework.在完成数据层的设计和实现之后,控制器中不再直接使用EF数据库上下文对象,而是通过工作单元去调用实体仓储,其实到了这一步就可以让WebUI层不再依赖EntityFramework.从WebUI层中通过nuget管理的方式移除EF,但要注意的是,EF包含2个dll,其中的EntityFramework.SqlSe

标准架构~业务层到底是否应该关注数据持久化的方式

业务层,你不能知道数据库的实现细节 这个话题也是网上谈论的非常多的,你的业务层是否会包含你的数据层的相关架构技术,如,你的数据层的持久化通过EF来实现,那么你的业务层是否也应该引入EntityFrameworks程序集?占占还是会告诉你,不应该,因为这样会使你的业务不再是纯粹的业务,它会依赖由你的数据层的持久化实现的技术,这是不对的,我们需要把业务层解藕出来,只有这样,你的数据层在进行技术切换时,业务层才不会受到影响,当然,这是理所当然的,如果你的数据库换技术了,还会影响到你的业务层,那么,你这

在javaee的三层结构中,为什么事物存在于业务层

我们都知道在javaee实际开发中,分为3层结构来开发,controller,service和dao 那么为什么事物要存在于业务层中,事物是通过connection对象操作的,使用原始jdbc链接数据库的链接也是connection操作的,connection是在到是怎么传递到dao的呢? 这里讲解两种方式第一种通过形式参数的方式第二种通过ThreadLocal的方式ThreadLocal的底层是个map,该map的key是固定的,当前线程.value可以让我们存入任意对象 public cla

爱上MVC~业务层刻意抛出异常,全局异常的捕获它并按格式返回

对于业务层的程序的致命错误,我们一直的做法就是直接抛出指定的异常,让程序去终断,这种做法是对的,因为如果一个业务出现了致命的阻塞的问题,就没有必要再向上一层一层的返回了,但这时有个问题,直接抛异常,意味着服务器直接500了,前端如何去显示,或者如果你是API的服务,如果为前端返回,如果是500,那直接就挂了,哈哈! 下面是在MVC环境下优化的全局异常捕获代码(非API) /// <summary> /// 全局异常捕获 /// </summary> public class Glo

业务层将持久层方法调用

主要业务层和持久层的联系 员工实体Bean package com.project.bean; import java.sql.Date; /** * 员工信息实体类 * @author 45470 * */ public class EmployeeBean { /**员工id*/ private int empId; /**员工登录名*/ private String empAccount; /**员工登录密码*/ private String empPwd="123456"; /