为什么 Ofbiz 没有使用 Struts

呵呵，怎么能说难听呢？这才是技术人员最终要考虑的问题。你总想有一天实现自己的价值吧？解决了客户的业务问题，首先给客户创造了商业价值，然后才有可能实现你自己的价值。软件业将越来越向服务业的方向发展，将来的竞争将是高层次的残酷竞争。最终的受益者将是客户（企业和最终用户），并且会带动整个社会向信息化的转型，改善全社会的资源配置，提升全社会的生产效率。
业务问题往往是复杂的，从要解决的业务问题入手展开思考，才有可能把技术用好用深入。
我来举个例子：假设我们要做一套报表服务器。客户有很多下属单位，下属单位的报表都要汇总到总部，在总部以各种方式进行汇总。如何解决这个分布式系统中数据的一致性？首先要保证可靠的传输，如果各下属单位以拨号方式与总部相连，而不是永久连接，如何保证传输可靠性？这些报表数据如何定义，如何汇总？生成的这些报表需要进行审核，要用工作流方式来实现。要对报表进行完善的管理，如：设置报表的各种参数，设置报表是自动生成还是手动生成，对报表进行检索、修改、删除，还要对报表的访问权限加以控制。合在一起就是一个很复杂的问题。目前任何的技术框架都没有给你提供现成的解决方案（因为这完全是一个业务问题）。
由业务问题入手，可以应用到的技术范围是无限宽广的。具体采用什么框架，是一个 tradeoff 的艺术。

其实这个讨论是相当泛泛的。为什么 Ofbiz 中的 MVC 比 Struts 灵活，它们究竟是怎样设计的等等问题都没有讲清楚。这些问题需要留待以后深入讨论。大家先有一个学习的方向，然后在具体工作中再去体会。框架具有一定的复杂性，而一个人的时间是有限的，抓紧时间，了解更多的框架，最终找到最适合自己的才是重要的。我不太赞成所有项目都用相同的框架来开发，因为不同的框架对于项目的进度和质量有很大影响（再次强调选择正确工具的重要性，比如我用 Eclipse 做 Java 开发的效率是采用 Vi+Javac 的十倍）。即使从成本上考虑，也不应该所有项目采用相同的框架。我是很相信我们的程序员的学习能力的，他们在 3、4 个月的项目开发期间学会使用一种新的框架是绰绰有余的（掌握了一种框架再掌握其它框架就会比较容易，而且还会加深他们对原先框架的理解）。当然首先我要确定这种框架确实是最适合的（我认为最适合，还是带有一定的主观性）。一种框架就是一种解决问题的思路，从公司的角度，开发人员掌握多种框架也符合公司的利益（应该鼓励开发人员学习和实现自己的想法，而不是把他们当作编程机器严加看管）。
根据我对 IT 行业多年来的观察，成功者往往都是那些真正专注于解决问题的人，我更多的指的是业务问题。
最后再说一句，对各种框架进行深入讨论是有必要的，不要搞神秘主义。任何问题只要找到其症结，都是可以讨论清楚的。

当然选择的前提是能解决问题。
我也非常相信程序员的学习能力。
但是在一个项目中使用太多新技术或者说大部分小组成员不熟悉的技术，肯定是有比较大的风险。
所以大部分的做法是，局部的替换。
再说技术框架和业务框架之间没有明显的界限。
我们不能就认为ofbiz是业务框架,struts是技术框架。

还有我认为学习或者研究多种框架更多是CTO等人的责任。
当然程序员需要了解。因为PM或Boss要考虑学习的成本。

至于选择什么样的框架，除了CTO的知识之外，还有就是
项目或者产品以及人员的实际情况。

我基本上同意，做一个新项目对于所应用的框架可以做小范围的替换，比如把 Entity Bean 替换为 Hibernate。这样程序员适应起来会比较容易。一定要考虑程序员的接受能力，不能揠苗助长。CTO 或者 PM 确实必须要掌握多一些的框架。至少要对这些框架的特点、适用的场合非常了解。因为具体用起来之后他们要起到一个示范者的作用（而不是直接甩给程序员学习自己落得轻松）。只要有人带领，程序员学习起来速度会很快的。一两个程序员掌握了就会产生榜样作用，辐射到更多的人。不过要注意的一个问题是学习要有针对性，因为对于一个商业化的组织，最终的目的还是要通过做项目、做产品来获得发展，光学习不出活是不行的。这要取得一个平衡，需要 CTO 或者 PM 掌握好。
Ofbiz 确实是业务框架，这在 Ofbiz 的介绍中有说明。当然 Ofbiz 解决了 Struts 要解决的很多问题，不过它的最终目标是面向业务（Business）的。业务框架还可以分为多个种类和多个层次，我们以后再讨论。
The goal of the project is to create an open source application framework, application components, and suite of enterprise applications and to build a community of end users and developers that work together to create easy to customize business software based on best practices.

