透明思考

Sun Java Application Framework是Sun向JCOE（Java Center of Excellence，Sun的技术型合作伙伴）主推的应用框架。我没有看到这个框架的实体，从Sun公司讲师的介绍来看，这是一个从底至顶无所不包的“all-in-one”解决方案。persistence、business component lookup/populate、messaging、logging、MVC、exception hierachy、unit test……你能想到的东西，在JAF的那幅big picture上都能看到。听他们介绍完JAF，我再介绍我们自己的业务框架时相当不好意思——想来想去不过是对Hibernate和Spring做了一点包装而已。

 

但是回过头来看我做的笔记，发现一个很有趣的现象：JAF里面的东西其实我们大多都用到，不过都是作为一个功能组件来用的。譬如JUnit，我把它理解为开发流程的一部分；譬如logging，我们直接用了Log4J和Apache commons-logging，没有再做包装；譬如MVC，我们的业务框架（也就是G-Roller框架）只管到业务层为止，Web层直接在Struts Action里面调用Service Locator；譬如messaging，我用拦截器的方式实现了Observer模式，可以为任何业务组件动态添加监听器，JavaMail或者JMS在我看来只是监听器内部的实现细节而已。我在做G-Roller框架的时候，考虑得最多的就是DAO和business service层的概念清晰，如何以直观的方式实现DAO和service组件、并以灵活的方式装配它们。至于其他的功能，我愿意把它们看作系统的另一个aspect，用AOP的态度来对待它们。如果把这么多的概念都拢在一个framework里面，概念完整性是不是会受到影响呢？这大概就是open source和商业产品在理念上的差异吧？

 

另外还有两件有趣的事。第一，Sun（至少是中国这边）对AOP的认知相当落后，JAF没有提供任何与AOP相关的概念（如果不算servlet filter的话），而照我现在的想法，一个业务框架不提供AOP（至少是interception）是很难接受的，因为那就意味着新的crosscutting concern会对既有代码造成难以估量的影响。第二，Sun现在给合作伙伴主推的解决方案相当lightweight，JAF已经极度淡化EJB的概念，可以看到Sun的主流观念已经是“EJB仅仅是一种可选的实现方式”——和Rod Johnson的观点不谋而合。Sun JAF选择的默认persistence方案是LiDO JDO，这是非常值得玩味的一个现象。