jiming

写代码的简要规范（必须要遵守）

jiming — Wed, 25 Jun 2008 12:36:02 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/207814 发表时间: 2008年06月25日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

1. 每个函数的行数不得超过显示器的一屏幕的高度，如果有这样的情况的话就应该分成多个函数
2. 要注意多使用 namespace 的方式，尤其是 javascript 代码，以避免变量名冲突
比如：g_aaa, g_module1_aaa, c_max_name_len, c_module1_max_name_len ....
3. 注释，一定要加，要按照 javadoc 的标准格式，不要自己随意定制格式
4. 因为已经有了版本控制系统，所以提交时要把注释的老的代码删除掉，以避免代码混乱难于维护
5. java 代码中不允许出现 magic number, 需要的地方要定义常量
7. 提交代码前一定要自己 review 一下自己的代码，不允许把不应该提交的内容提交到版本控制系统中
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

值得分享的客服信[转载]

jiming — Tue, 03 Jun 2008 20:10:30 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/199852 发表时间: 2008年06月03日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

值得分享的客服信
作者：virushuo 发表于 2008-06-03 11:06 最后更新于 2008-06-03 11:06
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。
http://blog.devep.net/virushuo/2008/06/03/idc_letter.html

前几天blog访问不了了。询问机房，得到了这么个很强的邮件。这个邮件写的真是跌宕起伏。让人看了确实不生气，还很同情他们。我觉得实在值得分享一下。

其要点有几个：
1 承认错误：事故确实发生了。
2 先说坏消息：机房起火爆炸了！
3 然后说好消息：你的数据还在！
4 再来说坏消息：但是暂时还恢复不了。
5 最后说解决方案：我们努力中。

一气呵成。高手！

Dear Customer,

Last night around 5 p.m. (Central Time) there was an electrical shortcut in the facility where our servers are stored, thus creating a fire and an explosion that damaged part of our equipment. While no hosting servers were damaged, and all data are safe and preserved, as far as we were able to determine at this point, a part of electrical generators were heavily damaged, and some of our servers were cut off the network and shut down.
Unfortunately, our DNS servers were affected and went down, so our whole network was partially inaccessible. At this point we have moved our DNS servers to the working part of our network and all servers that are not affected by this impact should become accessible in the next several hours (if not already), as soon as DNS update propagates around the web. Unfortunately, two servers from our network will remain inacessible even after this time line, until electrical damage gets repaired and destroyed equipment gets replaced.
It is hard to say when this whole process is going to be finished, so we can not predict the estimated time to repair everything, but let me insure you that our staff members are working around the clock on resolving this situation.
I apologize for this inconvenience and thank you for your patience. We are doing everything we can to remedy this problem as quickly as possible.

Regards,
Delta Web Hosting
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

加密 web 程序的方案[有偿，请报价]

jiming — Mon, 26 Nov 2007 14:36:41 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/143689 发表时间: 2007年11月26日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我们的系统是 Spring+iBatis 的方案，数据库是 oracle。操作系统是 linux 或者 unix

客户要求我们把我们的系统部署到他们的服务器上，这个服务器和数据库都由他们来管理。

对于我们来说，我们的数据是非常宝贵的，不希望客户能够直接通过连接数据库的方式大批量的获取。当然，我们的程序也有很多我们的心血，所以也希望能够保护起来。

请问在这种情况下我们有什么方法可以保护我们的数据和程序呢？

商业方案也可以。

谢谢了！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

电影《奔腾年代》

jiming — Sun, 09 Sep 2007 16:25:19 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/122413 发表时间: 2007年09月09日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

本来以为是关于汽车的，看完之后感觉不错，以后再看一遍

应该允许别人犯错误，改了就好
要有不屈不挠的精神，屡败屡战
要懂得感恩，比如老板给的机会，当然是老板有人情味的情况下

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

flash 在 ie 激活问题的解决方案

jiming — Sun, 02 Sep 2007 16:34:13 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/119497 发表时间: 2007年09月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

使用的方式调用外部的JS文件，在JS文件中用使用docuemnt.write写...。

注意：直接在页面上使用docuemnt.write写入是不能饶开激活限制的。

本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

iptables 的不错的文章

jiming — Fri, 31 Aug 2007 19:48:00 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/117562 发表时间: 2007年08月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

