锁定老帖子 主题:论Spring与EJB的组件架构
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2004-09-21
我怎么看怎么觉得这篇文章说的是有规范支持的Framework与无规范支持的Framework之间的区别.......
不可否认,EJB的容器做了很多事,但这些是不是Spring做不了的?你不能说你已经有了成熟的产品,就不让人家有更好的想法 其实基于EJB的复用和基于Spring的复用,实际上是一回事,复用本身不取决与容器,而取决于设计,业务逻辑到哪里,用什么实现都是没有问题,都是可以复用的,当然前提是,大家都还在同一规范的容器里,Spring也一样,必需在AOP的容器里,否则,额外的代码是必然的 事实上,如果所有Vendor都按照Spring的规范(如果有的话)建立一个容器的话,EJB又该何去何从? |
|
返回顶楼 | |
发表时间:2004-09-23
我主要用C++和 CORBA,对EJB 和spring 都没有实战经验。所以我没什么可说的。 但是还是忍不住说:
这个帖子很精彩。 raimundox 观点我认为很客观, 赞成他的绝大部分观点。 |
|
返回顶楼 | |
发表时间:2005-03-06
raimundox 写道 robbin 写道 agilecat 写道 我的看法:
1. ejb3 是模仿spring建立的体系结构,ejb3跟spring的关系就像jdo跟hibernate的关系,老的ejb体系已经垂死,ejb3使轻量级容器有了更多选择. 2. 到了ejb3时代,有可能spring修改符合ejb3,也有可能部分中间件厂商拿spring作内核来实现ejb3. 就像hibernate和entity bean的关系一样. 3. ejb3仍然会是j2ee的核心模块,但由于spring的开放性,用户不再会对ejb3的需求付费,用户付费的核心是分布式事务. 4. 纯中间件服务器的利润会暴跌,因为许多应用不需要分布式事务,主流中间件厂商会把业务核心转向portal,eai,数据仓库等方向. 我同意这样的观点。我本来想写一个帖子阐述这样的观点的。 其实在中国,把关注力转向商业逻辑元件和商业逻辑框架,显得意义更加重大。因为中国在全球IT产业链处于底层,在技术层面上无法改变追随者的地位。就算有人能够做出来优秀的开源技术框架,但是如果英文水平不足够好的话,还是没有办法普及到全球。但是商业逻辑框架就不同,中国的软件公司和外国的软件公司站在同一起跑线,本土的公司甚至还有很多优势。我的主张就是采用流行的可靠的开源技术框架,例如Hibernate/Spring/Webwork2之类的就可以了,没有必要非在技术上较真,而把资源投入到钻研行业业务上,要做到比客户还精通业务,把业务抽象出来好的商业逻辑框架。这才是软件公司的核心竞争力。 对,同时我认为做行业元模型也不错,就像iec61970,国内也开始推了,电力eai也开始用了,因此就算mda不成功,mof也会成功。 起码数据库未来会大面积支持cwm,ETL工具已经有很多支持cwm,webSphere也有自己的j2ee mof model。钻到行业我想元模型比框架的价值大,但是也更难,竞争也更激烈. 这个帖子水平很高。 我想要说的是,真正的复用,并不是容器的复用,而应该是业务逻辑的复用,即所谓的Domain Logic。因为容器说到底还是技术的层面,会一直的变化,而业务逻辑在一个领域内是相对的稳定的。 因此我觉得花太多的力气在容器的复用上是没有必要的。不如花更大的力气在业务逻辑的复用上。 但是很多公司的业务逻辑绑定在某一种技术上,这很危险。业务逻辑不应该和具体的某种技术相关,比如struts, spring等什么的。应该只是纯粹的Domain Object。这也是提出POJO的原因。Eric Evens的Domain Driven Design这方面讲得很透彻。 如果业务逻辑部和具体的技术相关,那么移植就不再是问题了。 |
|
返回顶楼 | |