写程序，做产品，过日子

@dudu
dudu老兄，什么时候可以让我从Blogjava向博客园其他的站点论坛发文呀？特别时.Net站点。我已经郁闷了很长时间了。

毋庸置疑，博客园是最好的IT博客站点之一。稳定，友好，有人气。但博客园各子站之间“老死不相往来”，现在已经成了制约我写博客的主要因素。
我的博客在BlogJava。但随着工作经验的积累，我也有很多.net，甚至管理方面的文章。这些文章，我却没法发表到相应的社区首页。
诚然，我可以多申请几个博客。但我的精力只够维护一个博客。多开的博客帐号，十有八九会成为垃圾博客。
因此，强烈建议博客园取消各子站之间的樊篱。

@GentleYang
印象嘛，就是工作当中碰到的一些事情和感受。
“在开源时代，几乎你能想到的别人也都想到了”这句话没错，但想到不等于做到。坦率的说，开源产品还有太多的东西没有做到，尤其是易用性方面。

用不了多久，估计你还是会换回金山词霸的。词典软件拼的是词汇量和易用性。对于现在标配内存1G的计算机来说，占几十M内存算什么啊。

今天被Spring的事务管理机制耍了，不得临时用用HibernateTemplate。一用才发现简单的查询被Spring搞复杂了，而且缺失了一些功能。
1，不支持分页。HibernateTemplate中有个fetch size，但没有first result。
2，传入命名参数时不是一个map，而是一个名称数组和一个值数组。
3，传入参数为null时有异常。

当然，解决办法很简单——写一个新类扩展HibernteTemplate。

此外，Spring参数文档中对HibernateTemplate的用法举例也有问题。在它的例子中，每个DAO类都有一个HiberanteTemplate属性，而不是每个DAO的方法自己创建一个新的HibernateTemplate实例。
这种做法的主要问题在于，HibernateTemplate中的一些设置，如fetch size, max results等，可能在调用者不知情的情况下，应用到后续查询中。

我现在更愿意把HibernateTemplate理解成Spring集成Hibernate的一个sample。想用就用，想改就改。

前段有新闻报道了，这不过只个炒作而已。没有科学性可言。

@netfishx
应当有往这个方向努力的目的，但还达不到。原因很简单，各个持久层的查询语言和模型不一致，比如HQO，SQL, JDOQL, JPQL, Criteria等等。Spring的Template虽然统一了API的方法名和参数个数，但其接收的参数本身仍是分裂的。

@dennis
老大高啊！一下子就找到我想要的解决办法了。俺马上就试试。

@aninggo
这么说主要好处是保证自动关闭session。这个的确很有用。
至于第二点，Jason想到的是方便用户从一种持久层技术切换到另一种。而在我们的产品中，持久层比较稳定，反倒是Spring，有可能被换掉。出发点不一样啊。

@aninggo
我想知道的是，和直接使用hiberate API相比，有什么好处？不用HiberateTemplate，同样能整合事务，而且一样简单。

何苦抱怨多多。

我用的是从sf下载的jar包。是只有一个Easy Explorer菜单的版本。楼主所说的增强特性，在这个版本中已经是这样了。

第一强烈支持。
第二友情提醒一下楼主，一定要想好这个产品的盈利模式。这是个大工程，需要很大的投入成本的。没有盈利，光凭干劲可不行。

@itspy
呵呵，innerHtml只是我举的一个例子而已。人家已经命好名的东西就按人家的来好了。不要太执着。

这两种标准都是存在的。其实也说不上是标准，两种最多人用的约定而已。随便选一种跟就可以。不过你得和你的团队一致。

我的习惯是：
* 文档中是以单词的形式出现，一定要全部大写：ID, HTML。
* 代码中是驼峰法命名的一个部分，应首字母大写：getId, innerHtml。
* 文件名中全部小写。

@Coffee and Tea
嘻嘻，我的想法就是想给Java加点儿动态特性。当然，前提是不影响性能。

应当没的解决吧。这是事务的规则之一。

@azure
我自己没研究过JSF和Tapstry，是同产品组的同事研究的。他专门做了一个JSF和Tapstry的选择验证。最后得出的主要结论之一就是JSF还不够成熟，UI组件(widget)不够多。所以我们最后选了草民。

@Juliashine
嘻嘻，不管什么O/R Mapping工具，好像都没有提倡OO式的表结构哟。O/R mapping这个名字中，R可是三分天下有其一的。如果真的想玩OO式的表，那就玩面向对象数据库得了。连O/R mapping都省了。

@harry
你提醒得对啊，俺早把外部工具忘到九霄云外去了。不过比较起来，还是右键菜单好使。

这些东东和XSLT相比，有些什么优势呢？

是啊，我们技术人员缺少的是单，但是不是什么单都可以接的。
众所周知，Java的长处在于B/S系统，在于跨平台。
在B/S上，在Windows上，怎么可能和Delphi, Visual Basic相提并论。
Java是长枪，Delphi是短剑，要做近身肉搏，显然不能用长枪。

@dennis
你的观点我是赞同的。即便Spring真的提供了这个功能，我们在使用时也会审慎的考较它：是真的节省开发成本了，还是增加开发成本了？
如果有限度的，谨慎的使用接口粘合特性，应当是节省开发成本的。如果大张旗鼓的用，那十有八九是增加成本。
我只是觉得对于我在文章中所举的案例，确是一个需要接口粘合机制的东东。