[转贴]国外一大二学生的小组作业

jiming — Fri, 31 Aug 2007 19:48:00 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/118947 发表时间: 2007年08月31日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

------------------ 这是这位朋友本周要做的任务 ----------------
- 2.5 Assumptions and Dependencies.
What do you assume the client to do/act/want, and what you depend on
to produce a final result. Its design phases for everyone.

---------------------- 以下是原题目 ---------------------------
Dominion Pizza Store
• Objectives:
o Dominion Pizza Store (DPS) is planning an information system for
their services. A customer may make an order through the Internet /
Phone / in-person. The order may include several products. There are a
few basic sorts of pizzas, which can be complemented with different
toppings. The assortment and the toppings change from time to time, as
do their prices. In addition to pizzas, other products are on offer.
They are divided into product groups. There is a textual description
of every product, and a picture of some of them, which the client may
see when ordering through the WWW.
o A bill will accompany each delivery. The price will be discounted
according to time, if the delivery is late; for example, 45-minute
delivery or FREE. The price of a product may, also, differ according
to the time of day, for example. The time and place of delivery is set
when the customer makes the order.
o For an online / phone order, the customer is identified by his/her
telephone number, or other contact information. A delivery status time
stamp (i.e. to kitchen, to delivery, and to customer) is registered
for each delivery. The client may cancel or change the order only if
the order has not gone to the kitchen. For an online/phone order,
customer's information is checked in the database for an existing, or
new client. If the client is new then take and store contact details.
For an existing client (or address), past history will be checked for
any problems.

• Main Modules:
1. Client Interface
 Browsing the Products, and their Prices
 Making an order
 Delivery time stamping
2. Agent Interface (Phone / in-person orders)
 Entering Agent Info (e.g. ID)
 Browsing the Products, and their Prices
 Delivery time stamping
 Checking past history (for any problems, and/or past frequent
orders for either quick order taking or special offers)
3. Inventory Management
 Food supplies
 Misc. supplies (e.g. Cleaning)
 Entering and maintaining product information (inc. pricing)
in the database
4. Finances Management
 Account Receivables
 Account Payables
5. Delivery Management
 Order Status (i.e. to kitchen - when, to delivery - when)
 Special offers (e.g. late order, new product introduction)
 Printing an order list - for kitchen (?)
 Printing a receipt
6. Payroll
 Employee Information (e.g. Contact Info, Salary Info,
Bonuses, Taxes, GST/PST)
 Hiring / Firing / Training etc.
