一直以来我都对三层架构中,业务逻辑层的存在表示怀疑,我相信有很多的初学朋友都跟我有相同的感受。业务逻辑层顾名思义就应该是处理业务逻辑的。但我一直以为它只启到数据访问层中转作用。甚至我有的项目直接放弃业务逻辑层,直接调用数据访问层的方法来做。但是随着所做项目业务逻辑越来越复杂时,渐渐的感觉到业务逻辑层所启到的作用。由于有些项目我放弃使用业务逻辑层,很多的从表示层输入的数据进行处理和有效验证的方法,我都放在在表示层来处理。但是随着逻辑复杂性的增加,表示层的代码也越来越膨大,给后期的维护带来很多的不便。
这只是其中的一个问题。当我遇到要同时操作几个表的时候,要用到事务处理,对操作失败的数据要进行回滚,如果把事务的逻辑放在数据访问层来做,同样会带来代码的复杂性,给后期维护带来不便。为此,我一直把事务处理放在存储过程中来处理。像我的项目一直使用SQL Server2000(2005)数据库的,这种方法也是行得通的,假如遇到同时要操作Oracle数据库,我看事务的处理就必须放在代码中来做。这样如果不使用业务逻辑层来处理,而放在数据访问层来处理,业务逻辑和数据访问逻辑混在一起,代码就会很混乱,给后期维护带来诸多麻烦。
上面只是我个人肤浅的感受,或许业务逻辑层还有很多更重要的作用,不妨给我指点迷津。
下面是在网络上找到一篇关于说明业务逻辑层重要性的文章供参考:或许从中能悟出点东西来
[
.NET在业务逻辑层使用事务
// 创建一个 TransactionScope 对象,并开始事务
using ( TransactionScope transScope = new TransactionScope())
{
try
{
// 利用SqlConnection完成从A地的帐户A中取款100操作
using ( SqlConnection sqlConnection = new SqlConnection(sqlConnectionString))
{
// 打开 sqlConnection 连接,系统自动使 transScope 为轻型事务,现有一个资源
sqlConnection.Open();
// 创建一个 SqlCommand 对象
SqlCommand sqlCommand = sqlConnection.CreateCommand();
// 将帐户A的余额减去100
sqlCommand.CommandText =
"UPDATE T_Balance SET C_Amount = C_Amount - 100 WHERE C_BankAccounts = 'A'";
// 预执行命令,异常的预判断,处于“挂起”状态(等待事务的提交,完成数据永久地保存)
sqlCommand.ExecuteNonQuery();
// 利用OracleConnection完成从B地的帐户B中存款100操作
using ( OracleConnection oracleConnection = new OracleConnection(oracleConnectionString))
{
// 打开 oracleConnection 连接,使 transScope 提升为完全分布式事务,现有多个资源
oracleConnection.Open();
// 创建一个 OracleCommand 对象
OracleCommand oracleCommand = oracleConnection.CreateCommand();
// 将帐户B的余额加上100
oracleCommand.CommandText =
"UPDATE T_Balance SET C_Amount = C_Amount + 100 WHERE C_BankAccounts = 'B'";
// 预执行命令,异常的预判断,处于“挂起”状态(等待事务的提交,完成数据永久地保存)
oracleCommand.ExecuteNonQuery();
}
}
// 事务提交,完成转帐
transScope.Complete();
}
catch
{
throw new Exception("转帐失败"); // 出现异常,事务自动Rollback()
}
} // using 结束
OK!如果把这段代码中对两个Connection的操作抽取并封装到数据访问层的类中,把这段代码放在业务逻辑层去访问数据访问层相应的类,这样就可以在业务逻辑层实现.NET事务。