Ofbiz与应用框架

目前开源的开发框架很多,大家完全没有必要把目光全部集中于 Struts。Struts 中的 MVC 设计也不是最好的。

以前学习 Ofbiz 的时候看到过老戴(Ofbiz 的总设计师 David E. Jones,我们都这样叫他)发的一篇帖子说明 Ofbiz 为什么不能直接使用 Struts。

如果想要学习框架的设计,Ofbiz 是一个非常好的起点,它是真正面向企业应用(面向业务的,而不是纯技术的框架,纯技术的框架是没有多大价值的)而设计的,而 Struts、Turbine 等框架对于简单的 Web 应用还可以,但是对于复杂的企业应用就显得太单薄了。企业应用的问题并不是靠简单地分出 MVC 就可以解决的。

http://www.ofbiz.org

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

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

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

这些框架的目标就是要在大部分场合完全替代 JDBC。然而我觉得有些遗憾的地方是 Hibernate、JDO 的抽象层次仍然没有上升到业务对象的高度(所以它们不能够作为单独的解决方案,而只能作为更大的业务框架中的嵌入式组件。[/quote]

这点我觉得这是技术性框架的优点。正是因为它不涉及具体的业务逻辑,所以才具有通用性。业务逻辑千变万化,越适应业务的技术,必然越专一,这就是所谓的专有技术。

我们要做的是在完全的灵活性(如C/C++)与具体的业务之间找一个平衡点。

技术框架能做到技术上优秀,接口友好,便于包装就是成功了。至于业务框架就应该是其他程序员的工作了。指望一个工具包打天下是不现实的。–也不好,都让人家做了,那,我们吃什么去? :)

我想,我们的注意力能否想如何更好利用现有技术框架上转移,在这个基础上找找一些由技术框架向业务框架进行抽象的规律 ?

最好的状态当然是鱼与熊掌兼得,技术与业务都精通,但现实中很难做到这一点。那么找一条较为平滑实用的学习路线是不是比较现实一点呢?

我并没有贬低技术框架的意思。我这样说是由小企业的发展策略所决定的。小企业做通用软件生存下来的可能性很小,只能先依托一两个行业,深入研究该行业的业务,通过成功实施项目壮大自己。如果同时做多个行业,很难都做好,极有可能任何一个都做不深,那样是没有任何竞争力的。

对于企业来说,通用的解决方案往往不能很好地解决他们的业务问题,因此他们需要为企业(或者是这个行业,如果企业的业务有代表性的话)量身定制的解决方案。软件业本身就是一个服务行业,软件业的利润将会越来越多的向服务转移(而不是靠卖发行包)。企业对为自己量身定制的解决方案(高级服务)的需求也会越来越大。我听说过有些做通用解决方案的公司(甚至是有些大公司),不管对于哪个行业,推销的都是一样的方案。他们的售前见了客户除了吹嘘自己的技术实力和成功经验外,对于客户的业务谈的很少,显然是没有做过认真细致的分析(完全是一派以我为主,强行推销的派头)。客户需要这样的解决方案吗?可能你前脚走人他后脚就把你忘掉了(想赚我的钱,你还嫩点)。在这个领域如果我们把工作真正做好了,以小搏大是完全有可能的。

我来举个例子。低级妓女为很多人服务,她的收入很少。高级妓女被某个亿万富翁包下了,为这个亿万富翁提供全方位的周到服务,她的收入肯定比低级妓女要高(大家可能都看过"风月俏佳人"这部电影)。这个比喻虽然不雅,但是确实说明了对高级服务的需求是很大的。

IT 业的产业链最近几年变化很大,但是最稳定的就是那些高端的厂商,因为他们提供的服务是很难被替代的。市场对技术框架的需求将趋于饱和(这也是为什么那么多很好的技术框架不得不开源的原因,要么是根本赚不到钱,要么是根本没有想过用这个框架来赚钱,这个框架只是更大的业务框架的一部分),而市场对业务框架的需求将越来越大,这个机遇是我们无论如何也要把握的。解决业务问题的能力是最难复制的,也是我们应该孜孜不倦追求的目标。你可以看几本讲 J2EE 的书来学习基本的技术,但是如何对业务进行建模,什么样的架构才是真正实用的架构你仍然是一个门外汉。

进入 IT 业就走上了一条充满风险的不归路,成为业务专家不是你本人是否喜欢的问题,而你要生存下来就必须要走的路。所以我总是对别人说一定要靠两条腿走路,技术和业务,缺一不可,而且都要做好。

REF
http://timeson.itpub.net/post/68/38220