天然本色_玛瑙王国

没带这么玩的：-）

http://www.360doc.com/content/10/0725/13/1215901_41333835.shtml

老探长忽悠新同志啊

goushi

http://www.cnblogs.com/builderman/archive/2010/02/21/1670576.html 这里有个解决方案 可以看看

楼主 这文章 你还要继续推广 因为 三层架构被很多批为一无是处 确实很多人也没理解到三层的真正含义 特别是在 业务逻辑层中处理事务的问题 上。。 我看了你的实例 写得不错 就是命名太长 看着有点晕 呵呵

比较欣赏 这个问题也是一直迷惑我 业务逻辑层完全成了一个转发器

楼主是强人，我的QQ：2881099

欢迎交流技术！

mark，学习

这样说三层架构似乎有些笼统了。
项目要大小，以及客户的要求都会对分层架构本身产生影响。

针对事务脚本以及领域模型的应用范围，Martin Fowler的《企业应用架构模式》中给出一张图，虽不是那么准确，但很好用。

建议将项目本身要求也谈及一下，因为架构很大部分是决策。

我一直研究这些东西，感觉自己的思想还是比较成熟一些。
有机会常交流。

@徐少侠
大表拆成小表当然不算业务,或者表中添加或减少字段等和表自身有关的修改也不算是业务,我对业务的一个大方向理解是完成一个任务要哪些步骤(在数据层就是操作哪些表),小方向理解是用户名必须是英文的,等等

@ddd [未注册用户]
请下载例子

说实话，discuzNT 早前的版本，事务控制是软肋，没有做好事务控制

又是一个本末倒置的观点。并不是按xx的规定，谁谁应该在那里。而是从实际出发，他就应该在那里。呵呵，你们都习惯了一切从数据库出发，所以你们才会迷茫。先有数据库-然后orm-接着是商业对象。嘿嘿，这种方式不迷茫才怪啊。看看你们推崇的那些对象书籍，那一本是在讲orm，那一本是在讲如何和数据库打交道-------基本没有！为啥?对象原本关心的是商业对象，而不是数据库，有了商业对象就有了分层，商业对象没有和数据库打交道的能力，ok，向下编写，dal，idal。商业对象不具备界面表现，向上扩展ui，uicontrol----------至于楼主万分强调的“事务处理”，如果你有了商业对象的情况下，你认为他会在那里？？ 我来讲一下我眼中orm工具，orm工具是用来简化编写dal，idal的工作的工具，他不是商业对象本身，他只是一个辅助工具

楼主你好，你说的问题我在项目中也遇到了，
我也用的动软生成工具，业务层基本就是转发

能不能请教一下，如何在业务层实现事务处理？
也请其他知道的朋友赐教，有示例最好

大家讨论的不错。期待楼主对#29楼的回复~~

记得曾经在MSDN里见过类似的说法，我去查查

其实所谓的事务应该分两个层次的事务

其中可以分为独立数据库内的事务和分布式事务

独立数据库内的事务主要是完成数据完整性

而分布式事务则范围远大于数据库，主要是保证业务完整性。

所以，如果仅仅是为了数据完整性的，那么业务层可以不去关心事务启动与回滚。
这个可以交给数据层去完成。业务层仅需要知道整体业务的完成状态即可

而为了保证业务完整性的时候，可能多个事务之间需要同步。则此时需要在业务层面出现事务的概念。于此同时每个涉及到的数据层事务需要接收业务层的回滚或确认的指令。

--引用--------------------------------------------------
私家侦探: @ 徐少侠
事务放在业务层就不能保证数据库的数据完整性吗? no

------引用
（比如其中本来三个表的连续事务操作现在只要两个表了），则业务层中的事务处理逻辑也要有响应的变化"
------
这属于业务上的变化(如本来规定添加用户时要同时再插入日志,现在又重新规定不再插入日志了),业务层跟着变,无可厚非.

哈哈

============

反对，因为这根本不是业务上的变化。

你举的例子可以算是业务的变化，但是我也来举个例子。

本来销售记录是由销售主表和明细表实现，现在明细表拆分成了3个更小的表。不过基本的列定义没有变化。

这个也算业务上的变化吗？当数据库里出于各种目的进行表拆分后，需要去修改业务层代码吗？


--------------------------------------------------------