我为什么鼓吹thick client

这个版面好像最流行是XMLHTTP，类似的技术早前也见识过一些。前段日子，moxie对我鼓吹他们的技术（有点类似XMLHTTP）开发如何高效。确实，他的公司开发效率挺高的，至少目前比我们效率高。前提：在前人丰厚的积累基础上。 如果给我足够的积累（人力物力因素），我绝对会比他们快。积累中......
     
  我们先来看看这种js+xml+http的优点：
   1、浏览器，0客户端安装，slim client.
   2、操作系统无关
   3、具有桌面应用程序的一些特征，注意，这里是一些。

  而thickClient的常有的一些问题
   1、安装，升级问题
   2、肥胖问题
   3、操作系统相关问题

  说实话，如果早是几年前我都认为thick Client真没有前途了。当然，现在恰好相反。

  让我们看看thick Client问题的解决方法
    1、安装升级： 我们拥有太多方法了，Java web start就是最好的办法。自动安装升级。

    2、肥胖问题：
       现在芯跳速度越来越让我们对普通的桌面程序效率不再担心；不会再有人给PC配置64兆内存了，因为难以买到；不会有人新配置的机器是window95无盘站或者6.4G硬盘（我的第一台电脑只有6。4G硬盘）。

   3、操作系统？ 嗯？那你一定不会java。

   4、他拥有桌面应用程序所有优点（包括脱机工作），而避免了桌面应用程序最大的几个硬伤，安装/升级/连接限制。我甚至可以建立一个本地数据库。

   5、我们都是java程序员，用接口交流，用代码说话。我和你没有人为的沟壑。想调试任何时候任何人都可以调试。没有人特殊，不存在稀有人才。（这可能就是Robbin所提倡的技术平民化吧）

   6、Client照样可以IoC,可以AOP,可以ORM.

     7、传输方式有N多选择，最差的一种是用XML传输。效率.......

     8、差点忘了说了，不然留下话柄，需要JRE支持。确实，这点总是有点不爽，不过，这个东东好像可以0培训。（当然，还可以从这里骗点钱，卖光盘，不过不要让sun知道）。 如果客户确实要运行业务系统的话，这个代价值得。而且稳定，JS则难说了。

   让我们回头看看js+xml+http:

    1、浏览器相关，据我所知，*****多的实现和浏览器相关。很多都和IE绑定，可是Bill最让人信不过，或需明天为了将firebox挤出，就不知道做了什么。

    2、脱机，本地存储皆是不可能（如果可能就依赖操作系统了吧）。 而这对于一些信息系统来说这太重要了，实际上之前都是特殊问题特殊处理，所以有了p2p之类的。

    3、js程序员+html+java程序员，他们用xml对话。我们知道，甲告诉乙，乙告诉丙，丙告诉丁.......到了戊那儿原话大变样了。再追溯起来就麻烦了。

    4、培养一个Swing的高手代价和培养一个js高手的代价比。写个Swing控件和写个JS组件的代价比。

    5、XML编制/解析，浪费了我的CPU.考验客户的信心。

    6、安全，java总比js这种解释性语言强吧
  
不过，web也有其不可替代位置，对于系统的外部用户，这个thick Client还不是很现实的。



增加名词注解：
   C/S 我不讲了
  
有了b/s结构后，随着应用的深入，浏览器这种request/response的方式比较不爽，刷新过于频繁，界面操作性不强，报表麻烦等等。有人又怀念c/s时代的丰富客户端（rich Client），但又希望拥有B/S（又一说是所谓的三层结构）的优点。
  后来发展出一些新的技术出来，当然，远程调用技术我就不详谈了。这里主要说客户端技术。 rich client客户端技术主要分流为thin client和thick client，只是有时候他们界限并不明显。

  thin client技术的主要以XUL,XAML为代表，也就是利用xml标签描述桌面应用程序的界面，但几乎所有的主要计算工作在服务端（我们叫他应用服务器）完成。这时候，客户端是纤细的，只需要支持XUL或者xaml这两种语言的浏览器。只不过，这界面用起来和c/s程序下的差别不大。 目前上述两种技术都很不完善，还不具备应用开发的大环境。

  thick Client则不同，客户端需要有自己一套程序在跑着，界面逻辑的计算量全部在客户端。就好像c/s程序一样，只是c/s连接的是数据库，thick client连接的是远程应用服务器。这种技术先是开发中用的已经比较多了，只是标准林立。

  类似httpxml这种框架不能分为其中一种类型，他利用了js做了一些rich client工作的技术，他的出现跟rich client本身技术成熟度不够有一定的原因，可以这么说，他是特殊时代的特殊产物。我个人认为，这种技术出生之时，就注定了离消亡不久矣。

  之所以有现在这样的结果，是因为Rich Client标准众多，门派林立，各家由各家的做法，没有形成一定的标准，而且本身又有些技术方面的缺陷或者难题。

  但2005年，第一届Rich client大会将在美国召开，我们期待能有所突破。

 

转自http://www.iteye.com/topic/10214