深夜闲聊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 的——无论是叫特点还是叫缺点——都是事实
这些缺陷确是早有人提出,而且不是一次两次提出的问题了
但问题在于,关于“新框架”这一解决方案的敏捷程度
一样是同样被不同的人,不同的项目提过不知道多少遍的话
而按照这篇文章的说法,这些曾经声称解决了敏捷问题的项目大多都在吃屎
对不起,我不是想说您的新框架一定达不到您所宣称的强大
但虽然很长,内容很多
我确实仍然只看到了一篇内容很多的预告