fireflyc 针对Nutz1.a.15 提的意见

Nutz1.a.15发布两个月以来，反响不错，更值得欣慰的是，提意见帮助Nutz的盆友很多很多，借此转载一篇新近由 fireflyc 发表的意见（据说zozoh在看到意见之后甚为欣慰，当即表示感谢热心人士的意见，欢迎大家更多地表达，尽情的抨击）：

 

 

 

仔细阅读了一下源代码，单纯的几个技术观点：

1.数据库的封装。这里的封装我觉得太薄太脆弱。和hibernate比起来根本没有办法比，hibernate的HQL是一种语法分析的推导。而这里只有SQL，虽然简单但是意味着耦合。对sql的执行我看到SqlMaker这样写道
"INSERT INTO %s (%s,%s) VALUES(@%s,@%s)"
也就是说，所谓的封装是对字符串的一种封装。把SQL的各个部分进行拼装。这种做法我不觉得有什么地方好，反而不如直接写sql，不做任何封装的好。这里估计是想要模仿什么，同样的道理注解的加入也是想要模仿什么。或许模仿的那个不合适这里的设计哲学。作者的设计哲学应该是输入sql，输出对象（或map）。那么很显然，作者如果能忍痛割爱把那些违反这个哲学的“对某些东西的模仿”剔除掉，那么这个东西会更加简洁明确。(我只是推测作者的设计哲学，可能有偏差。呵呵。。莫气)

 

2.对controller的封装，我觉的也是想在模仿什么，头部的那些注解暗示着返回的状态和输入的url都是由配置决定的，或者说是写死在代码里面的（我的哲学是，注解=代码而非配置）。我不知道这些注解和直接写死在代码里面有什么区别。两者都需要重新比编译。我还没有找到数据绑定相关的内容，难道直接使用request？这个我喜欢，但是问题是应该有一些工具类给我方便把request绑定到对象上才行。否则如果属性多无聊的代码也就多了。

 

3.代码整体结构有点out了。试举两例：
在日志的org.nutz.log.file.FileWriterPool中，26行getWriter方法，作者把打开的Writer放到一个HashMap里面，然后在getWriter的时候为了保证线程安全有如下代码段

Writer w = writers.get(file.getAbsolutePath());   
if (null == w)   
    synchronized (this) {   
        w = writers.get(file.getAbsolutePath());   
        if (null == w) {   
            try {   
                w = new BufferedWriter(new FileWriter(file, true));   
                writers.put(file.getAbsolutePath(), w);   
            } catch (IOException e) {   
                throw Lang.wrapThrow(e);   
            }   
        }   
    }   
return w;  

  Writer w = writers.get(file.getAbsolutePath());
  if (null == w)
   synchronized (this) {
    w = writers.get(file.getAbsolutePath());
    if (null == w) {
     try {
      w = new BufferedWriter(new FileWriter(file, true));
      writers.put(file.getAbsolutePath(), w);
     } catch (IOException e) {
      throw Lang.wrapThrow(e);
     }
    }
   }
  return w;

 

synchronized这个锁，太大了，java早已经在jdk5的时候重写了所有的并发相关的内容，引入了Lock类。
再看这里是否有必要自己来加锁？打开java.lang.concurrent包，引入眼帘的是ConcurrentHashMap类。应该猜到是干什么了的吧？

 

4.作者太偏执，作者的偏执体现在不引用任何除jdk以外的第三方包，也许是对混乱的jar愤怒到了极点。但是这种做法意味着你将与开源世界完全脱离，你重新制作一切，不利用社区的任何帮助。这是一种浪费，我觉得和开源哲学背离（个人观点中的开源哲学）

 

5.整个框架的封装说不上好用，有些东西明明是两样背离的东西却被试图封装在一起。与其破坏一个东西，不如去修改一个东西。我们的框架被我偷梁换柱替换几乎把struts1架空了，把hibernate限制的几乎只有HQL了，甚至把事务变成了手工的，把spring和guice都做了一层封装，但是我没有再去考虑自己重写这一切，因为我曾经这样尝试过，最后发现远不如修改来的直接和巧妙。至少它还是struts、hiberate、spring之类的。

评论

7 楼 zozoh 2009-11-26  

@fireflyc, 看了你的回复，我写了一篇文章：
http://zozoh.iteye.com/admin/blogs/526494

另，如果你感兴趣，在你的博客上贴出一些你眼中的 Nutz 脑残的设计，尤其是和现有的其他框架的对比的不足之处。我们会不胜荣幸。

同时也欢迎加入 Nutzam 社区，
你在这里可以不止讨论 Nutz 框架，实际上我们讨论的是 “如何最大限度的提高程序员的生产力”。

6 楼 fireflyc 2009-11-24  

