深夜闲聊Java与PHP 以及架构设计思想与最佳实践

深夜闲聊Java与PHP 以及架构设计思想与最佳实践
发信人: wesley (心中的森林), 信区: Java
标  题: 深夜闲聊Java与PHP 以及架构设计思想与最佳实践
发信站: 水木社区 (Thu Dec 24 01:55:04 2009), 站内

转载自本人新浪博客

http://blog.sina.com.cn/s/blog_53923f940100g7xx.html

（老吴自言自语）
最近频繁听说SSH这个词，搞了半天，原来是
Struts + Spring + Hibernate

我没听说过是孤陋得有些过分，不过这个架构最起码过时一两年了
也就是说，咱们国内的大部分Java程序员很可怜
把过时这么久的东西拿着当宝贝

 

（小L上）


小L：那您都用啥捏？
老吴：hibernate我偶尔还是用的，毕竟ORM还是很基础的东西，没必要重新发明

 

小L：我现在做的都是php相关的，项目用到，java就一直放下了，挺可惜的
老吴：php我倒是也用过不少
没比较就没鉴别

 

小L：开发很敏捷吧~不过缺陷也很多
关键就是流行呵呵
老吴：我告诉你一个事实先
不管做啥web应用
如果用java做起来，比php做得还要慢，那就是没用好java

 

小L：java如何做到呢？
老吴：这件事目前就我所知
暂时就我一个人做到
（当然，按照我的孤陋程度而言，估计有大把人都可以做到而我不知道。）

 

小L：。。。

老吴：所以java程序员也很可怜
国外的国内的都是

我看过一些台湾人写的程序，很工整
工整到像用砖头砌的金字塔
基于SSH的

 

小L:这么强？基础教育好啊！
老吴：听我说完

 

小L：好的，您继续说
老吴：工整得像金字塔啥意思呢
每一个独立的需求，都有一整套独立的类和xml配置
jsp action service dao xml配置
如果一个网站有100个独立小需求
那么就有好几百个类，密密匝匝堆在那里

 

小L：这个模块化很清晰啊
老吴：这样是死定的

 

小L：为何？
老吴：做起来很慢
很难维护

 

假设有一个论坛帖子列表的需求
显示一个forum中的thread列表


如果我需要修改一下界面，显示每个发帖人的积分（之前不显示）
那么我需要改jsp action servic dao
一个页面和三个类

假设我需要让帖子按多种不同方式排序，同样需要改这么多

 

小L：哇，后者不是只要改动ORDER BY就可以了么？
老吴：不是改orderby
是增加几种orderby
并且让用户可以自行切换

 

小L：如此，您继续
老吴：假设我需要额外显示发帖人的好友
那么对不起
要大改了

 

要有一套和 friend 相关的 dao service
并且要修改 xml 将这些 service 注入到那个帖子列表的 action 里边
（是的，我知道Spring 2.5 就支持 @AutoWired 了）


然后还要组装一个超级复杂的 viewmodel 放到 struts 的 ValueStack 里边
以便可以在jsp里边显示

 

不是说这个任务无法完成
而是
1、完成任务的时间无法接受
2、完成任务又要不影响其他模块的难度太高
是这样吧？

 

小L：恩，那您如何解决这个问题？
老吴：对于这样的只读表现层页面
我不写 action service dao
只用写jsp和pojo（用于ORM）
而且这个jsp里边代码量比php的代码要少
写起来更容易

 

小L：感觉jsp的代码并不少啊
老吴：我的jsp里边严格的说，没有java代码
只有不超过10种的tag

这些tag都是轻量级的
比如 if else iterator bean beanlist htmlvalue beanfield beanvalue 之类
基本上这几个就够了
当然了，是我自己写的tag

 

小L：这么说这些tag能处理大部分的页面逻辑
老吴：页面逻辑如果是指当前页面的要展现的数据以及数据之间的关系
那么足够了

如果再有phper站出来说java不够敏捷，太笨重，开发周期长
令得java开发员哑口无言，只能罔顾左右而言他
那么我可以理直气壮的站出来说
让大家公推一个写代码最快的php高手出来
我相信用我的框架去开发，一个经过6个月训练的java新手
可以大致在速度上不输给他

 

小L：哇，这么强大
可惜现在大多java写手还是不如php，您这东西可能有革命性意义啊

老吴：革命性是肯定的
相当于一个有 OpenAPI 的 Drupal

 

小L：Drupal在国外很火啊，国内感觉不怎么样
老吴：Drupal上开发东西，如果没有Drupal基础功能和现成插件支持的，基本只能去hack
你知道hack是指啥吧

 

小L：不知道具体是指啥
老吴：比如php的插件，基本都是hack
因为通常要改动底层的php文件
这里加几行，那里加几行之类

 

比如discuz的插件，全部都叫做hack
因为都需要修改discuz本身的代码
（当然Discuz不是框架，但究其本身的性质而言，应该属于一个缺乏OpenAPI的开放开源
平台）

 

