现在的位置: 首页 > 综合 > 正文

Java技术随想

2013年05月12日 ⁄ 综合 ⁄ 共 2191字 ⁄ 字号 评论关闭

CSDN英雄大会召开前之随想

早春三月,江南大地虽然还是处于春捂时节,但万物复苏的清新感觉还是扑面而来.承蒙各位支持我的好友的投票,我在CSDN的MVB票选中获得了第二名,在即将到来的四月份,我荣幸的受CSDN的邀请参加其组织的英雄会.这是对我去年一年坚持写博的一份肯定和鼓励.

从事开发已经很多年了, 这么多年什么都搞过,从底层开发到分布式框架,各种常用语言,开发方法,什么都尝试过,才发现软件这个行业其实也就这样.

这么多年,对于中小开发者来说,我逐步认识了3件事情:

一.java不是万能的
曾经我们对java语言是那么的期待,作为一种比C++简化了的跨平台的面向对象语言.java似乎也没能承受我们的期待.首先在语言上,java的语法在不过的扩充,扩充的速度远远高于对代码本身效率优化的速度.

在桌面开发领域,Java似乎还不能突破VB,PB,DELPHI的包围,在Web领域,PHP,Ruby等语言也在主机托管等领域对java展开了大围剿.但似乎大家仍然把Java做为一个天生的王道,也许是因为那个带垃圾回收机制的虚拟机和大量免费的组件框架吧, 这个时代,尤其在不用M$的软件公司眼里,不用Java开发的系统也不好意思开个几百万.

但是对于绝大多数面向服务和快速应变的门户网站开发团队,PHP妖娆的身段实在有太大的魅力了.

当然java还抱着一个中间件的稻草。不过似乎在面向消息和ESB的架构中,EJB也很难翻身了。

二.开源不是万能的
从2002年开发,各种开源软件风起云涌.sf.net里面的开源项目数以万计.如果整理一下开源的MVC框架,找到100多个,那还是常见的。我们曾经抱着很大的热情去观察每一个开源软件.结果发现开源软件就像别人的饭一样,并不永远合你胃口。大浪淘沙,dwr + struts2 + spring +hibernate这样的框架最终胜出。(struts2虽然只是GA,但也比较成熟了,因为webwork2本身就很成熟,struts2是对webwork2的一次重购,基本上也就是改改包名字)

三.JCP不是万能的
JCP作为制定标准的组织,似乎从来就没有制定出什么让人真正感到实用的东西.从Portlet到JCR到JDO,似乎就没有什么真正用起来的。

Portlet标准最大的问题是没有定义更好的交互模型,JCR的问题是查询接口达不到SQL的强大。JDO,JPA之类,似乎也看不到什么真正的能够替代Hibernate的地方。

这么多年真正炒作起来的概念:

MVC
MVC成就了Struts,而且简直成了他的代名词,作为一个URL可以明确调用的框架,从目前来看还是远远超越tapestry,jsf这些框架的。当他发现webwork比自己实现的更便捷的操作之后,干脆把ww2跟自己合并起来。

ORM
搞java,你不建领域模型那就是没面子,建了领域模型就必然需要一个工具来填充他,Hibernate的确在这个领域做到了最精

IOC
这个概念纯粹是Martin提起来的,居然还就真的火起来了。不得不佩服这位大师。

IoC的前提就是任何希望被装载的组件都要生存在容器中。结果struts2的action也变成了spring的bean。

AOP
和IOC一样,AOP成就了SpringFramework,使用spring可以精简大量的代码

AJAX
靠着google的大力推广,ajax可谓红透半边天。

这几年没炒起来的概念:

门户
前几年,人人都提门户,政府门户,个人门户,个性化定制。

IT也借着这个概念炒Portal,但在中国我们发现,绝大多数门户其实也就是个内容管理系统或者简单的说一个网站,个性化定制似乎也没什么用处,最多也就是像google桌面一样用ajax订阅一些新闻,加上Portlet标准的不够完善,使得Portal很难获得更大的发展。

工作流

不能说工作流不成功,一个表单定制引擎加上表单流转引擎的确可以解决很多企业应用,但是这么多年,也没有一个工作流引擎能取得像hibernate,spring这些框架在各自领域取得的独领半壁江山的效果。--当时写的太快了,没来急推敲原话,改改句子,免得歧义 :)

据我浅薄的经验,我看过很多政府,单位都上OA,但真正用起来的并不多

对于公文流转类型的:绝大多数单位只是像邮件一样发文章

对于请假,批示的:小企业管理不好的,推广不下去;大企业上SAP的,有能用起来的

对于更加复杂的应用:由于对表单数据的要求比较高,通常都是开发者自己开发一套简易的适合项目的流转引擎,或者整个应用还是基于数据库实现。

目前比较国外普及的开源工作流jbpm,shark等都只适用于一些环境。

其实既然叫“工作流”,显而易见,工作的复杂是千差万别的,那又如何能指望有一个普适的工作流框架呢?如果你设计一个面向呼叫中心使用的工作流,面向单据签收类的工作流,面向发文类的工作流说不定还更可能有效。

规则引擎
应用的不成熟性,导致不能真正流行。

目前正在炒,未来还不确定的概念

ESB
ESB的使用环境是在一个有很多现成的应用,并且它们都提供了集成的接口,这时候如果要开发新的应用,可以使用ESB简化集成的操作。但是目前为止这个前提环境的条件在中国似乎也没有形成。所以ESB是否能火也还是一个未知数。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1534756

抱歉!评论已关闭.