C#事务的添加以及思路

引言：学贵精不贵博，知得十件而都不到地,不如知得一件却到地也!
相信很多童鞋跟我一样，作为一个非软件公司的IT程序员，有很多悲哀的地方，比如大工厂的软件都是成型的，如果需要添加业务，都是在原有框架上添加业务内容，因此也导致了我们永远也不会有对整个软件的框架理解或实践的提高，另外一点，很多工具类都让前辈给封装好了，只需要直接调用就行，无需走到里面详细写代码，好处是规避了新手写代码的时候出现的一些低级性常规严重错误，坏处是，后辈如果自己新写用具类，则无法避免相关的低级严重错误。
正题：
上礼拜接手了一个需要改的BUG的案子，问题是这样的，业务单代码被分了2部分，一分部写在了后台逻辑层中，另一部分通过逻辑层中某张表的变更来触发trigger （工厂老司机提示各个码农，“trigger好顺手，使用需谨慎”，别特是我们这种做产线软件的，因为一旦出现问题，需要24H stand by,那就是自己挖坑埋自己，trigger是很难查到原因的，trigger会导致出现问题的蛛丝马迹直接断掉，除非你万年开车不翻车，或者对业务很熟悉），然后问题来了，因为没有写事务，导致前半部分，后台逻辑中的业务执行完成，但是trigger中的某项内容出错，然后trigger中的业务没执行完成，但是无法回滚，导致整个业务是错误的，所以我需要把trigger的业务搬到后台逻辑层中，并且把事务添加进去。
然后问题来了，之前写的代码全部是工具封装好的，就是直接"工具类.事务开启、工具类.事务回滚、工具类.事务提交、工具类.增删改查"，然后就一脸懵逼，自己想怎么写事务，怎么处理。
思路：
事务从头到尾都应该是一个事务，流程应该是：1.建立连接；2.事务开启；3.建立操作对象；4.连接、事务付给操作对象；5.完成数据库的操作；6.1.出错则回滚；6.2正确则提交；7.销毁操作对象；8.关闭连接。其中第3、4、5应该是多次操作，1,2,6,7,8应该是在业务开始和完成(操作成功提交或者失败回滚)后完成的。既然这样，那是否可以这样，把这些步骤放在一个新建的DBClass类中，在需要完成一个业务交互时，就初始化一个DBClass的实例对象，而1.连接的建立和2.事务的