构建的可伸缩性和达到的性能：一个虚拟座谈会
这个由业界主要专家们参加的座谈会探究了在使应用程序具备尽可能好的伸缩性及性能的过程中所面临的挑战和思考过程。
- Architecture, Java, .NET, Ruby,
新闻
视频：曹晓钢谈企业应用开发框架
作者 Jason Lai 发布于 2007年10月23日 下午8时31分
在本次采访中，曹晓钢首先对当前流行的Web应用开发框架，如Spring、JBoss Seam、Hibernate等进行了比较分析，然后根据自己的实际工作经验和经历指出在企业应用开发中如何选择并合理地使用这些框架，另外他还对未来一段时间开源开发框架的发展前景进行了展望。
观看视频：曹晓钢谈企业应用开发框架（20分42秒）因为在软件开发领域有着多年的从业经历，在谈到对目前市场上流行的企业应用开发框架的评价时，曹晓钢从三个方面进行了解释：
第一方面，它对Web端事件模型是如何封装的；第二点，它对组件是如何支持的，特别是对业务组件如何支持的……；第三点就是说业务框架，集成框架如何来处理数据绑定的事情，如何跟后端的ORM能够进行有效的集成。……
对于目前比较受关注的两个框架Spring和JBoss的优劣势，晓钢从它们对标准的遵循和商业推广上进行了比较：
JBoss来说，现在从标准上面或者说从商业推广的进度上来说，都是领先Spring的。……像Spring的话，它更加有点像草根的感觉，就是能够真正的解决开发人员平时遇到的一些很大的问题，但是我的感觉是什么呢？它没有一个很大的支撑。……
采访的最后我们给曹晓钢设置了一个假设的问题，询问他如果有无限的时间和经历，要解决现实项目中出现的问题，应该如何去选择？晓钢顺势向我们“推销”了他的“妥协理论”。
没有太多说服力
发表人
hong lin
发表于
2007年10月23日 下午8时46分
Re: 没有太多说服力
发表人
sw pollux
发表于
2007年10月25日 上午2时49分
Re: 没有太多说服力
发表人
zheng xin
发表于
2007年10月28日 上午2时35分
Re: 没有太多说服力
发表人
霍 泰稳
发表于
2007年10月29日 下午9时6分
没有噱头
发表人
fan fan
发表于
2007年10月29日 下午6时59分
Portlet
发表人
Chushu Gao
发表于
2007年10月29日 下午8时53分
实在听不下去了！来点实在的行不。。。工作offer
发表人
kai zhang
发表于
2007年11月7日 下午6时6分
组件化始终是程序员不懈的追求
发表人
gx li
发表于
2008年5月27日 上午3时39分
-
感觉业务建模是框架该做的还是以需求而设计的，你举的那个"显示客户信息"的例子实在没有什么说服力，我还没有深入seam，不过我想业务建模也应该不可避免的见于需求，你可以向页面传递尽可能多的信息（一个信息丰富的模型，你的“你的那些用户信息”必然在模型中）。
-
同意！另外在和spring和jboss系列做比较的时候，比较简单，没有深入下去。说spring是一个草根框架等等，让我感觉太随意了。其实作者自己的项目中不也还在用spring那套嘛！再说spring的未来还是比较明朗的。
-
我觉得，seam和业务逻辑的开发仍然没有什么关系，只不过是another framework，对于实际的复杂的业务逻辑开发，seam也解决不了什么问题。 我觉得这种说法很肤浅，很没有深度，也没有准备好，不应当出现在infoq的网站.
-
没有噱头
-
首先声明，本人并无大量企业应用开发经验。以下看法更多来自学术观点。 从曹晓钢的访谈中可以看出，他对业务模型如何穿透映射到页面表示尤为关注。在学术领域中，不乏学者通过建立页面表示模型，利用MDD中的技术与成果，一方面进行工作流模型到页面表示模型的转换，一方面进行页面表示模型到具体表示通道的转换或映射。Portlet可以看作一种运行于容器中的页面内容表达途径。因此，一些学者选择Portlet载体进行这类转换与映射。不知道这是否会是软件工程实践者亦会尝试的途径。
-
参与讨论就是一种美德，你的问题对其他朋友是很好的启发。
-
实在听不下去了，特意注册一个账号跟大家讨论一下。我不是Professional programmer也没有用过JSP 0.8什么的，不过这个谈话不是矛盾就是空洞还有太多错误。这个网站做得挺好的啊，怎么。。。sign 首先，好像你主要想要一个component based framework, 你拿Spring来说当然没前途。。。因为他根本不是走这个路线的，你可以拿JSF等相关的东西来说说他们的具体缺陷，和你整合时候遇到的问题而不是找些不相及的东西开刀。J2EE Development without EJB如果没有记错是对Spring核心技术的解释，应该就已经透露这个框架是用来支持你想整合的其他框架其中包括你不断重复的控件之类的，还有就是你正在用的hibernate等等。而且Spring 的IOC 精髓， AOP的支持 让POJO这样的简单object实现了EJB的declarative transaction 等等, 而又不强迫你重写，重建一大堆方法和object. Spring主要在支持你在任何一个层面上更好的设计和控制你要做的事情。你要求的那个server side validation(JSP里面的小红标志表示验证失败), Spring里面有阿还很多种呢 比如 @spring.validator type="required"。。。 而分层是为了更好的处理这个层的任务，在你的那个多个页面需要类似客户信息的例子里，你需要考虑的是怎么样得到一个model在presentation layer下面的那个层然后转给一个view（额外的抽象出来的好东西）去interpret，这个在presentation layer 的 view，是interactive designer or expert的美学领域的工作，他们需要考虑如何把这个页面渲染的像个样子（用传过来的model）。具体技术上的就是sitemesh这种页面布局小模块的用处。 .net 是用钱堆出来的，表现层能差吗？你扔给interface21几十个亿，就要什么控件有什么控件了。这些框架的好处是你可以用一个方法控制你的代码而不是帮你把UML Diagram直接变成JSP的。 小小的意见是：框架的英文名字说得慢一点，或者拼出来一下，也许可以让别人在你启发后发现更多东西，起码有机会google一下。 如果你真想谈，应该谈谈你如何用Spring， hibernate 还有前端的XXX没听清楚来实现你的component based design, 比如你完全可以用JSP TAG实现你的那个每个页面都有的什么什么客户信息。。大家都忙 指东说西也就罢了 总的来点实在的啊。。。 最后最后这个给网站的：也许用一下AJAX 让用户在发言回复的时候不会重新播放stream. 如果哪位同仁感觉我说得更偏激 欢迎讨论adjure_study@hotmail.com ， 另外 我正在找合作的伙伴，主要是B2B的webshop之类的，将会用到Spring等等 暂时还在给老外打工，所以最好会外语的 如果技术很强也成，我做interface了：）有兴趣的联系 谢谢
-
晓刚这些发言的核心还是在于“组件化”。 其实这个问题很多年来正是众多程序员不懈的追求。见子打子的程序大家都会写，真正追求是业务逻辑的重用。于是从过去的COM、CORBA、EJB，到如今的WS、REST、SOA等等。 可惜，业务逻辑组件化这样的想法几乎快演变为玄学了。 经过多年观察和实践，老实说本人对这个追求开始产生了悲观情绪。或许这种追求本身便是程序员的西西弗斯悲剧？ 而且可笑的是，B/S经过好多年的折腾之后，仍然没有达到当初VB、Delphi、PB那样高生产力的程度。虽然说B/S仍是必经之路，但要有多久，要如何做才能达到如C/S时代的易用度和高产？届时什么样的技术和框架经得起时间的考验？Spring、Seam、Grails、PHP、RoR、ASP.NET？
8 条回复
回复