这样开源的业务框架其实还有很多，在 Freshmeat 上找找，做 ERP/CRM（或者自称是做 ERP/CRM）的框架已经有不少。另外的一个我比较关注的框架是 GNUe（http://www.gnu.org/software/gnue/project/project.html）。
开源的业务框架对于提供解决问题的思路是很有价值的，这些思路是大公司所不愿意透露的。授人以鱼不如授人以渔，开源软件正是要授人以渔。虽然它们目前可能还不是非常成熟，但是你可以期待它们会变得更好。因为这类框架总是受到广泛关注的，所以它们一定会得到发展。

我觉得老大可以去写文章了，一个好的ppt和方案比一个好的软件值钱的多。
解决业务问题是软件开发的目标，怎么强调都不为过。选用合适的技术手段则是使自己利润最大化的目标。而在现实中，自己的利益经常会和客户的利益相矛盾。因此，我们必须在二者之间寻找平衡。
很多业务到手以后，会有很多不同的做发。比如，开发通用框架，开发针对性的软件（还算不上框架，我认为可以复用是框架的首要特点），外包，简化业务后开发。这时候，如何选择是非常重要的，而经济利益是第一个要考虑的因素。尤其是采用什么技术所带来的经济影响，比如学习成本，开发成本，公司短期利益，长期利益，程序员个人利益（这也是不能忽略的，有些项目，本来jsp就够了，但实际上却采用了分层，ejb等等，因为程序个人出于自身考虑，换工作，ejb比jsp值钱）。由于公司大小的不同，决策也各不相同。

非常同意，但是操作却不容易，开发人员水平的差距，开发人员的爱好不同等等都会制约，而且开发人员的流动性太大，而很多东西，又需要积累。因此，实际上只有cto或者公司资深程序员才会真正关注并研究多个框架。
不知道你们公司项目的情况，很多公司的项目都是时间很紧的，很少有时间为某个项目学习准备。而对具体某个项目采用什么框架却是个经验活。实际上一个公司一般掌握1到2个就能应付大多数应用了。我们对框架的学习主要在平时，项目来了就直接实践了。

这句话应该有个前提，而很多人忽视这个前提，那就是成功者对于解决问题所需的技术手段已经很熟练，不成问题了，而据我的观察，很多程序员对于技术问题还差的远。
就像前面所属的业务框架和技术框架，技术都不具备，如何能完成业务实现。二者兼备才是成功的保证。
题外话，实际上做项目，倒并不需要具备很高的技术水平，当然要够用，也不要对业务烂熟，也要够用，就看公关、营销等等的水平，在我看来这是比技术更难的学问。

我并不这样认为，能否找到好的工作，会 EJB 当然有些优势，但是如果你有很多项目实施的成功经验，并且对于解决各种复杂的业务问题非常了解，那你的优势就非常大了。会 EJB 我可以让你做一个程序员，但是能解决复杂的业务问题，并且了解各种框架的优势和劣势，我要直接把你请来做设计师，甚至你来做 PM，我来做设计或者开发都没有问题。
我强烈反对程序员仅仅为了提高待遇就频繁更换工作的做法，那样对你的职业生涯是非常不利的。在这个竞争激烈的行业里，信誉的积累是非常重要的，所以首先要做好人。我并不会在一个项目进展一半时候离开，把一个烂摊子留给同事和客户（我没有特指谁，请别介意）。

你的这句话具有危险的倾向，很容易让某些人认为技术是完全不重要的。所以我只能说这句话是错误的。如果你想开一家百年老店，你无论如何一定要先把事情做好才行。这也是我到现在还能活着在这里跟你讨论问题的原因。

就我的了解，多数公司的多数程序员往往都是设计编码一起上的，好点的会有一个专职设计师，很多都没有。而这些公司呢多数以开发ejb来赚钱。对于多数程序员的短期职业目标恐怕就是这些职位。而且不少程序员的长期目标恐怕都不是设计师之类的。
不知道你的位置，但感觉最少是个主管，很多主管恐怕想的也和你不一样吧


其实这一点咱俩是一样的。解决业务问题是目标，而技术是手段，缺了哪个都不行，可在一定阶段内，还是要根据自己的实际情况分出主次来。