呵呵，谢谢作者对我评论的容忍。其实我觉得可能更多的是一种对同一个问题的不同设计理念引起的。这里我先表示一下我的设计理念。
1. 我理想中的东西是一个实践性框架，所谓的实践性是指不以语言，环境等等因素为限制。一种思想上的“复用”。“复用”的对象是一种web开发的最佳实践。
2. 我个人认为去限制一个框架好过去重新设计一切。因为我曾经试图重写过很多东西，从最开始有自己的一点点想法，然后去写代码；之后我会发现在另一方面我有时候欠佳考虑于是乎重新设计。有时候还会碰到各种疑难杂症，带着郁闷我会阅读各种代码，大部分是我不满意的那些框架的各种代码。后来我对自己不满意的东西更多的是有一种敬意。这是从技术上来说，自己做的一切重复劳动不一定比先人高明。再一点从管理角度来说，你告诉对方这是struts，然后给对方说，formbean我们不提倡，配置文件不需要配置，你只需要如此这般即可。对方会很乐意接受。如果你告诉对方，这个是一个新的框架，你这样这样使用，对方更多的是把这个看成新东西，心理作用让他感到不安，感到为难，感到抵触。有个关于我自己的插曲，我还在读大三就要写一个叫做flyweb的东西，是一个web框架，主要是对struts2的不满而产生的想法，代码很快写好了。我用它做了毕业设计，随着时间的增加，代码被我修改了，被我完全推倒重来了，名字被我换了，我有更多的想法，我疯狂的翻阅着各种框架的设计，阅读他们的代码。后来我不再局限java，我跳出java去看php的框架去看python的框架。再后来我想设计一套可以很方便提高工作效率的整体性的东西；鬼使神差我没有走写“大框架”的路。而是开始去翻阅各种cms和protal。我迫切希望给开发提高效率。直到去年我终于沉静我总结出自己这些年瞎折腾的东西无非是两样：a,一个开发框架，注重实用。b,一个由各种通用模块组成的基础性framework。前者是后者的基础，后者的复用面积更加有效。比如权限管理，日志监控，菜单管理，一套通用UI。诸如此类。这些东西对于一个企业应用来说非常实际。

开始我很喜欢springside，后来感觉小白对某些问题的看法和我不同，于是我开始自己做一些事情。
总的来说我提倡对传统架构做如下调整：
1.有一套通用的工程目录结构，这个目录结构包括spring配置信息，通用的jsp头，通用的jsp错误页面，web.xml配置诸如此类。这个存在的目的是为了方便开始一个项目。避免每次都重新搭建目录结构（或者修改以前的项目目录结构）这样jar包几乎是固定的了。我不喜欢maven因为我难以理解它。。太复杂了。。呵呵
2.对struts来说取消formbean，因为它是一种空壳对象，会让开发人员产生厌烦。这就带来数据校验的问题和数据绑定的问题，数据绑定我们可以提供一个方法来方便request到model的绑定。但是数据校验，我想不出什么好办法。每次都是大家手工做校验，或者干脆就只有客户端校验。struts的配置是0，每次新建一个action，我只需要在spring的配置里面加上action的配置信息就可以完成了。这样就避免了重复配置。还有struts的页面渲染没有采用任何配置，是以一种约定进行的。
3.spring的配置文件是被分来的，是随着目录结构被引入的。所以无需做过多考虑。只需要提供一些通用的组件即可。比如执行时间的拦截。还有就是取消DAO，引入一个通用DAO，提供各种工具方法。只保留service对象。service对象以领域对象的形式存在。
4.hibernate。引入注解，注解应该被加载字段上而不是getter、setter上。注解应该尽可能的不多写，一切尽量保持默认。取消多对多关系，只有一对多和一对一关系；宁可引入中间对象。所有查询尽量使用HQL，如果是关联对象，不要像对象的set放入数据。 总之把它当做高级的SQL用。
5.代码生成工具的集成。
可能这些比较粗和大家的思想也不一样，因为我对改变复杂的问题的思路源于我自己的一些不断探索。
根据这些我设计了一套框架在我们公司内部使用，先后用于某电信和酒店合作项目，某市电信电子账单项目等。之后由于觉得公司的一些东西过于保守而在离职之后重写了所有的代码。代码量不多，因为我是在修改某些东西；我宁愿把struts架空也不愿替换它。我一直不愿意公开它，只是在我们几个好朋友之间流传。而且最近一个项目让我觉得有必要把事务修改成手工的还有一些其他想法。

以上是我对“解决开发难”的问题一些总结和看法。或许是这些看法不同导致了每个人对待某个问题的看法都不同。

5 楼 zozoh 2009-11-24  

唉，不过话说回来， Nutz 对于直接书写 Sql 支持的也不错啊。
这个功能好像从来没人关心的样子 

http://code.google.com/p/nutz/wiki/customized_sql

4 楼 hilliate 2009-11-24  

zozoh 写道

对于第一点： 输入 SQL ？ 让我自己拼装 SQL？ 老拼装 UPDATE XXX，用起来很不方便吧。

采用注解，是因为没有更好的方式了，它比配置文件更方便。

我觉得Nutz期望Dao的操作更加对象化，自己拼写sql语句不是不好，只是说在更加对象化的目标下，不太符合目标。

整体上来说，我没觉得有什么模仿哪个框架，我觉得大家只是用了相同的概念，既然用这些概念，看起来是会有些相似，应该说很正常吧。

3 楼 zozoh 2009-11-23  

对于第一点： 输入 SQL ？ 让我自己拼装 SQL？ 老拼装 UPDATE XXX，用起来很不方便吧。

采用注解，是因为没有更好的方式了，它比配置文件更方便。

2 楼 birdwindy 2009-11-23  

1.对sql的封装的优点在与灵活性，就像ibatis就是对sql的封装， 但是过于灵活容易造成代码的混乱与不规范。我想nutz主要是想平衡着点吧。
2.其他的观点我觉得也很好，但由于技术所限，不多评论，现在nutz还处在测试阶段，欢迎各大牛人指点~~~

1 楼 zozoh 2009-11-23  

对于第四点，需要说明的是，Nutz 并不是要阻止使用者使用其他的 jar 包，它是想力图做到：

“不会因为你使用了 Nutz.jar，而不得不 copy 其他的 jar”

而已