为什么 Ofbiz 没有使用 Struts

哈哈，看来我们要另开几个线索专门讨论 Ofbiz 各部分的设计了。
http://forum.hibernate.org.cn/viewtopic.php?p=5861#5861

看了这里的讨论，真是满热闹的。
我大概是从OFBiz刚刚开始在sourceforge上有它的第一个页面时开始试用的。很快我就放弃了。有几个原因（现在不知道发展的怎么样），包括：
1。OFBiz是以数据建模为核心的，我不是太喜欢
2。OFBiz预想的规模太大，我不太喜欢规模太大的东西，因为我是一个Unix哲学的推崇者
第一条直接导致OFBiz的GenericEntity，我可以说基本上失去了所有面向对象的优点。我喜欢显式编程，而不是一个HashMap.实际上GenericEntity是PropertiesList的一个泛化，EricGamma、MartinFlower都有专门的文章谈到这一点，是迫不得已的时候才用的东西。
第二条仔细来说并不完全正确，其实一个系统大不要紧，但是部件之间的依赖不能太紧密，软件体系结构的发展也是出于这个目的。OFBiz每样东西都要自创固然是好事情，但是不是意味着它本身的结构设计就是有缺陷呢？
最后的原因是因为当时我所在的公司在很久以前就有这样一个系统，是用Delphi做的。当这样的系统（数据建模+脚本语言作为粘合剂+GUI设计器）去实现一些小业务的时候，效率非常高。现在公司里面没有做过任何开发的工程实施人员，做一套功能非常完备的库存管理系统大概只要半个月即可以了。
但是当系统达到一定规模的时候，当这样的客户需求频繁发生变化的时候，表面上看起来的灵活却变成了一种负担。设计数据模型的重点不是去分析到底什么地方是可变的，什么地方是不可变的，业务会以什么样的方式变化（OO里面经典的Hotspot分析），所以整个系统慢慢会变成一堆数据，根本无法理解它真正的行为。原先感觉我们这种设计会减少整个公司的开发和实施成本，最后却适得其反。
------------------------------------------------------------------------------------
Struts我也用的比较早，经过几个项目以后基本上就放弃了。但Struts社团的支持非常好，工具多，资源也比较丰富。也许本来用struts解决一个问题会比较困难，但现在的情况是可能这种困难别人早就帮你解决了，所以一般的项目来说，Struts目前来说还是比较好的框架。
我不喜欢Struts的原因也和不喜欢Ofbiz的原因基本上是一样的，OFBiz用一个DynamicProperties(PropertiesList)模式代替了所有的东西，结果就是数据建模。而Struts基本上用一个Command模式代替了所有的东西，结果就是纯过程型的编程。看看你的Action有多少相似而不尽相同的地方就知道了。
------------------------------------------------------------------------------------
我喜欢Hibernate的原因是它基本上保持了Java语言的原意，你不会得到一堆没有任何业务行为的数据，也不会得到一个被篡改了的类文件（发生在运行时），还有一套比较实际的对象+数据查询语言（目前JDO认为查询返回的一定是对象，我们的一个项目同时需要在Oracle和SQL跑，结果就是两套查询、报表，还得用SQL）。这比较符合O/R的经典理论，面向对象的原则和实际的需求。
界面层我则偏向于Tapestry。一个简单的例子就是如果你要在两个页面之间传输一个对象，Tapestry可以让你象普通的Java类之间通讯一样，得到另一个页面的实例（普通的Java类），然后用你的对象作为参数调用那个页面实例的方法。其它的譬如说纯HTML(XML,WML)，组件化等等也非常简洁、完美。
-----------------------------------------------------------------------------------
其实我要求不高，给我一个对象的世界，让我实现业务，你去展现、去持久、去分布，不要让别的东西来打扰我。当然，万一我需要数据你也得给我，我还要做报表呢。呵呵。

可否再深入的说一下就你个人认为ofbiz的不足。

O/R mapping的作用是弥补对象世界和关系世界的裂缝，http://www.ksc.com/article5.htm堪称O/R理论中最重要的文章，OFBIZ的实体引擎实在不能称为ORM.

