|
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
时间：2008-04-29
ltian 写道 通过代码跟踪来知道那些方法参与到同一事务中。 与查看配置来知道哪些方法参与到同一事务中哪个更好呢？我喜欢前者，因为前者在出现问题时，我可以确切知道问题所子啊，而通过配置的查看，还要判断这个配置的有效性，是否别的配置对其有影响等等。 事务绑定在当前线程，并随线程传播， 所以，如果A有事务并且A call B,B又call了C，那么三者都参与到了事务，根本不需要看BC的配置 |
| 返回顶楼 | |
|
时间：2008-04-29
ltian 写道 daquan198163 写道 ltian 写道 用AOP实现的事务管理在少量使用的时候也就罢了，大量使用就很难调试了。
……………… 配置是否麻烦这样的事情取决于你开发应用的规模，如果你构建的系统包括二十多个子系统的时候，需要事务管理的地方太多了，都用配置来搞，难道你觉得很简单吗？ 我猜测您很可能不知道一个技术细节——Spring声明式事务的配置可以简化 况且你的几十个子系统，如果用配置来搞都嫌太麻烦的话，编程式事务管理就更不可想象了，会死人的！ 大量使用就很难调试了？ 只有编程式事务管理才需要调试，所以，这个问题又是你们自己发明出来的 通过代码跟踪来知道那些方法参与到同一事务中。 与查看配置来知道哪些方法参与到同一事务中哪个更好呢？我喜欢前者，因为前者在出现问题时，我可以确切知道问题所子啊，而通过配置的查看，还要判断这个配置的有效性，是否别的配置对其有影响等等。 它的初衷就是让程序员抛开事务~ 直接关注业务逻辑~ 现在你确说我要关注的是事务。 嗯~ 也许你的需求太复杂了吧~ 不敢妄加揣测~ |
| 返回顶楼 | |
|
时间：2008-04-29
ajax 写道 rain2005 写道 看来大家都很喜欢spring啊，我就是想表达我现在使用spring的地方已经有更简单的实现了。spring的声明事务和资源管理，还有就是ioc。哦忘了强调一下，我使用hibernate，它已经实现了资源管理就算是其它的持久框架实现这点也是相当的简单。事务我用filter不行吗？ioc用guice多简单啊。那我还需要spring干嘛？也许大家使用spring干了很多工作，但是我只需要这些。
再补充一句，你所列举的solution，比spring提供的很有优势？如果没有，那你的意思是什么？满足一下你的技术虚荣心，看看我的架构，都可以不用Spring了？ 这个很中肯，因为spring也没号称别人离了它就会死。但是自己搞解决方案的话，比spring的优势在哪里？如果没有明显由于spring的地方，那为什么要without？仅仅是为了说“看我多牛x，当年有人鼓吹without ejb再搞一个spring出名了，我现在without spring了，更牛？” |
| 返回顶楼 | |
|
时间：2008-04-29
标题和LZ要表达的意思可能不符合～
^_^ |
| 返回顶楼 | |
|
时间：2008-04-29
Hibernate的API如果原生的就能够支持嵌套事务的话，那就更加有利于Spring的声明式事务管理了。
|
| 返回顶楼 | |
|
时间：2008-04-29
firewood 写道 ltian 写道 daquan198163 写道 ltian 写道 用AOP实现的事务管理在少量使用的时候也就罢了，大量使用就很难调试了。
……………… 配置是否麻烦这样的事情取决于你开发应用的规模，如果你构建的系统包括二十多个子系统的时候，需要事务管理的地方太多了，都用配置来搞，难道你觉得很简单吗？ 我猜测您很可能不知道一个技术细节——Spring声明式事务的配置可以简化 况且你的几十个子系统，如果用配置来搞都嫌太麻烦的话，编程式事务管理就更不可想象了，会死人的！ 大量使用就很难调试了？ 只有编程式事务管理才需要调试，所以，这个问题又是你们自己发明出来的 通过代码跟踪来知道那些方法参与到同一事务中。 与查看配置来知道哪些方法参与到同一事务中哪个更好呢？我喜欢前者，因为前者在出现问题时，我可以确切知道问题所子啊，而通过配置的查看，还要判断这个配置的有效性，是否别的配置对其有影响等等。 它的初衷就是让程序员抛开事务~ 直接关注业务逻辑~ 现在你确说我要关注的是事务。 嗯~ 也许你的需求太复杂了吧~ 不敢妄加揣测~ 初衷都是好的，事务是客观存在的，当事务出现混乱时，调试不了是很痛苦的事情。业务大家都能保证程序里面配置即正确。 |
| 返回顶楼 | |
|
时间：2008-04-29
AOP，企业开发的重要工具 核心思想！想不明白楼主！
|
| 返回顶楼 | |
|
时间：2008-04-29
spring2.5的配置应该还可以了吧
远程调用确实不够好 acegi还是不错的 AOP还是多数人的选择 大型应用不能说改就改,历史遗留问题,技术不能单走还要更上现实 |
| 返回顶楼 | |
|
时间：2008-04-29
楼主没必要这么否定spring,spring对于事物的管理更加灵活，它使用的是AOP织入形式完成的操作，而且2。0支持元数据，对于事物管理的配置已经非常少了，少到只需要定义一个描述位置，再配制文件里面加如一个事物驱动，和一个事物管理类就行了。而且自动装配也加近来了，可以不用手动去填写好多的依赖注入的元素。对于配制过度的问题可以通过定义父bean和子bean还有自动装配等形式进行解决了。而且我感觉楼主把AOP理解太狭隘了，它不光可以实现事物，其实你应该去考虑一下AOP可以做很多事情，比如说性能监测和系统日志，优秀的框架性能监测都是可以配制的。如果你光把AOP理解成对事物的支持，那我也没话说了。
|
| 返回顶楼 | |
|
时间：2008-04-29
楼上的别吵了，我在几个外包公司作过项目，只用struts 1和自己的框架，从没哪个用spring，hibernate的，为外国人的框架吵来吵去，值得吗？适用就好，没有必要鼓吹！
|
| 返回顶楼 | |