说道这里，其实有些跑题。
作为程序员对框架的学习是进一步发展的有力促进，而在工作中恰当的选择框架，则能使工作更出色。
对于技术框架和业务框架的讨论，首先能够明确二者的重要区别，再讨论会目标更准确一些。
个人感觉业务框架还远不如技术框架成熟和通用，任重而道远啊。

这样说就对了。做技术的说起话来让人感觉象销售，做销售的说起话来让人感觉象技术人员，这样都是搞不好的。我们这里分的还是比较清楚的。
如果你是做技术的，就要做一个专业的开发者，如果你是做销售的，就要做一个专业的销售人员。不具有专业精神，任何一个职位都做不好。一个人分兼几个角色不是很好的事情，至少不要同时分兼两个以上的角色。

每个 PM 根据自身经历不同会有自己的很多想法，我不想过多品评。EJB 并不是什么保证赢利的利器，这就是我的想法。

逐字逐句地看完这个帖子以后，我的心久久不能平静，震撼啊！为什么会有如此好的帖子！我纵横论坛多年，自以为再也不会有任何帖子能打动我，没想到今天看到了如此精妙绝伦的这样一篇帖子。楼主，是你让我深深地理解了‘人外有人，天外有天’这句话。谢谢侬！
　　　　在看完这帖子以后，我没有立即回复，因为我生怕我庸俗不堪的回复会玷污了这网上少有的帖子。但是我还是回复了，因为觉得如果不能在如此精彩的帖子后面留下自己的网名，那我死也不会瞑目的！能够在如此精彩的帖子后面留下自己的网名是多么骄傲的一件事啊！楼主，请原谅我的自私！
　　　　这是百年难得一见的好贴啊！苍天有眼啊，让我在有生之年得以观得如此精彩绝伦的帖子！我知道无论用多么华丽的辞藻来形容楼主您帖子的精彩程度都是不够的，都是虚伪的，所以我只想说一句：您的帖子太好看了！我愿意一辈子的看下去！

这里的人都比较认真，想得也比别人多，并且都是在专研事情的人，希望大家都有一个更好的明天
关于架构和业务，我觉得都离不开项目。项目的大小和成本决定了采用的技术和手段，当然这么说不是说架构不重要，而是哪一种更合适。
话说到ofbiz上去。我觉得OR Mapping已经有很多成熟的，表现层也更是丰富多彩，工作流引擎和service引擎很多开源架构也有，那么
what the fuck makes ofbiz diffrent?
是不是这又是埃里克森的哲学的又一次显现？
我们的技术并不是都是最好的，但我们的技术整合在一起可以更好地工作，就好象汽车一样？
我对ofbiz不熟，所以有这么一种也许多疑的心态

OFBiz的entity engine和常见的ORM有一点很大不同，他mapping的object只有一个:GenericEntity，称它的entity engine为adaptive object model更为合适一些，是一种比较灵活，代码量非常少的独特的数据持久化方案。使用OFBiz的entity engine做的项目和其他ORM相比有一个很明显的特征就是：非常少的对象。对于这一点上有过很多的讨论，对于它的优缺点评价是仁者见仁了......

在表现层方面，由于OFBiz的MVC实现是采用了adapter的方式，这样能够方便使用，扩展现有的各种成熟的技术，在表现层它可以使用JSP, Velocity, Freemarker, JPublish, 等等，你可以很方便的扩展它的ViewHandler来使用你熟悉的技术。在逻辑层上可以也扩展各种方式，比如Java, Script, Service Engine等等。这样的MVC实现非常灵活，和那种逻辑层必须使用固定的action接口，view只能JSP或者1，2种模板技术的MVC实现相比，有很大的优势。

OFBiz从技术架构上来说是SOA (Service Oriented Architecture)，我没有接触过其他的service engine，不好说它有比较特别的地方。看它的ECA (event condition action)，group，封装事务 这些特性，都是一些计算机架构上蛮常见的想法，ECA借鉴database trigger的想法，事务封装借鉴EJB的事务描述想法。相信其他的service engine也应该有这些东西，好的设计想法是通用的，:)

在workflow engine上，我花过一些时间研究，基于wfmc规范实现的opensource workflow engine有蛮多的，但是目前没有看到成熟的，或许是因为规范还不成熟？有兴趣的话，我们可以另开话题聊这一块。

OFBiz和其他架构最大的不同在于它不仅仅是一个优秀的技术架构，还是一个优秀的业务架构，它实现的data model可是非常有价值的哦。光这一点就值得好好研究。