我对 Ofbiz 的体会也不是很深。Ofbiz 把原先必须通过 Java 编程解决的问题转化为用 xml 文件进行数据建模，确实很大地减小了开发工作量。很多原先必须编程解决的问题现在只需要写 xml 文件就可以了（更多的 xml 文件，更少的代码量）。
我们做的是 MIS 类的数据库操作密集型的软件开发，所以我们的框架也是以数据建模为核心的。
对于业务框架的可重用性，我的考虑是这个业务框架是为了解决更复杂的业务问题，即为了更大范围的重用而设计的，其中每一部分的可重用性并不是非常重要，各部分耦合紧密也无可非议。这是由它的设计目标决定的，因为每一部分不是设计来单独使用，而是为了一个更大的设计目标服务的。如果你只喜欢其中某一部分而对其它部分都不喜欢，那么最好完全不要用这个框架，而使用更适用的轻量级框架。好在现在可用的 Java 框架已经是非常多了。

很多人都是框架的使用者，而不是架构师，很少“掌握”框架的精髓，因而“为自己的应用定制适合自己的框架”，更少人去写一个好的框架来给别人使用。

作为普通的应用者，大多数时候都是套用框架，目的仅仅是不想重新发明轮子。
他们不仅仅要用框架，还喜欢用控件等等一大堆现成的东西，目的仅仅是为了节省开发时间。

因此我所想要的应用框架是这样的：
1。有大靠山。
这意味着有比较多的资料，而且会不断更新，而且即便是框架升级，那些框架的设计者也会动脑经来兼容我以前的代码，而且我可以稍微的少一点担心，今天还在学习它怎么用，明天它就人间蒸发了。如同MFC，尽管有不少人说它烂，但是我还是可能会考虑使用－－现在当然不用了。说白了，这种框架卖的是服务，而是框架本身。
2。容易使用。
因为我需要的是开发效率。而且中小项目居多，大而全是我所不欲。

如果是这样的需求，应当如何选择？一度打算使用struts，结果某某人说了
一句：如果你已经使用了struts就接着用，否则就使用jsf。让我开始犹豫，
这个某某人的意思是不是说，如果将应用的框架由struts转化为jsf将有不小的工作量？而目前的jsf还处于草案阶段。。。。

关于框架，我还想说的是现在有很多开源的框架，都只解决了企业级应用中的一部分问题。这些不同的框架设计理念不同，彼此存在着一些内在差异，把这些框架简单组合在一起是否就能大幅度提高开发效率我是很怀疑的。一个成熟的框架必须要保证整体的概念完整性，而概念完整性才是软件质量和开发效率的关键。
老戴为什么没有采用 Struts 而要自己设计，就是因为 Struts 的设计理念与 Ofbiz 有很大的差距。而 Ofbiz 中的各个部分确实保持了整体的概念完整性，这与其只有几个主要的核心设计人员是分不开的。
不同的开源框架随着使用人数的增加，在更高的版本中会加入更多的功能，随着功能的膨胀，最后甚至想无所不包，企图解决一切的问题，这样它们彼此之间将产生很多功能上的重叠，把它们简单组合在一起更容易出问题。

框架的重用是高粒度的重用，只要能充分保证概念完整性，无所谓这个框架是采用对象建模、数据建模还是混合方式设计出来的。无论对象建模还是数据建模都是着眼于技术层面的重用，业务解决方案的重用对我们才是最有意义的重用。potian 的话并没有说服我框架一定要完全采用对象建模的方式来建造（因为我知道很多问题完全采用 OO 是无法解决的），只是让我理解了对象建模的优点。
我的一位朋友前几天说的话我觉得很有道理。

现在为什么会有 JSF？是不是因为 Struts 已经不适用了？

？？关注

JSF好象也是很久的事了，只是Sun自从生了Java这个Baby后行动就像没加润滑油的老爷车！

我个人认为业务框架与技术框架两者是不能割裂开讨论的。技术框架是业务框架真实世界中具体实现方式，业务框架是对真实世界中遇到问题的逻辑抽象，以及各类抽象之间的关系。
1、最终具体实现是由技术框架完成。如果没有一个稳固的技术框架作为依托平台，业务框架中的抽像又如何发挥作用呢？只有对项目内容有了一个比较充分的了解之后才能选择一个适合项目的需要技术框架。因地致宜，莫要盲从。
2、只有能帮助客户解决真实世界是的具体问题，让客户从中受益才能说产品或是项目成功。如何解决客户的业务问题，需要一个优良的业务框架为之提供服务。如果不能很好的解决客户的真实问题，即使拥有一个最先进的技术框架也是没有用处的。