小L：不过框架也不是完美的，修改很正常吧
老吴：框架是理论上不应该被修改的
框架是不应当掺入应用逻辑和特定业务需求的

 

小L：对啊
老吴：当然改框架是正常的，框架需要经常改动以便方便的支持更广泛的业务需求
但必须是通用的，是多种业务需求的抽象
但php做不到这个

要实现业务需求，基本上必须hack
也就是说得修改底层框架的代码，我说的是那种 Full Stack 的框架哈
不是说PDO， Smarty这种单层框架
比如 Drupal 是一个Full Stack框架
也就是说，只需要 Drupal ，可以几乎不用写代码就搭出一个网站来

 

小L：了解
老吴：这是php绕不过去的坎
也许 php 6 会有好转
因为全面向对象了

但究其根源
php 的问题是各类应用之间的关系是合作分工关系
具有上下层关系的框架太少

例如 Smarty 是展现层框架
这是个很好的抽象

 

小L：对，很流行呵呵
老吴：数据层 + 逻辑层 + 展现层
这属于上下层关系
是可维护的关系

再例如 discuz + ucenter + ucenterhome
是分工合作关系
是难于维护的
（又举了个不合适的例子，拿产品当框架了）

 

在java世界里边，很少有分工合作关系的框架
基本都是上下层的
每个框架解决其中一到几层的问题

 

这就带来了一个显而易见的差别（与PHP）
php要搭一个功能丰富的应用很容易
拼接各个可以合作的应用模块即可

 

小L：对的

老吴：可以认为这是横向的
而java则非常困难

做一丁点小事情
就需要从表现层 ...... 一直用到数据层框架
每个都得用
不用就断层
每个都有不低的学习曲线

 

小L：那这不增加了java流行的难度？
老吴：嗯，造成了开发java应用的极度困难

 

小L：是啊，望而却步啊
php很快就能上手

老吴：这我相信是很多人远离java的重要原因
说，不敏捷
笨重

 

小L：对
老吴：但
java完全可以不这么玩
java里边也有full stack 的框架
例如 RIFE
用过的人都极其推崇
这是一个好的范例

 

小L：恩~我没用过呵呵
老吴：嗯，我是举个例子
并不是说我认为RIFE已经足够好了
full stack的框架和php的直接拿来就部署的应用当然还有很大区别
毕竟还需要编程序

 

小L：恩，我感觉jsp的配置挺麻烦的
老吴：java世界的本质问题是
十几年过去了
基本的问题还没解决

也就是说温饱还没解决
还没法敏捷思考

 

JavaEE 6 的发布，算是基本解决了温饱问题


温饱是啥意思呢？

温饱就是说
1、把各个层之间的关系理清
2、把每层里边的最佳实践搞清楚


这两件事花了JavaEE整整十年

而php根本不解决这两件事

 

绝大部分php是单层的
偶尔有些做得好一些的，是三层
像discuz是两层
ucenterhome是两层半

 

小L:意思是有数据库层么？
老吴：ucenterhome有半层逻辑层
都没有数据层

discuz双层指的是
页面表现层是一层
其他东西的另外一层

 

如果要php分层分得好
同样需要花将近10年时间
才能有大量的上下层协作的中间件框架问世

 

小L：它肯定不会花这么多时间来做这个事情呵呵
老吴：所以，我是不会对php的任何新版本新特性抱有任何幻想的
因为JavaEE吃了10年的屎
php, ruby on rails 才刚开始想这个问题不久
他们聪明的地方在于不去吃屎

 

小L：避开这个问题
老吴：是的，当然这不是件坏事
毕竟很流行，很多人追捧
做起来方便，学习曲线低

 

小L：是啊
老吴：但，这要看你的理想是什么
是想成为一个程序设计的艺术家呢
还是想成为一个泥瓦匠
这是个人精神层面追求的方面

 

小L：我是想成为艺术家~
老吴：如果要做艺术家
你要知道很多艺术家们都吃了10年屎
比如我，比如JavaEE的那些专家们

 

甚至有个专家组成员经济危机差点活不下去
就是我博客里提到的Reza老兄
他是EJB in Action的作者
目前是Resin的核心开发员，是JavaEE专家组的独立成员
他写了20年程序
从80年代开始的

 

小L：真不容易啊
老吴：我只不过是可以提供“相对”快速一点的成为艺术家的途径
因为你可以站在我的肩上

 

粗放的说我写了23年程序
从10岁开始学写BASIC
精确的说写了13年java程序

 

小L：java才诞生多少年啊，95年诞生的？
老吴：对
我是96年底开始的
换句话说，他们吃过的屎，我同样都吃过
他们吃完明白的事情，我也都明白

但我不得不说，他们太艺术家追求了
他们有点过分精英意识了

 

