为什么 Ofbiz 没有使用 Struts

象API, component, framework, pattern谈来谈去都是希望reuse,
reuse的目的是功能全面, 稳定可靠,  还得容易上手. 容易修改.
这些本来就是矛盾的, 所以一切的问题就是tradeoff.
Struts为什么流行, 我认为他的tradeoff做的很好, 功能比较全面, 又不太难.
Ofbiz还是够复杂的, 看了一会儿就晕了.

其實做一個企業的應用
最重要的選擇並非是"簡單", 應該是 "支持度"
struts 沒有比 webwork 更簡單,
但是 struts 擁有太多開發人員的支持
不論文件, 附加功能, 相關套件, 產品, 開發工具... 等等,
你都能找到類似甚至符合的東西.

至於 Ofbiz 我也有看過
我個人認為, 他給予的觀念很好
部分的設計就像是磚塊中間的水泥
無縫地接合其他的 opensource project
創新的觀念與想法
都是作為一個系統架構師 ( System Architect ) 可以參考的思維

Java 發展至今, 百家爭鳴的情形讓程式開發感到快樂
各式各樣的解決方案, 比起 M$ 一家獨大的情形是一種力量與信念
不過, 我們該如何將這麼好的環境創造客戶更大的利潤
這是大家需要思考的

我很同意，企业应用的复杂问题依靠简单的框架是无法解决的（简单是在解决了复杂问题之后对系统做重构所达到的，所以简单是相对的，在某些人看来可能还是非常复杂）。而且通常来说使用人数越多的框架进步也会越快。所以我相信 Struts 也会有很好的前途。不过目前没有选择 Struts 的朋友也大可不必急于更换框架。
Java 开发框架呈现出的百家争鸣、百花齐放的局面，对于开发者确实是一件幸事。

可能是我的意思没有表达清楚，或者咱们对于框架的理解不同。
我的意思是业务框架离不开技术框架，除非业务框架是一个纯理论性的东西，类似于客户需求。就像现在国内出现了很多业务基础件的平台，它通过设计器描述业务，生成可以运行于.net也可以j2ee(至少自己宣称是)的代码，这里就需要一套转化框架，而这个框架应该是很高技术含量的。同时生成出的具体代码也会遵循一定的技术框架。开发这样的框架和使用框架的开发人员肯定要求不同。
对于框架的看法分歧，实际上也反映出开发人员的细分，比如很多开发人员注意于业务，对于他们需要的是一套成熟的框架或者模式。而另一些开发人员注重于各种技术，利用各种资源和框架组合出一套开发模式，甚至开发自己的框架。
而这些对于客户可能没有区别，都能为客户服务。但却影响到公司的经营和个人的发展。

选择struts有点像现在选择EJB.国内对技术的发展的反应明显比国外慢半拍.国外EJB如火如荼的时候国内还没几个人知道,国外把它视为J2EE中最垃圾的东西的时候国内却又把它视为为至宝.对struts也有点这种感觉.当然这只是从*纯技术*的角度来看.
struts有jakarta和sun撑腰,就像EJB,必然会不断前进,但绝对不会是进步最快的东西.标准的东西也不一定就是好的,就像portlet现在红得发字,JSF却没几个人问津.没有选择struts的朋友大可不必着急,特别是我发现大多数比较smart的人都没有选择struts.当然不包括这里的各位,也不想包括我自己.

EJB != Entites
我也不覺得 EJB 已經沒落了, 如果沒人在用,
BEA , IBM, SUN, Oracle 等等的 Application Server vendor 都會關門不營業了
我只看到越來越多產品採用 EJB 作為核心開發的程式
支持 JDO 的人們也不敢說不可以使用 Session Bean ,
真不知道你的資訊及想法是從何得來 ?

或許我不夠 smart , 我從 struts 1.0 用到現在
大約兩年左右的開發, 開發出許多企業的套件
減少了我專案開發的工時.
我不會說 struts 是最好的 framework
但是我會說 struts 是最好的 solution,
此外..我個人對 webwork , tapestry 都抱持著尊敬的態度等等,
每個 framework 都有他們的精神與核心
要真正體會才能夠創造他的價值....

至於 portlet 與 jsf 的解決方案又不盡然相同
兩個也可以合作無間的運作..
我對於 portlet 與 jsf 都抱有高度的期望
更不能了解你在說些什麼 ..

      首先我就强调了我是从*纯技术*角度说的以上问题(也就是说从开发者的角度,我没讨论商业方面的,我对此还不敢评论).技术上不管EJB2.0还是2.1都是"落后"的,已经有很多更好的方式来解决类似的问题.说道最基本的J2EE的基石RMI,JAX-RPC就不如AltRMI,.NET Remoting等等,我想robbin经常比较J2EE和.Net.更不用说现在最火热的,你看看TSS上的hottest thread都是关于什么的:AOP, IoC,Hibernate...这些已经可以成为一个比较完善的EJB体系的取代物,不过明显的,很多东西不成熟,很多东西也没有,所以只有那些自认为足够smart的人在冒险(我们也许都是愚蠢旁观者).当然,并不是说没有做那些的人就不行了,也许他们才是真正聪明,能够赚大钱的人.EJB3.0的JSR这么快就开始启动也说明了目前EJB的状况.我从来都不否认EJB特别是SB和MDB是一种很有用的东西,只是从纯技术角度它已经不是什么领先的令人神往的玩意.至于Sun,IBM他们的container怎么做,这完全是目前商业方面的问,没看见jboss在干什么吗,也许那群人考虑技术问题比较多.
      我一样没有否认struts的作用,包括本人一直都是用的struts ,它也能够做出很多好东西,但是它的缺点也是显而易见的.从商业方面考虑当然是首选它,但是话有说回来,struts开发对技术的发展反应显得不是很迅速,就像JSR的release一样缓慢.
      portlet和JSF当然不是一回事,要不然sun有病搞类似的两个规范.就欢迎程度,我的感觉是JSF是Sun的为主来推出的,也就是说在整个community中好像是一种自上而下的,而portlet更多是一种community向Sun提出的,是自下而上的,就像一个是总统任命的,另一个是人民选举的,你说哪个会更受欢迎.

没有必要争论孰好孰劣！
适合你的、能解决问题的就是最好的，实用至上！
如果你写 servlet 烦了，你可能需要一种 servlet 模式（mvc模式）。
或者你只会 jsp ，那就让 jsp 充当Controller 又有何不可呢？
不要把问题搞得太复杂，一个框架，在有些人眼里可能很美，有些人却从来不用。

Just do it!

我觉得有必要争论，这样我们才会对各种框架都有一个了解，我们每个人不可能有那么多的时间去研究所有的框架，而大家争论一下我们就有个大致的了解了。

很少见这样深入的讨论。
其实不管是技术框架还是业务框架。最主要看使用的前提。
我非常坚持够用，减少工作量为大原则。
如果一个公司主要做项目为主，可能今天做银行的项目，明天做电信的项目。
完全熟悉业务不现实，那以不变应万变好些，就比如我死守EJB+Struts+JSP.
虽然明知道有些弊端，但必须考虑员工对技术的熟悉程度已经学习的难度。

如果去做一个产品，可能就象dlee说的一样选择业务框架。
我想这里面设计到一个核心竞争力的问题，因为业务框架相对来说比较上层次的
抽象，被复制的难度要大一点。也就是说我在一段时间内是有竞争力的。

其实说的难听一点：利益最根本。选择什么看短期长期的利益。