@fullqin
真是只有想不到，没有做不到。以前零星听闻过Hivemind的大名。有机会一定研究一把。

@dennis
Adapter模式仍然是用java类和接口来表达的，它没法完全消除开发时的依赖。

大哥，只能在包和文件夹的菜单上用啊？文件的菜单上怎么没有呢？
另，菜单太长，不好找，给它加个Windows图标吧。EasyExplorer这个插件就是这么干的而且还可以配置打开文件浏览器的命令。

哈哈，说得太对了，这么小功能，既繁琐又不得不用。

Dudu好年轻啊！

支持支持！建议再加几个功能：
1，用Windows文件浏览器打开当前目录。
2，复制当前文件/文件夹的全路径

另外，做java的人，一定要在注册表中加入一个Dos Here命令。下面是脚本：

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Folder\shell\Open_DOS_Box]
@="DOS Here"

[HKEY_CLASSES_ROOT\Folder\shell\Open_DOS_Box\command]
@=hex(2):43,00,4d,00,44,00,2e,00,45,00,58,00,45,00,20,00,2f,00,4b,00,20,00,43,\
00,44,00,20,00,25,00,31,00,00,00
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Folder\shell\Open_DOS_Box]
@="DOS Here"

[HKEY_CLASSES_ROOT\Folder\shell\Open_DOS_Box\command]
@=hex(2):43,00,4d,00,44,00,2e,00,45,00,58,00,45,00,20,00,2f,00,4b,00,20,00,43,\
00,44,00,20,00,25,00,31,00,00,00

没用过iBatis，所以不知道它对于动态SQL有多好。反正，基于不愿意为一个表做两套O/R Mapping和储备两种技术的目的，我没有在产品中引入iBatis。

是啊，我们现在的做法就是在Hibernate中写HQL和SQL，没有用iBatis。不过楼主的最佳实践中讲到“非事务性的查询及报表，都用Ibatis”。我有些纳闷：在已经使用了Hibernate的前提下，直接在Hibernate中写SQL，和在iBatis配置SQL，哪个更好呢？

我觉得高层管理者，比如说PM以上，深厚的技术背景并不是必须条件，很多情况下也不可能。对于高层管理者来说，他们的确是把自己的命运交付给PM的。只不过通常不会把所有的鸡蛋放在同一个篮子里。

我们不搞敏捷开发模式，但是在设计阶段做demo的确非常有价值。

(
最终的运用：

在基于Spring的容器事务管理之下，
增、删、改、存及在事务中的查询，使用Hibernate。
非事务性的查询及报表，都用Ibatis，维护非常的直观方便，开发速度上也快很多。
)

按楼主的这个做法，岂不是要同时掌握Hibernate和iBatis两门技术？同时为一个表写hibernate　mapping和ibatis sql?　这本身已经有很大的重复量了呢。

Maven和Ant在在部分功能上还是竞争的。Apache本身只是个基金组织，它可不管自己出钱开发的项目之间有没有竞争关系。

JSF的竞争对手是Tapstry，而不是struts。我们最后选的是Tapstry。原因很简单：够成熟，组件够多。页面的复杂度其实是一个系统中最让人头痛的。只是因为什么都是可视的，所以很少有设计者重视它。

数据量多也不明显。夏昕在《深入浅出Hibernate》中有介绍：Oracle就是这特性，得好的服务器配置才能体现其优点。

我只是在写文档时感觉会受打字速度的影响。编码时绝在部分时间是在思考，而不是打字。如果机械的打代码的时间太长，是不是应当考虑优化一下UML模型。

编码速度主要是受思维敏捷度的影响。

to m99c

对啊，WTP本身提供了XML的编辑器。刚刚试了一下，Myeclipse就是用的它。
前几天我测试时，用的是Eclipse 3.3 M6，WTP1.5.2和这个版本没法共同工作，使我误以为Eclipse没有XML编辑器。
今天用Myeclipse 3.2.2试了一下，确实是有的。

我不太懂Spring事务。但是楼主说的并行事务的例子是所有事务的共性。

忘了说了，我用的是Oracle 10g测的。它是支持batch处理的。

一到两个小时穿刺能搞定的问题，正式开发的工作量应当也就在一两天以内。这个范围内的评估价值并不大啊。

这么小的版本升级，的确不应当出现运行不了的错误。Spring有点草率了。

对各类UI组件的支持如何呢？比如dropdown, grid, list等等？

我们公司现在用Tapstry

除了二八理论，其余的就泛了。
1，只要一天保证一定的工作时间，没必要去深究刷牙这样的细节。
2，像我们做技术工作的，一天应当保证至少三个小时的不被打扰时间。

fyxruben提到JVM的安装。Windows XP和Vista不是都预装了Microsoft 的JVM吗？
此外，Java6中加入了很多的桌面特性。运用这些特性开发出来的界面与.net开发的可以不相上下，不过成本可能高出很多。
而且，不知道这些桌面特性是不是只针对Windows的。

如果盗版windows消失，受益最大的是微软，java我估计变化不大。因为盗版消失后，微软必然大幅降低正版Windows的价格，而其Home版本更有可能以极低价出售，甚至免费提供。
这些并不会影响微软的利润。首先它的销售量会剧增，要知道人的习惯可不是那么容易改变的。其次它可以利用Windows平台，从Office等产品上获以高额利润。

java7? 咱这里java 5才刚刚上线呢。这可不比应用软件，升级跟吃饭一样。估计要等两三年的。

POI不能支持图片啊