|
目前开源的开发框架很多，大家完全没有必要把目光全部集中于 Struts。Struts 中的 MVC 设计也不是最好的。 以前学习 Ofbiz 的时候看到过老戴（Ofbiz 的总设计师 David E. Jones，我们都这样叫他）发的一篇帖子说明 Ofbiz 为什么不能直接使用 Struts。今天找了找，应该就是这篇了： http://www./archives/3/12465/2002/3/100/8002721/ 如 果想要学习框架的设计，Ofbiz 是一个非常好的起点，它是真正面向企业应用（面向业务的，而不是纯技术的框架，纯技术的框架是没有多大价值的）而设计的，而 Struts、Turbine 等框架对于简单的 Web 应用还可以，但是对于复杂的企业应用就显得太单薄了。企业应用的问题并不是靠简单地分出 MVC 就可以解决的。 Ofbiz 中文网站： http://www. 老 戴基本上没有对 Struts 发表太多的见解。我来解释一下他的这段话，主要原因是 Struts 的设计与 Ofbiz 的设计有较大差别，因此很难无缝地集成进来。而老戴以为以自己的能力，写一个 MVC 框架是件很容易的事。所以在 Ofbiz 中，MVC 框架、OR Mapping 全部是自己设计的。老戴的一个基本思想是通过 XML 对系统进行建模，以 XML 来定义系统中不同的层次关系，尽量减少写 Java 代码的数量（甚至创造了一套以 XML 为基础的 Mini Language 来做一些简单的逻辑处理）。而在 Struts 中仍然需要写大量的 Java 代码。Struts 在减轻开发人员工作量方面做了一些努力，但是做得还不够（甚至带来了额外的复杂性，我认为 Ofbiz 的表示层比 Struts 更容易理解）。如果说面向对象开放框架的目标就是实现更大程度的代码重用的话，无疑 Ofbiz 在这方面要比 Struts 更成功。 根据我的使用经验，Ofbiz 中的 Event Handler、Service、和 Entity Engine 的设计是非常灵活的。确实极大地减少了 Java 代码开发量，换之以更多的 XML 配置文件，但是这个工作量要比做 Java 开发小得多。 某种程度上，Ofbiz 和我们现在设计的这个框架有很大的相似之处，我们都是面向业务问题的框架而非学术性的纯技术框架。 这里是不是牵涉到一个如何对待技术框架和业务框架的问题？ 按我的理解，框架技术实际上就是流程固化技术。在框架技术中应用的很多的一种就是回叫机制（callback），对比MFC之类的东西，框架其实就是由设计好的工作流程调用具体的数据结构和算法（在C/C++中使用函数指针，Java中使用接口）。 J2EE 我更多的是做为一个框架来理解，而不仅仅是一组API。J2EE面对的问题域主要集中在分布式计算，那么它就固定了一套处理分布式计算的流程。我把它看作 一个技术框架，它处理的流程是面向机器的：如何定位资源；如何管理连接；如何传递消息；如何处理事务；如何处理安全等等，这是所有业务的基础。所有的商用 逻辑最终都是要转换成这些计算逻辑。 从这个角度看，实际上J2EE的抽象级别还是相当低级的。程序员的作用就是把商业逻辑转换分解为计算逻辑。随着程序的变大，人们自然的想在技术框架上再做一次抽象，把商业逻辑向技术逻辑转换的流程固定下来，这样就可以大大减轻开发的负担。 这样就要求设计者对商业逻辑和技术框架都相当了解，才能完成这个抽象。--谁说软件开发变简单了？ 在这个趋势下，程序员的两极分化必定越来越大，一方面向框架的设计者集中，一方面向框架的使用者集中。各种各样的框架也会越来越多。 优秀的开发者会根据合适技术建立适合自己业务的框架，而不是盲目地追逐现有的热门的框架。 stuts主要是面向Web开发的，而真正的企业应用的UI层是很薄的（dlee，这是你说的哦：） ），或许，是这个原因ofbiz没用stuts。 无 明兄，我很同意你的观点。你对框架作用的描述比我要清楚的多。J2EE 确实只是对低层次的逻辑进行了抽象和建模，做的还远远不够。这也是我对 EJB 由热衷到冷静到失望的原因。我接触过很多朋友对 EJB 还有 MVC 都不是非常的热衷。但是对于初学者，往往最喜欢谈论的就是 CMP 和 MVC。我写了很多反对的意见，并不是说它们没有价值，而是它们完全没有达到 Marketing Hype 所描绘的理想境界。在我看来，企业花费巨资购买一个仅仅实现了 J2EE 规范的 WebLogic 是完全没有价值的，因为没有解决任何的业务问题。当然有人会反驳说一分钱一分货，我只是觉得 Java 技术发展到了今天，完全有性价比更高的选择。J2EE 把对业务进行建模的任务完全甩给开发者，这是一个很大的问题。因为开发者完全不清楚需要把哪些业务对象表示为 Servlet，哪些表示为 Session Bean，哪些表示为 Entity Bean，即使发明了那么多的 Patterns，如何对业务建模仍然有很大的难度。业务建模的复杂程度要远远超过对连接池这样的简单对象的建模。随着软件技术的成熟，软件开发者关注的 领域越来越向问题域转移，这也是为什么最近 AOP 兴起的原因。AOP 是直接关注问题域的新型开发方法（当然 AOP 是不能够脱离开 OOP 的，它是 OOP 的最新发展）。 在我们看来，今后几年国内的企业对于面向业务的开发框架的需求将呈现一个快速的发展阶段。我们希望 自己在这个市场占有一席之地。我们希望自己将来成为框架的设计者而不是一个纯粹的使用者。这样的业务框架设计的难度比设计一个纯技术的框架要高的多，因为 你必须有多年大型项目成功实施的经验，对某一行业的业务非常熟悉之后才能够设计好。设计一个框架不难，设计一个真正有用的框架就很难了。IBM 也没有什么象样的框架，所以只能拿开源的东西直接来用（WebSphere 中有多少东西都是来自于开源软件）。IBM 是在帮助开源社区，但是他拿走的也不少。 我觉得你对 ejb 的理解有些偏差，ejb 的核心是什么？我想应该是tp monitor，而不是什么 cmp & bmp 。 只 有了解什么是 tp monitor ，才能确切知道 EJB 的价值。自从60年代tp monitor 软件（cics）出现后，在商业领域一直没有能够出现 cics 的竞争者。而tp monitor 软件的市值之大另各软件公司所垂涎（500强企业中95%以上使用cics）。而传统的 TP monitor 软件是面向过程的，所以在面向对象的语言出现后，如何实现面向对象语言的事务控制一直为工业界所关注，EJB 的出现可以说另业界兴奋不已，这就意味着企业的核心软件终于可以用先进的面向对象的语言来编写了。但是很遗憾，ejb 还是不太成熟，所以直到现在，（大）企业的核心软件仍然由cics所盘踞（部分原因是大机的缘故） 为什么tp monitor这么受重视呢？ 非 常简单: 是因为企业的软件过于复杂，交易量太大而且事务交易过程决不允许出错！真正能够达到工业强度的 tp monitor 软件，你的选择基本上很少，而能够用在大型机上的 tp monitor ，基本上你没有选择，而价格更是让你咋舌！而业界对这个东东也是恨之入骨(有如微软)。 你 说的有些道理。但是大量的应用不一定要用到 EJB 的跨数据库两阶段提交，它们可能只需要用到 JTA 所提供的功能就可以了。在涉及到跨数据库两阶段提交的场合（比如银行的转帐业务），我确实还不清楚有比 EJB 更好的选择。CORBA 比 EJB、WebService 都要成熟，然而它缺少的正是一个 TP Monitor，而 EJB 以规范的形式实现了这样的一个 TP Monitor，确实减轻了很多的开发工作量。而且我相信业界主流的 Java 应用服务器在高可用性方面完全可以满足重负荷业务的需求。在分布式应用，尤其是涉及到大范围的事务处理的场合，我相信 EJB 是目前最好的选择。然而对于一般的信息管理系统，EJB 确实有些过于重量级了。 EJB 属于框架的范畴，任何一种框架都有其适用和不适用的场合，抛开具体的应用领域来谈其优劣都是不适当的。我还看到过有人认为“工作流必须要用 EJB 来实现，否则是无法想象的”这种说法。“有了一个锤子，看到什么都是钉子”这是我看到这种说法后直接想到的第一句话。 我想我们说的都有一些道理，但是应该加一些限定，否则就变成无边际争论了。在我们的开发领域，确实看不到很多必须要使用 EJB 的理由。我也并不认为做分布式应用就一定比设计 MIS 系统要高级，大家各有各的难处。 这 类银行的核心应用正是我说的少量应用。你不能让所有的人都跑去做银行应用吧？就银行这样的关键应用而言，不用 EJB 确实很难达到高可用性的要求。我们做工作重要的是要站在巨人的肩上，EJB 是一个巨人，但是它也不是不发展了。光是说“EJB 就是好来就是好”（有点象脑白金的广告）而看不到它的局限性是要犯错误的（别介意，我没有特指）。EJB 确实做了很好的工作，但是如何更方便地对数据做复杂的加工处理却是 EJB 没有解决好的问题（这正是我说的 J2EE 甩给开发者来解决的问题），要由 Hibernate 等面向数据建模的框架来解决。实际上 Hibernate 解决的也是局部的问题，研究 Hibernate 应该放到企业数据流的大背景下思考才能把 Hibernate 的优势充分发挥出来。开发者现在需要的不仅仅是 EJB 这样解决了关键技术问题（比如 TP Monitor）的框架，他们还希望得到一个能够帮助他们解决业务问题的业务框架。不知道你有没有真正理解我说的话，解决技术问题是不值钱的（尤其是在 JBoss、JOnAS 等 Open Source 的应用服务器出现后。Java 应用服务器市场已经是一个过度竞争的饱和市场），解决业务问题才是值钱的。位于产业链的高端的企业才是最舒服的，这也是我们将来的发展方向，我们会在将来 适当的场合采用 EJB，关键是看是否有这方面的业务需求（分布式的应用，对事务处理的高可用性要求很高）。 JDBC 过于低层了，如果永远只在如此低的层次上工作，那么复杂的大型项目的完工就遥遥无期了。好在 OOP 给我们提供了无限的封装能力。JDBC 之上有 Hibernate、JDO，还有 Ofbiz 中 Entity Engine 实现的 OR Mapping 框架。这些开发框架极大地减少了开发的工作量。这些框架的目标就是要在大部分场合完全替代 JDBC。然而我觉得有些遗憾的地方是 Hibernate、JDO 的抽象层次仍然没有上升到业务对象的高度（所以它们不能够作为单独的解决方案，而只能作为更大的业务框架中的嵌入式组件）。业务分析和软件设计在国外是分 的比较开的两个领域，分析领域有很多模式（分析模式），最后得到是分析对象，这些分析对象是直接与业务相关的，也是商务人员比较容易理解的。设计领域也有 很多模式（设计模式），最后得到是设计对象（差不多就是计算机中真正的对象）。但是目前从分析对象到设计对象的映射还有较大的空隙（gap）需要填补，填 补了这个空隙，软件从需求收集、业务分析到设计、开发、部署、测试的全生命周期就能够以一种无缝的方式结合起来。Borland 整合了 Together 和 JBuilder 后可能会有一个比较好的方法。我还没有试用过 Together for JBuilder，你可以看看其介绍。 解决业务问题的业务框架有很多，IBM 兜售的解决方案中就有面向业务的框架，比如以前的 E-Commerce Suite（现在好象叫 WebSphere Commerce Suite 了）。开源的业务框架我只用过 Ofbiz，感觉比较好，你可以找些资料看看。 我 并没有贬低技术框架的意思。我这样说是由小企业的发展策略所决定的。小企业做通用软件生存下来的可能性很小，只能先依托一两个行业，深入研究该行业的业 务，通过成功实施项目壮大自己。如果同时做多个行业，很难都做好，极有可能任何一个都做不深，那样是没有任何竞争力的。 对于企业来说，通用的 解决方案往往不能很好地解决他们的业务问题，因此他们需要为企业（或者是这个行业，如果企业的业务有代表性的话）量身定制的解决方案。软件业本身就是一个 服务行业，软件业的利润将会越来越多的向服务转移（而不是靠卖发行包）。企业对为自己量身定制的解决方案（高级服务）的需求也会越来越大。我听说过有些做 通用解决方案的公司（甚至是有些大公司），不管对于哪个行业，推销的都是一样的方案。他们的售前见了客户除了吹嘘自己的技术实力和成功经验外，对于客户的 业务谈的很少，显然是没有做过认真细致的分析（完全是一派以我为主，强行推销的派头）。客户需要这样的解决方案吗？可能你前脚走人他后脚就把你忘掉了（想 赚我的钱，你还嫩点）。在这个领域如果我们把工作真正做好了，以小搏大是完全有可能的。 我来举个例子。低级妓女为很多人服务，她的收入很少。高级妓女被某个亿万富翁包下了，为这个亿万富翁提供全方位的周到服务，她的收入肯定比低级妓女要高（大家可能都看过“风月俏佳人”这部电影）。这个比喻虽然不雅，但是确实说明了对高级服务的需求是很大的。 IT 业的产业链最近几年变化很大，但是最稳定的就是那些高端的厂商，因为他们提供的服务是很难被替代的。市场对技术框架的需求将趋于饱和（这也是为什么那么多 很好的技术框架不得不开源的原因，要么是根本赚不到钱，要么是根本没有想过用这个框架来赚钱，这个框架只是更大的业务框架的一部分），而市场对业务框架的 需求将越来越大，这个机遇是我们无论如何也要把握的。解决业务问题的能力是最难复制的，也是我们应该孜孜不倦追求的目标。你可以看几本讲 J2EE 的书来学习基本的技术，但是如何对业务进行建模，什么样的架构才是真正实用的架构你仍然是一个门外汉。 进入 IT 业就走上了一条充满风险的不归路，成为业务专家不是你本人是否喜欢的问题，而你要生存下来就必须要走的路。所以我总是对别人说一定要靠两条腿走路，技术和业务，缺一不可，而且都要做好。 ofbiz 只能算是 opensource 界的高級專案 集合了許多 opensource 產出了一個完整的架構 如果和 bea weblogic platform 比起來還是不行 所以拿著 ofbiz 來否定 struts 是不公平的 因為 bea portal framework 就是基於 struts 開發上去的 我反而不會看好 Ofbiz 的未來 即使他的未來有更多的整合方案 更多的元件增加進來 只是讓他更加肥大 肥大到讓初學者畏怯 因為到現在, 我尚未有看到更方便的 ide 工具有支援他 反而來看 struts 的支援度, 如果單純的直接開發 或許會蠻麻煩的, 一大堆麻煩的設定 但是這些設定的存在都是有他的道理的 因為那不是給人讀的 ( 雖然我都直接寫 ) 卻是給予 ide 方便的存取修改新增的方式 可以讓初學者輕易地開發著程式 Turbine 或其他 framework 如 WebWork ... 和 Struts 的優劣勝敗我不予評論, 基本上, 市場機能將決定一個 opensource 的興衰 即使我認為 turbine 的優點較多 支援更強 但是對於一個初學者來看... 我反而推薦 struts 當作基礎的入門 因為我喜歡單純的 framework 作為 mvc framework 我可以自由地增加我所需要的東西 OR Mapping 我可以選擇 Hibernate , OJB , EJB 甚至 ibitis 等等 Security 我可以選擇 securityFilter, pow2acl 等等 ........... 即使 ofbiz 幫我做了很多 我卻不認為我可以直接讓客戶使用 只會造成我要閱讀他們的原始碼作修改...... 採用 struts 有另外一個好處是 當大家都使用的時候, 你可以找到更多適合的資源附加在你的系統 如果採用過 bea workshop 8.1 開發過 web 就知道再複雜的程式也可以靠著拖拉與設定完成 此外 j2ee 的 support 都是過之而無不及的 一個企業除了安全性穩定性之外 要的就是能夠在最短的時間產出最好的產品提供給客戶 拿著 ofbiz 和 weblogic 比 似乎太對不起 ofbiz 了 根本就是讓大象去踩死一隻小螞蟻 :P 不過我不否認 ofbiz 的價值, 用在一般小企業倒是不錯的一種解決方案.. 還有他提供的是一種思路給予大家 如何套用各種 opensource 讓一個企業具有更完整的解決方案 jini， 你说的是有一些道理的。你要做的这些事（组合各种开源的 Framework）正是 Ofbiz 已经做过的事（我们现在也在做这件事，为建造一个企业级的业务框架而奋斗。但是我们更多地是立足于自主开发，而不是直接采用开源的方案。因为我们要涉足的 领域目前还没有很好的开源项目）。很多人可能觉得 Ofbiz 中某一方面的设计不是最好的（比如 MVC、ORM）。但是它们的设计都是为整体的目标服务的。不一定各方面的超强工具（Struts、Hibernate、Castor、 Tyrex......）简单组合在一起就是一个稳定的企业级业务框架。 以前我在 linuxtea 发的帖子中说： Larry Ellison 在中央台的对话中说，你可以买下零件自己组装汽车，但是 Oracle 是组装整车的公司，某一部分不一定是最好的，但是它们组合在一起是最有效率的，每一部分都可以很好地发挥作用。 现在的 Open Source 世界所提供的就是这样的一些汽车零件。把这些零件拼装起来就可以生产整车了，但是你不能简单地拼凑起来，那样是跑不过别人的车的，从 DIY 到提供真正的商业价值的道路还是很远的。 对于目前国内的很多企业来讲，他们急需尽快地从解决基本的技术问题跨越到解决复杂的业务问题（先要赚到足够的钱活下来），Ofbiz 对于他们加快项目的开发进度有非常大的帮助。 我 本人也并不是很喜欢别人一股脑地向我推销什么 All-In-One 的解决方案，更喜欢解决某一方面问题的小而精的方案。我们并没有采用 Ofbiz，但是可以借鉴 Ofbiz 中好的设计思想（适当的借鉴是绝对必要的，否则就是闭门造车了）。既然已经有了 Ofbiz 这个东西，它就树立了一个标杆，这是你无法忽略的。就象前几天我和几个同学激烈争论的数据库选取问题，Oracle 已经树立了一个标杆，这个标杆无论你如何厌恶，都是无法绕过的。MySQL 的爱好者可以闭上眼睛当作这个世界上根本就没有 Oracle，但是我可并不想这样做。 我们这里讨论还是要采取兼收并蓄的原则，欢迎大家对于各种 Java 开发框架（开源的或者不开源的）展开客观深入的讨论。这些讨论对于来这里的每个人都会是有益的。
呵 呵，怎么能说难听呢？这才是技术人员最终要考虑的问题。你总想有一天实现自己的价值吧？解决了客户的业务问题，首先给客户创造了商业价值，然后才有可能实 现你自己的价值。软件业将越来越向服务业的方向发展，将来的竞争将是高层次的残酷竞争。最终的受益者将是客户（企业和最终用户），并且会带动整个社会向信 息化的转型，改善全社会的资源配置，提升全社会的生产效率。 业务问题往往是复杂的，从要解决的业务问题入手展开思考，才有可能把技术用好用深入。 我 来举个例子：假设我们要做一套报表服务器。客户有很多下属单位，下属单位的报表都要汇总到总部，在总部以各种方式进行汇总。如何解决这个分布式系统中数据 的一致性？首先要保证可靠的传输，如果各下属单位以拨号方式与总部相连，而不是永久连接，如何保证传输可靠性？这些报表数据如何定义，如何汇总？生成的这 些报表需要进行审核，要用工作流方式来实现。要对报表进行完善的管理，如：设置报表的各种参数，设置报表是自动生成还是手动生成，对报表进行检索、修改、 删除，还要对报表的访问权限加以控制。合在一起就是一个很复杂的问题。目前任何的技术框架都没有给你提供现成的解决方案（因为这完全是一个业务问题）。 由业务问题入手，可以应用到的技术范围是无限宽广的。具体采用什么框架，是一个 tradeoff 的艺术。 其实这个讨论是相 当泛泛的。为什么 Ofbiz 中的 MVC 比 Struts 灵活，它们究竟是怎样设计的等等问题都没有讲清楚。这些问题需要留待以后深入讨论。大家先有一个学习的方向，然后在具体工作中再去体会。框架具有一定的复 杂性，而一个人的时间是有限的，抓紧时间，了解更多的框架，最终找到最适合自己的才是重要的。我不太赞成所有项目都用相同的框架来开发，因为不同的框架对 于项目的进度和质量有很大影响（再次强调选择正确工具的重要性，比如我用 Eclipse 做 Java 开发的效率是采用 Vi+Javac 的十倍）。即使从成本上考虑，也不应该所有项目采用相同的框架。我是很相信我们的程序员的学习能力的，他们在 3、4 个月的项目开发期间学会使用一种新的框架是绰绰有余的（掌握了一种框架再掌握其它框架就会比较容易，而且还会加深他们对原先框架的理解）。当然首先我要确 定这种框架确实是最适合的（我认为最适合，还是带有一定的主观性）。一种框架就是一种解决问题的思路，从公司的角度，开发人员掌握多种框架也符合公司的利 益（应该鼓励开发人员学习和实现自己的想法，而不是把他们当作编程机器严加看管）。 根据我对 IT 行业多年来的观察，成功者往往都是那些真正专注于解决问题的人，我更多的指的是业务问题。 最后再说一句，对各种框架进行深入讨论是有必要的，不要搞神秘主义。任何问题只要找到其症结，都是可以讨论清楚的. 关于框架，我还想说的是现在有很多开源的框架，都只解决了企业级应用中的一部分问题。这些不同的框架设计理念不同，彼此存在着一些内在差异，把这些框架简单组合在一起是否就能大幅度提高开发效率我是很怀疑的。一个成熟的框架必须要保证整体的概念完整性，而概念完整性才是软件质量和开发效率的关键。 老戴为什么没有采用 Struts 而要自己设计，就是因为 Struts 的设计理念与 Ofbiz 有很大的差距。而 Ofbiz 中的各个部分确实保持了整体的概念完整性，这与其只有几个主要的核心设计人员是分不开的。 不同的开源框架随着使用人数的增加，在更高的版本中会加入更多的功能，随着功能的膨胀，最后甚至想无所不包，企图解决一切的问题，这样它们彼此之间将产生很多功能上的重叠，把它们简单组合在一起更容易出问题。 框 架的重用是高粒度的重用，只要能充分保证概念完整性，无所谓这个框架是采用对象建模、数据建模还是混合方式设计出来的。无论对象建模还是数据建模都是着眼 于技术层面的重用，业务解决方案的重用对我们才是最有意义的重用。potian 的话并没有说服我框架一定要完全采用对象建模的方式来建造（因为我知道很多问题完全采用 OO 是无法解决的），只是让我理解了对象建模的优点。 我的一位朋友前几天说的话我觉得很有道理。
现在为什么会有 JSF？是不是因为 Struts 已经不适用了？ |
|
|
