为什么 Ofbiz 没有使用 Struts

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，感觉比较好，你可以找些资料看看。
http://www.ofbiz.org

我从来没有说过 Hibernate 是万能的这样的话，所以别安在我的头上。

dlee说的很对的，在应用软件开发领域，单纯的技术框架是没有多少价值的，因为IT行业已经过了泡沫时期，现在要赚钱，是那些面向行业的的业务框架。不过业务框架相对于技术框架来说，更加难以成功，因为技术框架解决的问题相对明确和简单，而业务框架要解决的商务问题实在太灵活多变了，也许Ofbiz算是一个成功的业务框架，如果你能够做出一个很好的某行业的业务框架，赚钱是一定的了。

dlee，我觉得你现在思路越来越清晰了。

这点我觉得这是技术性框架的优点。正是因为它不涉及具体的业务逻辑，所以才具有通用性。业务逻辑千变万化，越适应业务的技术，必然越专一，这就是所谓的专有技术。
我们要做的是在完全的灵活性（如C/C++）与具体的业务之间找一个平衡点。
技术框架能做到技术上优秀，接口友好，便于包装就是成功了。至于业务框架就应该是其他程序员的工作了。指望一个工具包打天下是不现实的。--也不好，都让人家做了，那，我们吃什么去？ ：）
我想，我们的注意力能否想如何更好利用现有技术框架上转移，在这个基础上找找一些由技术框架向业务框架进行抽象的规律 ？
最好的状态当然是鱼与熊掌兼得，技术与业务都精通，但现实中很难做到这一点。那么找一条较为平滑实用的学习路线是不是比较现实一点呢？

这个贴子真不错，国内很少这样的。
对于一般业务而言，EJB确实不实用。

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 了
根本就是讓大象去踩死一隻小螞蟻
不過我不否認 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 开发框架（开源的或者不开源的）展开客观深入的讨论。这些讨论对于来这里的每个人都会是有益的。

这里提到了技术框架和业务框架的问题，个人认为，业务框架依赖于技术框架。因此一个好的技术框架是很重要的，尤其是考虑产品化。但是好的技术框架如何组织成业务框架也是个大问题。
做框架的目的就是为了很好的复用，越是底层的框架复用的机会就越多，这也是很多公司愿意作底层框架的原因。同时底层框架更换的难度相对较小，比如jdo和hibernate，但是高层框架的学习使用要比底层框架难，更换的成本也就高，如果把自己绑在ofbiz之上，估计会有很多人犹豫。
最后，还有一个赚钱的问题。很多项目，简单的使用一些底层框架就能够完成，就会很少选用高层框架，而对于复杂的项目，很多公司都希望有一套完全属于自己的高层框架，甚至从open source中直接拿代码，但开发框架的技术壁垒很高，成功好像也不多。

不同意，业务框架不应依赖于技术框架。业务框架应是描述企业的具体业务的，技术框架是用来解决机器相关的问题的。我们用OOP的目的是什么？就是设计与实现分开啊。
两者之间的连接才是大难题。好的业务框架应该不依赖一某一具体实现，这样才不会受制于某些专有技术。－－.net也是一个很好的技术框架，但你愿意依赖在上面吗？

看看这个：
http://211.157.100.165:8080/kf/index.jsp
It's very Good!

堪称标准的j2ee企业计算范例，据说使用以下技术：

javaScript + jsp + javaBean + servlet + sessionBean + DAO

（这种架构深合我意也：使用简单+成熟的技术，搭建稳定可靠的企业软件）

空谈各种框架，没有什么实际意义，不是吗？

框架本身有一定的复杂度，如果没有真正用过某种框架，说具体了你反而更要糊涂了。就象 Ofbiz 中 Event Handler、Service、Entity Engine 这些概念对我来说是很具体的，我完全清楚它们代表什么东西，而你可能只能凭字面上的理解，也许就把 Entity Engine 与 Entity Bean 挂上了钩。所以从一个较高的层次（框架要实现的目标、实现的效果）考察一个框架还是有必要的，否则就有可能只见树木不见森林了。
对于设计模式也是这样，我知道 DAO 的目的是要做什么，但是对于没有读过《J2EE 核心模式》的人就会认为这是很深奥的概念。

简单和复杂是相对的，要看你讨论问题的粒度。当你把 CMP、Hibernate、Entity Engine 当作业务框架中的一个部分来考察时是在一个较高的粒度上思考的，因为这 3 样东西做的事情基本上是一样的。但是当你具体去考察 Hibernate 的时候你又会发现它本身也具有相当的复杂度。可以说“一花一世界，一叶一如来”。OOP 无限的封装能力使你总有能力将一套复杂的系统封装成一个大系统中的相对简单的子系统。封装到最高层次就是解决用户业务问题的解决方案了。

你可能会问：为什么你就不能把这些你认为具体的概念解释清楚，让大家都搞明白？原因有 3 点：
1、这些框架和概念已经有相关的文档介绍得非常全面透彻了，这些文档都是开放可自由获得的，我没有把握比这些文档说的更清楚，也不想重新发明轮子。
2、框架的设计确实是一个比较复杂的问题，要讨论清楚，最终大家形成共识需要相当长的时间。很有可能最终无法形成共识。比如我觉得 Struts 的 MVC 设计不够灵活，而 Ofbiz 的设计要好些，而你用惯了 Struts，你会告诉我 Ofbiz 其实也没什么了不起，Ofbiz 能做的 Struts 全部都能做，甚至 Struts 还能够做 Ofbiz 所不能做的一、二、三。这些争论是相当浪费时间的，而我还有比较重要的工作要做。
3、这也和我的懒惰以及主要的兴趣倾向有关，我有时间还想多读些书呢。这点完全是我本身的素质造成的，没什么可辩解的。当然我还是希望尽量为大家做好服务。

这里 Hibernate 相关的版面是属于务实的版面，而 Java 企业技术、其他技术这两个版面相对来说是属于比较务虚的版面，可以讨论更加广泛的技术问题。Java 企业级技术主要就是针对企业要解决的业务问题的，所以在这个版中对业务问题会谈的更多些。