小L：呵呵
老吴：广大java程序员还处于水深火热中挣扎
而他们不管不顾的搞了10年艺术

不是说搞艺术不对
而是不能光搞艺术

 

小L：恩
老吴：所以，我看不下去也忍受不下去了
因为我也是个java程序员
一帮子人整天搞艺术无视我的需求，我也受不了

 

小L：恩，该拯救Java程序员了呵呵
老吴：没那么快，我先把我自己拯救了

首先，重新做了一个类似struts和stripes的框架
然后，参考Drupal的概念做了一个基本上免编程的web开发底层
再然后参考 ruby on rails 的REST以及Convension over Configuration的思想
重新做了个一个无缝与上述两个底层集成的 REST 引擎
另外，我的框架可以算是整体无配置文件的（通过 Annotation 和数据库进行必要配置）

全部整到一起，基本上只用写POJO和JSP就可以实现大部分网站的功能了

 

小L：那不是和Drupal非常容易就架起一个web应用来
老吴：嗯，然后，用我做好的这套东西
一周时间做了一个网上商城

 

小L：果然
老吴：上帝说要有光，人类却仍在黑暗里
于是，我发明个手电筒先

 

这是我最近两三个月远离了所有同事，独自干的事情
我教了他们三年时间
结果让我很伤心
没任何一个人学到我的哪怕皮毛

 

小L：哎。。真是遗憾
老吴：我检讨了自己
发现是我的问题

道理不能靠嘴说
哪怕是言传身教
对现代的年轻人来说，也会让他们失去耐心

 

小L：是啊
老吴：打个比方

我告诉你按我说的做可以发大财
结果做了3年，还是没发财
是个人都会嘀咕的

 

所以我决定不再告诉别人任何道理
直接拿出几十根金条给他们看下
大家就都服气了

 

我让他们去各谋生路
自己上手做一个我3年前告诉他们可以实现的一个目标
然后3个月后连最终结果一起拿给他们看

 

比任何的说教
都要强一百倍

 

小L：他们肯定后悔极了呵呵
老吴：还好，每个人的理想也不同，并不是每个人都想当艺术家。

不过其中一个回来了
说他哪里都不去了

 

小L：呵呵，挺好啊
老吴：嗯，挺好的兄弟

我今天跟他说
你不要问我任何技术问题
我也不会回答

 

我说，我拿这个框架已经做好的几个网站里边，其需求已经涵盖了你未来几个月要做的事
情的全部
相当于最佳实践的范例大全


你要做的是学习我的代码
而且只学习我的代码

然后，做到你写的东西和我写的东西如同一个模子出来的


把这样的过程反复十几次
那么我所有的精髓就会印在你的脑海里
真正成为你自己的东西了
之后，你想学什么做怎么就可以随心所欲了，再不用像现在这样受我的束缚了。

 

小L：如果我不太懂Java，怎么学习你的框架和思想呢
老吴：先用用 struts 2.0
用Resin做appserver
用JSR299规范做 DI 依赖反转注入
用hibernate或者eclipselink做 JPA 数据访问层
业余的时候，做点小玩具练个手

然后上手我的框架就会比较快了

 

小L：有什么书、资料、网站推荐的么？
老吴：1、hibernate 的中文文档
2、struts2 的官方英文文档
3、resin的官方网站关于CDI的文档
http://caucho.com/resin/doc/resin-ioc.xtp

 

书可以看，但中文书籍只能看翻译的

 

struts刚发布了一个用于被 CDI 集成的插件
你用resin的CDI实现，来集成 struts2 以及 Hibernate JPA 应当很容易

hibernate的书和文档只看JPA相关的即可
hibernate的专有特性不学也罢

 

JPA2.0都发布了
以后ORM基本上都会符合JPA规范了
所以用啥ORM实现是不关键的

特别不能用hibernate自己的扩展
无法移植的
而且 Hibernate 的某些实现方法也不能算是最佳实践
用 JPA 1.0 就好
hibenate对 JPA 1.0的支持很完善了

 

小L：好的，我去试试看
老吴：没问题，方向上的事情尽管问我
具体的技术问题，问Google

 

（小L、老吴互道晚安，各自下）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~``

 

大致扫了一遍
基本看到这样的意思

java 工整分层太多，敏捷模块太少
造成学习曲线过高，需求调整太慢
但是我的新框架就不一样了
而我的框架代码具体是这样风格的——

然后没了。


这文章里提到的 java 的——无论是叫特点还是叫缺点——都是事实
这些缺陷确是早有人提出，而且不是一次两次提出的问题了
但问题在于，关于“新框架”这一解决方案的敏捷程度
一样是同样被不同的人，不同的项目提过不知道多少遍的话
而按照这篇文章的说法，这些曾经声称解决了敏捷问题的项目大多都在吃屎


对不起，我不是想说您的新框架一定达不到您所宣称的强大
但虽然很长，内容很多
我确实仍然只看到了一篇内容很多的预告