7. Anything you may suggest (will be considered towards the Bonus
Marks for the best project, if above modules done reasonably well
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

[转贴]八大优势能否助JSF统一Web开发

jiming — Thu, 15 Feb 2007 15:42:11 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/54582 发表时间: 2007年02月15日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

作者:Simon 来源:IT168

JSF掀起你的盖头来

JSF为什么会受到如此大的青睐，IBM，orcale，包括国内领先的中间件厂商金蝶也投以关注目光。那么它又具有哪些与众不同的优势吸引众商家投怀送抱呢？下面我们就来揭开JSF的神秘面纱。

JSF英文全称 JavaServer Faces (JSF) 是一种用于构建 Web 应用程序的新标准 Java 框架。它提供了一种以组件为中心来开发 Java Web 用户界面的方法，从而简化开发，也是Sun精心打造的一项技术。

JSF优势之一：UI组件（UI-component）

UI组件（UI-component）一直是桌面程序的专利，web程序中，虽然HTML定义了基本的UI标签，但要使这些UI标签像UI 组件那样工作，还需要很多代码片断来处理数据及其表现形式，而且有效地组织这些代码片断使其协调一致也是一件繁琐的工作。JSF的UI组件是真正意义上的 UI组件，能极大地简化程序员的工作，例如，在页面上放置一个文本输入框，这个输入框立即具备了数据填充、界面更新、事件侦听、动作触发、有效性检查和类型转换的功能。更为重要的是，程序员只需根据业务逻辑编写核心业务代码，JSF会保证代码在合适的时候被执行，完全不用考虑代码与代码之间该如何来配合。

JSF优势之二：事件驱动模式

事件是面向对象方法的重要组成部分，对象之间通过事件进行沟通和交流，使得一个或多个对象能够对另一个对象的行为作出响应，共同合作去完成一项业务逻辑。通常，编写Web程序时，程序员要为对象之间的沟通设计机制，编写代码。虽然沟通的内容属于业务逻辑，但沟通的机制显然与业务没有太大关系，程序员因此为业务逻辑之外的功能浪费了时间。

JSF改变了这种状况。JSF的事件和侦听模式与大家熟悉的Javabean的事件模式类似，有Java基础的程序员并不需要学习任何新的东西。JSF的UI组件可以产生事件，例如，当页面上一个文本输入框的内容被修改时，会发出一个“值改变事件”。另一个对象如果对“值改变事件”感兴趣，只需注册为该对象的侦听者，并编写处理例程，即可命令JSF在事件发生时自动调用处理例程。JSF做了所有该做的事，留给程序员的只有业务逻辑代码的编写。

JSF优势之三：用户界面到业务逻辑的直接映射

举个例子，表单提交是Web编程最常见的任务，也是最复杂的任务之一。当用户在网页上点击“确定”按钮时，浏览器将生成一个HTTP请求，发往服务器端的某个Servlet，执行该Servlet的service方法。在service方法中，HTTP请求需要经历解码、类型转换、有效性验证、状态保存、数据更新等环节，处理这些环节的所有细节，对程序员来说是沉重的负担。

在JSF下，这些工作的很大一部分都由框架承担了，在程序员看来，这个过程是透明的，用户界面端的HTTP请求可以直接映射到后端的一个事件处理例程，JSF起到了承前启后的作用。

JSF优势之四：程序员和网页设计人员的分工

在JSP中，程序员和网页设计人员的工作有时候是互相交织、无法区分的。这是因为JSP页面中掺入了网页设计人员所不熟悉的一些JSP标签，甚至是晦涩的Java代码。要求网页设计人员理解这些标签和代码是不现实的，不符合分工合作的原则。在JSF中，框架为网页设计人员提供了一套标准的 UI组件，在工具的支持下，可以通过拖放简单地添加到网页上，然后设置某些显示属性来满足视觉要求。

网页设计人员不需要知道UI组件背后的复杂代码，那是程序员的事，而程序员也不需要再处理任何与视觉相关的细节，程序员所做的只是给 UI组件绑定类的属性或方法。虽然程序员和网页设计人员需要修改同一份文件，但他们各司其职，各得其所，互不干扰。程序员和网页设计人员工作的明确划分，是JSF在易用性方面迈出的一大步。

JSF优势之五：请求处理生命周期的多阶段划分

虽然都是建立在Servlet基础之上，但JSF的生命周期要比JSP复杂得多。JSP的生命周期非常简单，页面被执行时，HTML标记立即被生成了，生命周期随即结束。而一个完整的JSF请求-处理生命周期被精心规划为6个阶段，典型的JSF请求需要经历所有阶段，某些特殊的请求也可以跳过一些阶段。阶段的细分，显然引入了更多的处理，但JSF框架会管理这一切，所以，程序员在获得更多控制能力的同时，工作量并没有增加。

JSF优势之六：伴随工具而生存

JSF带来了Web编程的巨大变革，变革的强烈程度超出了很多工具厂商的预料，以至于现在可供JSF使用的工具非常缺乏。缺乏工具支持的 JSF只会令人敬而远之，因此，JSF在设计之初就为工具厂商预留了用武之地。在为数不多的JSF工具中，sun的Java Studio Creator是一个优秀的开发环境；Borland的Jbuilder在JSF1.1时曾经是非常好用的开发工具。

可惜现在对JSF1.2的支持没有跟上；Eclipse下JSF的插件很多，但真正支持所见即所得的JSF插件都是收费的，例如Bea 的Workshop for JSF、Exadel的JSF Studio等等；此外，Oracle和IBM也有JSF的开发工具。随着工具的不断涌现，用JSF开发Web程序将会越来越方便和快速。

JSF优势之七：全面的用户自定义支持

前面提到，JSF将极大地简化Web程序的开发，作为一个相对复杂的框架，JSF是如何做到这点的呢？原来JSF为程序员提供了很多默认的组件和类，通常情况下，JSF的这些默认组件和类足以满足Web开发的需要了。但是，考虑到在某些应用场合，框架的默认行为也许不符合业务的要求，JSF 特别允许程序员编写自己的组件和类，来满足客户的特殊需求。例如，程序员可以编写自己的UI组件，甚至可以创建自己的EL解释器，来支持非标准的EL表达语言。

JSF优势之八：Web开发的官方标准之一

JSF的1.0版本发布于2004年2月份，当时是作为一项独立的Web技术推出的。经过1.1版到现在最新的1.2版，短短的两年多时间，JSF 终于在2006年年中成为Java EE 5的组成部分，上升为Web开发的官方标准之一。Java EE 5最重要的使命就是简化Java的开发，而JSF无疑为这一使命立下了汗马功劳。在Web框架层出不穷甚至有些泛滥成灾的今天，Sun以JSF来树立标准，对Java的发展是有益的。Sun在Java领域的领袖地位不容动摇，对于Java程序员来说，始终追随业界领袖的步伐，也许是避免技术落伍的最好方法。

JSF能否统一Web开发模式

在J2EE下一代规范Java EE5.0中，JSF技术被放到了一个非常重要的地位，J2EE社区试图通过JSF来统一Web应用的开模式与方法，但是JSF能否担起Sun所赋予的重任？实现Web开发的统一？

很多开发人士都对JSF不抱乐观的态度，用过JSF的人都称JSF是Web开发世界的创举， JSF可谓墙里开花，墙外不红，是什么原因的造成如此大的反差呢？

1.获取方式

书是我们获取知识第一来源，一种技术的火爆程度，我们不用在网上去做任何调查，只要去一下图书城结果就一目了然，关于JSF的书籍简直是凤毛麟角，难觅终影，这样在人们在获取JSF相关资料，JSF会大打折扣，比较经典《JSF in Action》国内还没哪家出版社有翻译动向，证明图书厂商还没有对JSF投入太多关注度。

2．中文讨论区成熟度不够

除了图书方面，讨论区的热度也很重要，打开JSF官方讨论区，对JSF大唱赞歌人大有人在，为什么国内这种讨论却少之又少呢？一些国内比较知名的讨论区中没有看到JSF的相关技术讨论，这样从影响度上从知识的渴求度上，都限制了JSF前进脚步。

3．Sun商业策略

Sun的商业运作模式一直存在问题，我们在之前曾经预言过如果JSF不叫JSF，而叫JSP3.0那么现在结果会如何呢？Sun可以不费一兵一卒从而实现JSP到JSF的合理过渡，同时也会有大批的JSP狂热者迅速的转向JSF，也可能有些人会认为两者是不同的两种技术，但是谁又能说Asp 和Asp.net是两种相同的技术吗？同样的策略微软用的很成功，难道Sun没有想到吗？

4．开发工具的支持程度

这次采访袁总的时候，也提到了JSF依赖开发工具的支持，Sun，IBM，Orcale都提出了对JSF开发工具的支持，但是这些开发工具在简化开发方面是否做足了功课，宠大、全面、无所不能一直是众厂商炫耀技术的舞台，这次Apusic Studio提出了简化，易用两方面特性，这点从程序员角度出发的开发工具，我们还是值得期待的。

5．扩大影响力

每一种技术都要有忠实狂热者，同时要让更多人的来应用和学习，Struts成功就是很好例证，一位著名IT人士曾经说过，“即使公司发生惨绝人寰的人事大变动，产品经理也不必过于惊惶失措，茫茫人海中，有大批的Struts们可供选择，只需好好考虑好新员工的业务培训如何开展即可，而对于技术延续性,则不必太过于担心,这就是Struts 带来的战略性优势。

也是Struts在今天技术落后的情况还能一直保持领先地位，这点还是值得反思的，JSF如何在影响上扩大学习者的基层人群，打消企业的后顾之忧，影响高层对JSF企业框架的应用选择，不知JSF是否做好了准备。

综上所述只是个人观点，如果JSF能在影响力和扩大人层基数上突破瓶颈，那么统一Web开发的格局将指日可待。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

Re: 讨论一下 cache 应该放在 service 层还是 dao 层吧

jiming — Thu, 08 Feb 2007 15:54:07 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/53226 发表时间: 2007年02月08日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

Cache 这个东西，看似简单，但是具体实施起来却是很麻烦，有许多方面的因素需要考虑，很多实施不好的 cache 会成为系统故障和维护噩梦的重要源头。所以我的原则是，只在一个层面上提供 cache 功能，其它的层面都不提供，以避免其复杂性并且降低耦合性。就像各位所讲到的那样，cache 包括很多层面，而且会有一些特殊情况，这些应改需要根据具体情况具体分析了。[color=blue]这里我主要想讨论一下我们大多数情况下用到的的 cache 方案。[/color][color=orange]页面 cache 也很重要，不过不再这里讨论了。[/color] Allen 说： [quote] 首先，你所说的cache应该指的就是对象的缓存，确切地说应该是持久化对象的缓存。那么这个“service 层的object cache”肯定得由你们自己来写了，我想这很难保证你们的cache使用效果会比底层下面“不是很完善的”hibernate 和 iBatis 提供的cache更好看。 [/quote] 这个说的非常对，实现自己的缓存方案比较麻烦一点，但并不是非常困难的事情，而且一个方案定下来之后可以不断地重用。 Allen 说： [quote] 再者，你们怎么保证“service 层的object cache”可以完好地与各不相同的“其它 dao 的技术方案”匹配上呢？而且又用什么机制保证“service 层的object cache”和数据库是同步的呢？直接连DB来获得更新了的碎片？或者专门写一些DAO层的接口，通过各自的实现来搞？ [/quote] 我的想法是 DAO 只做 DAO 的工作，对开发应用的程序员提供的接口只有 service，不允许直接操作 DAO。这样应该就可以实现了。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

讨论一下 cache 应该放在 service 层还是 dao 层吧

jiming — Wed, 07 Feb 2007 18:44:26 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/52994 发表时间: 2007年02月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

我个人倾向于放在 service 层。

因为虽然 hibernate 和 iBatis 都提供了 cache 机制，但是他们提供的方式都不是很完善。而且还有可能会使用其它 dao 的技术方案。所以放在 service 层应该更好一些。

注： cache 话题很大，我们只讨论 business layer 的 cache 问题，即 service 和 DAO。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

发现一个非常优秀的 JSF 包，icefaces

jiming — Tue, 06 Feb 2007 18:22:01 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/52616 发表时间: 2007年02月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

http://www.icefaces.org/

效果相当漂亮。大家可以去看看。

还支持 ajax
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

高薪招聘兼职系统架构师

jiming — Sun, 04 Feb 2007 23:31:14 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/52206 发表时间: 2007年02月04日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

职责：
. 周末能够抽出 1 - 2 天的时间
. 对需求进行分析，选择设计合适的系统架构
. 进行 code review
. 对软件工程师进行培训
. 对技术难题进行攻关

要求：
. 5年以上工作经验，至少3年以上J2EE平台商业或企业产品架构设计经验
. 精通J2EE相关技术，如Servlet、EJB、JMS、JNDI、XML、Web Service等
. 对 XP 有比较深的理解，尤其是 TDD
. 熟悉Spring、JSF/Struts、Hibernate/iBatis等架构
. 熟悉数据库设计，熟悉Informix、Oracle、DB2、SQL Server等主流数据库产品
. 熟悉应用服务器产品，如Bea WebLogic、IBM WebSphere等
. 精通面向对象分析设计，UML建模，熟悉PowerDesigner或RationalRose等一种或多种工具
. 对 Ajax 及用户界面有深入的了解
. 良好的技术文档撰写能力和沟通能力
. 良好的沟通能力与团队合作精神
. 具有大型软件开发经验者优先考虑

请发送简历到： mail4jiming-job@yahoo.com.cn
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

我为什么选择 iBatis 而不是 Hibernate(对于正在选型的人的建议)

jiming — Sat, 30 Dec 2006 15:18:22 +0800

作者: jiming 链接：http://jiming.javaeye.com/blog/41720 发表时间: 2006年12月30日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

[注意]清在回复之前认真地看一下我的帖子，结合你的实际项目经验考虑一下，看看你是否能比较好地解决我所提出的Hibernate 的缺点。最好不要提一些大家都知道的泛泛的观点，这样会很浪费读者的时间并且分散大家的注意力。

非常感谢有几位对 hibernate 有深入了解的朋友给出了我这里提出的问题的 hibernate 解决方案。我提出这几个问题的初衷不是说 hibernate 无法实现这些功能。而是说他的实现比较不美，呵呵。比如说把一些 sql 嵌入到 java 代码中，我觉得这是非常不好的习惯。

v0.3 - 2007-1-1 21：1：1

我在最初的选型的时候是打算选择 Hibernate 的，在研究的过程中发现了 iBatis，经过
分析比较之后我选择了 iBatis。现在我已经使用 iBatis 完成了一个中小型的项目。这个
项目在性能、可维护性、可扩展性方面都非常令我满意。

在这个过程中我也不断的与使用过或者正在使用 Hibernate 的人进行过探讨。而且我本身
也在不断的跟进 Hibernate 的发展。

最终，我的结论是 iBatis 的选择非常正确，而且越用越喜欢它了。

当然了，我对 Hibernate 的理解还是非常有限的，所以这里的关于 Hibernate 的一些观
点的错误之处希望能够得到 Hibernate 高手的指正。

1. iBatis 易于掌握。拿来文档看半天到两天就可以掌握了。
Hibernate 可能需要 3 倍以上的时间来掌握。

2. iBatis 更容易进行 sql 的优化。

这个应该大家都有共识了。另外 Hibernate 生成的 sql 也实在是太难看了。鉴
于有的朋友提到了 sql 不太重要。我想在这里强调一下我的经验，一般系统性能
的瓶颈都在数据库上。所以这一点是 iBatis 非常重要的一个优势。

3. iBatis 可以进行细粒度的优化

3.1 比如说我有一个表，这个表有几个或者几十个字段，我需要更新其中
的一个字段，iBatis 很简单，执行一个sql
UPDATE TABLE_A SET column_1=#column_1# WHERE id=#id#
但是用 Hibernate 的话就比较麻烦了,缺省的情况下 hibernate 会更新所有字段。
当然我记得 hibernate 有一个选项可以控制只保存修改过的字段，但是我不太确
定这个功能的负面效果。

3.2 我需要列出一个表的部分内容，用 iBatis 的时候，这里面的好处是可以少从数据
库读很多数据，节省流量
SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE ...

3.2.1 一般情况下
Hibernate 会把所有的字段都选出来。比如说有一个上面表有8个字段，
其中有一两个比较大的字段，varchar(255)/text。上面的场景中我为什么要把他
们也选出来呢？

3.2.2 用 hibernate 的话，你又不能把这两个不需要的字段设置为 lazy load，因
为还有很多地方需要一次把整个 domain object 加载出来。这个时候就能显现出
ibatis 的好处了

3.2.3 Hibernate 还有一个方案，就是生成 javabean/map/object[](感谢
leelun/cjmm)，但是这样的话就可能会产生大量的多余 class。map/object[] 的方式
应该不错，我比较喜欢这种方式。

3.3 如果我需要更新一条记录（一个对象），如果使用 hibernate，需要现把对
象 select 出来，然后再做 update。这对数据库来说就是两条 sql。而 iBatis
只需要一条 update 的 sql 就可以了。减少一次与数据库的交互，对于性能的
提升是非常重要。

4. 开发方面
4.1 开发效率上，我觉得两者应该差不多
4.2 可维护性方面，我觉得 iBatis 更好一些。因为 iBatis 的 sql 都保存到
单独的文件中。而 Hibernate 在有些情况下可能会在 java 代码中保存
sql/hql。

5. 运行效率
5.1 在不考虑 cache 的情况下，iBatis 应该会比hibernate 快一些或者很多
（根据实际情况会有所不同）。

当然 iBatis 也有比较大的缺点
1. 不同数据库类型的支持不好，如果你要开发的系统是要在对中数据间移植，那可能用 hibernate 比较好。
2. 缺省的 cache 支持不好，但是 hibernate 的 cache 支持其实也不是很好，而且很复杂。尤其是对于大并发量的应用。所以我更倾向于自己管理 cache。

非常感谢这么多朋友对这个话题很感兴趣。但是我感觉大家并没有对我第三部分提到的问题进行更深入的思考。我晚些时候会提交一些 ibatis 的代码。欢迎大家一起来讨论。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