我的团队正在开发一个带有Web前端的面向服务的新产品.在讨论我们将使用哪些技术时,我们决定运行JBoss应用程序服务器和Flex前端(可能使用Adobe AIR进行桌面部署),以及用于连接客户端和服务器的Web服务.
当涉及到我们的业务逻辑使用哪种服务器技术时,我们陷入了僵局.EJB3和Spring之间的争论很大,我们最关心的是可扩展性和性能,以及代码库的可维护性.
这是我的问题:
对于EJB3和Spring有什么争论？
我可以期待哪些陷阱？
我在哪里可以找到好的基准信息？
John Stauffe.. 73
基于Performance,EJB3和Spring之间没有太大区别.我们选择Spring的原因如下(问题中未提及):
Spring将架构推向更容易支持单元测试的方向.例如,注入一个模拟DAO对象来对您的业务层进行单元测试,或者利用Spring的MockHttpRequest对象对servlet进行单元测试.我们为单元测试维护一个单独的Spring配置,允许我们将测试与特定层隔离.
最重要的驱动因素是兼容性.如果你需要支持多个App Server(或者最终希望选择从JBoss转移到Glassfish等),你将基本上随身携带你的容器(Spring),而不是依赖于不同实现之间的兼容性. EJB3规范.
Spring允许为Persistence,对象远程处理等提供技术选择.例如,我们也使用Flex前端,并使用Hessian协议在Flex和Spring之间进行通信.
我只是更依赖Java EE实现之间的兼容性而不是从服务器到服务器携带一些专有容器. (4认同)
PEELY.. 37
显然,EJB3和Spring之间的差距远小于它.也就是说,现在EJB3的一个缺点是你只能注入一个bean,所以你最终可以将组件转换成不需要的bean.
关于单元测试的争论现在相当无关紧要 - EJB3显然是为了更容易进行单元测试.
上面的兼容性参数也是无关紧要的:无论您使用EJB3还是Spring,您仍然依赖于第三方提供的事务管理器,JMS等实现.
然而,为我提供的是社区的支持.去年在EJB3项目上工作,并没有很多人在那里使用它并谈论他们的问题.Spring,无论是正确还是错误,在企业中都非常普遍,特别重要,这使得找到遇到同样问题的人更容易解决.
基于Performance,EJB3和Spring之间没有太大区别.我们选择Spring的原因如下(问题中未提及):
Spring将架构推向更容易支持单元测试的方向.例如,注入一个模拟DAO对象来对您的业务层进行单元测试,或者利用Spring的MockHttpRequest对象对servlet进行单元测试.我们为单元测试维护一个单独的Spring配置,允许我们将测试与特定层隔离.
最重要的驱动因素是兼容性.如果你需要支持多个App Server(或者最终希望选择从JBoss转移到Glassfish等),你将基本上随身携带你的容器(Spring),而不是依赖于不同实现之间的兼容性. EJB3规范.
Spring允许为Persistence,对象远程处理等提供技术选择.例如,我们也使用Flex前端,并使用Hessian协议在Flex和Spring之间进行通信.
显然,EJB3和Spring之间的差距远小于它.也就是说,现在EJB3的一个缺点是你只能注入一个bean,所以你最终可以将组件转换成不需要的bean.
关于单元测试的争论现在相当无关紧要 - EJB3显然是为了更容易进行单元测试.
上面的兼容性参数也是无关紧要的:无论您使用EJB3还是Spring,您仍然依赖于第三方提供的事务管理器,JMS等实现.
然而,为我提供的是社区的支持.去年在EJB3项目上工作,并没有很多人在那里使用它并谈论他们的问题.Spring,无论是正确还是错误,在企业中都非常普遍,特别重要,这使得找到遇到同样问题的人更容易解决.
对于EJB3和Spring有什么争论？ Spring始终在创新并认识到现实世界的限制.Spring为Java 1.4应用程序服务器提供了简单和优雅,并且不需要在2004 - 2006年没有人可访问的J2EE规范版本.此时这几乎是一个宗教辩论,你可以被吸引到 - Spring +抽象+开源与Java企业版(Java EE)5.0规范.
我认为Spring 补充的不仅仅是 与Java EE规范的竞争.由于Spring曾经独有的功能继续被纳入规范,许多人会争辩说EJB 3为大多数内部业务应用程序提供了"足够好"的功能集.
我可以期待哪些陷阱？ 如果你把它视为持久性问题(Spring + JPA)而不是EJB3,你真的没有做出那么大的选择.
我在哪里可以找到好的基准信息？ 我有一段时间没有遵循specj基准测试结果,但它们很受欢迎.似乎每个供应商(IBM,JBOSS,Oracle和Sun)对拥有兼容服务器的兴趣越来越小.从1.3,1.4开始,这些列表的认证供应商越来越短.1.5 Java企业版.我认为完全符合所有规范的巨型服务器的时代已经结束.
我肯定会推荐EJB3超过春天.我们发现它更加简化,编码更好,更好地支持.我过去使用Spring并发现它非常令人困惑,并没有像EJB3那样详细记录(或者我认为在一天结束时的JPA)
从EJB3开始,您不再需要处理外部配置文件,并且每个数据库表只有一个POJO注释.此POJO可以毫无问题地传递到您的Web层.像Netbeans这样的IDE甚至可以为您自动生成这些POJO.我们现在使用EJB3作为很多大型应用程序的后端,并没有发现任何性能问题.您可以将会话Bean轻松地公开为可以向Flex前端公开的Web服务.会话bean很容易在方法或类级别锁定,以便在需要时分配角色和类似的东西.
我不能说春天这么多,因为我只试了几个星期.但我对它的整体印象非常糟糕.这并不意味着它是糟糕的框架,但我们的团队发现EJB3是持久性/业务层的最佳选择.
我倾向于选择Spring而不是EJB3,但我的建议是采用哪种方法,尽可能坚持编写POJO并尽可能使用标准注释,例如@PostConstruct,@ PreDestroy和@Resource等JSR注释,它们都适用于EJB3或Spring,以便您可以选择您喜欢的任何框架.
例如,您可以决定使用Guice代替IoC.
如果你想在Web应用程序中使用预请求注入,你可能会发现Guice比依赖Spring注入要快得多.
会话bean主要归结为依赖注入和事务; 所以EJB3和Spring真的有点类似.Spring的优势在于更好的依赖注入和更好的抽象,例如JMS
京公网安备 11010802040832号 | 京ICP备19059560号-6 