Hibernate和Spring的决裂以及Spring和EJB3之争

查了下,目前的版本不可以,主要考虑对jdk的兼容,可能是因为涉及到核心部分的改动.
而对@Transactional这个的支持不同,在实现上不涉及核心的改动.

我们将在下一个版本中发布embedded container . 方便用户进行开发。 我们可以单独将这个容器发布出来，可以让用户更灵活的开发Service层。同时也支持类似的IOC实现。
给个简单的例子:

@Service(name="myService");
public class MySerivce {
@PersistenceContext(unitName="order");
EntityManager orderEM;
@PersistenceContext(unitName="other");
EntityManager otherEM;
@Service(name="otherSerivce",singleton="true");
private OtherSerivce otherService;

@transaction(propagete="newTransaction" );
public void service(int orderID); {
Order order=orderorderEM.find(Order.class,new Integer(orderID););;
OtherEntity other=new OtherEntity(1,order);;
otherEM.save(other);;

}

}

这里的Service不用实现任何Template,您需要做的仅仅是声明使用一个orderEM和一个otherEM . 其中的 unitName说明这两个EM的获取方式，他们有可能是从不同EMFactory获取。

另外，虽然从这段代码来看orderEM 和 OtherEM是instance variable,但是他们在实际代码中不是作为实例变量来获取的，我们仅仅利用它来声明一种获取EM的方式和可编译的编写业务代码的而已。

这样的话，还不如setter来得标准。反正只需要提供setter，管它是什么bean工厂来做inject.

其实不是拘泥语法，用不用setter，annotation还是xml。我只是觉得spring应该满足这样一个要求
：
我不需要使用或者继承spring的模板才能获得注入资源并和transaction关联。也就是说在代码中我不需要import ...spring...;的包就可获得注入和自动事务管理等能力。（当然，产生business object的代码还是要用spring的包咯）。对于需要extends XXXsuport的做法实在是不舒服。

对于setter，如果我在annotation/xml种定义了我要的资源，我就应该不用写setter。能省就省，技术上也很容易实现。
一个更重要的考虑，如果注入的资源和事务相关，那就不是简单的set就可以了。

我对spring了解不多，不对地方清纠正。

http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/
在这个讨论里Juergen Hoeller说明了HibernateTemplate存在的目的．


假如资源的使用不是线程安全的，那么就不能把这样的资源注入到多线程的环境．spring在运行时绑定线程－资源，而不是注入．

上周Floyd Marinescu离开TSS消息令人震惊而惋惜，但是也仅此而已。虽然Floyd Marinescu长发飘飘时潇洒和敬业的态度给我留下了很深的印象，但他在技术上的见地还达不到令我崇拜的地步。但是今天Adrian Colyer的离开IBM，加盟interface21却真的让人震惊，但更多的是兴奋。对于Adrian Colyer总是那么的令我敬仰，而他的加盟interface21则意味着Spring与AspectJ这两种我最狂热的技术将要结合在一起，意味Spring的AOP功能将得到极限提升！



在几个月前，我对Adrian Colyer的印象只停留在纸面上，我知道他是IBM领导AspectJ和AJDT的牛人，我知道他的blog上有好多关于AOP的文章，尤其是那篇AOP without buzzword确实很有意思。但是真正下给我留下最深印象的是他在JavaPolis上的那次讲座，没有人能够象他那么能把AOP解释得那么好，没有人能象他那样用那么多的实例将AspectJ和AJDT讲解得如此让人神往。就象他承诺的那么，整个两个半小时多的讲座的感觉比看一部指环王还爽！留下这个讲座的链接吧： http://www.javalobby.org/av/javapolis/10/colyer-aspectj


如今他来到了interface21，成为了chief science，如今他将和我的另一位偶像Rod Johnson共事。Spring与AspectJ将更加紧密地结合，这是多么神往的事啊。当然Adrian Colyer还会继续担任AspectJ和AJDT的领导人，这也意味着AspectJ也会继续发展。


留下Adrian Colyer的blog地址：

http://aspectprogrammer.org/blogs/adrian/

再欣赏一下Adrian Colyer的风采吧：


welcome to my blog: http://blog.itpub.net/xiecc

在这个讨论里Juergen Hoeller说明了HibernateTemplate存在的目的．

Spring目前基本上是通过XXXTemplate的方式来提供方便的资源管理，事务处理和异常转换的。不过XXXTemplate只是Spring提供的一种方便的设施，即便不用XXXTemplate，在Spring框架下，仍然可以实现同样的资源管理，事务处理和异常层次转换的功能，但是需要自己写一些相关处理代码，配置文件也要稍微复杂一点。

因此Spring要实现同样的功能，并非一定要用XXXTemplate，只不过用XXXTemplate更加方便。

Spring容器和EJB3容器从功能上来说存在直接的竞争关系，这恐怕也是Hibernate攻击Spring的一个直接原因。然而从一个使用者的角度来说，Spring容器仍然有其价值。

使用Spring容器要依赖Spring的API，使用EJB3，同样要依赖EJB3的API和annotation。所不同的是Spring是产品，EJB3是标准。
使用spring容器开发的企业应用一般只需要Servlet容器，Tomcat/Jetty就可以跑，使用EJB3开发的应用必须使用WebLogic/Websphere/JBoss才能跑。即使EJB3厂商愿意提供嵌入式EJB3容器，但是每个厂商的容器配置也是不同的。

因此对于开发者来说，是愿意选择一个单一产品，依赖于单一产品，但是处处适用呢？还是愿意选择依赖标准，但是必须学习不同容器的不同配置方法呢？

EJB3基本上是面向商业市场的，Spring更多的是开源的市场，技术实现上有竞争，细分市场上未必有直接的竞争关系，当然EJB3是未来主流是无可争议的。

其实站在应用程序开发人员的角度来说，我对于框架是否开源，是否可嵌入式是非常在意的。

框架可嵌入意味着可以摆脱应用服务器进行单元测试；
框架开源意味着我可以在Eclipse调试的时候直接跟踪到容器执行堆栈，没有解决不了的问题，也意味着我发现框架代码有缺陷的时候，我可以随时修改源代码，以解决燃眉之急。

确实。但不用XXXtemplate的模式就不能使用托管的transaction或者需要用spring的一个transactionproxy。我提出这个问题到不是从市场的角度出发，主要是目前的技术发展特别是bytecode级别的操作已经很成熟，完全可以发展不具备侵入性的托管容器。



嵌入式容器肯定是潮流。ejb3的容器应该和spring一样，可以在j2se中运行，可以单元测试，甚至可以支持hibernate等其他的orm。这也是我们希望看到的，j2ee架构完全是模块化的，可以根据需要来搭建j2ee环境。


这个可能要取决有代码的复杂度。框架类型的代码修改如果没有经过严格的regresstion test不好改完就用吧。当然开源对用户来说更安全。其实商业代码也可以给用户代码，只要双方遵守规则。