回复fireflyc：Nutz 的设计以及提高程序员生产力

@[url=http://fireflyc.iteye.com/]fireflyc[/url] 在 [url=http://xiaofeng.iteye.com/blog/523772]晓风的这篇博文[/url] 的回复，引起了我的一些思考，考虑到内容较多，就单独写成一篇博客吧：

-------------------下面是正文的分隔线-----------------------------------

那么我也聊一下 [url=http://nutz.googlecode.com]Nutz[/url] 这个框架的设计思想，或者叫做“精神”，或者随便怎么叫它。

[b][size=large]我希望 Nutz 是你一个乖巧的奴仆 [/size][/b]
[i]并且它不是你唯一的奴仆[/i]

[url=http://nutz.googlecode.com]Nutz[/url] 框架对使用者的态度

[b][color=red]不是[/color][/b]：

[b][color=red]“要这样编程序！”[/color][/b]

[color=blue][b]而是[/b][/color]：

[b][color=blue]“我能为你做些什么？”[/color][/b]

它存在的意义是想努力[b][size=x-large]帮[/size][/b]大家处理一些编程工作中很烦琐的问题。
它对自己的最低要求就是：[b]“不招人讨厌”[/b]

[b][size=large]它努力的在理解现在的程序员主人真正喜欢什么，又讨厌什么[/size][/b]

[b]比如 ORM：[/b]
为什么大家用 ORM 呢？因为大多数人都讨厌拼 SQL，很麻烦。但是有时候又不得不用一下 SQL。所以 ORM 对大多数程序员主人的最大的意义(虽然不是唯一的)就是：

[align=center][b]省却了拼装 SQL 的烦恼[/b][/align]

因此 [url=http://code.google.com/p/nutz/wiki/dao_get_start]Nutz.Dao[/url] 就替你拼 SQL。 实际上，它是 Hibernate 和 iBatis 的一个折中。
它可以支持你随便怎么写自己的 SQL，也可以根据一个对象，替你拼出 SQL
但是
它仅此而已。
至于分页，条件查询什么的，则是顺理成章的事。

[b]比如 Ioc[/b]
Ioc 的意义就是

[align=center][b]解耦[/b][/align]

我发现有很多程序员其实不习惯 Ioc 方式。
有些经验的人，拥有自己的解耦方式。
当然更多的人喜欢 Ioc 的方式，他们使用 Spring 。
Spring 的 XML 配置语法过于繁琐，而新的基于Java注解的 Ioc 框架（比如 Guice），实际上就是把耦合写在另外的一堆 Java 文件里，并且部署后似乎很难修改。
所以 [url=http://code.google.com/p/nutz/wiki/ioc_get_start]Nutz.Ioc[/url] 默认选用了 JSON，（又是一个折中：书写不麻烦，但是部署以后可以随时修改）
当然，它也支持你把耦合写成任何样子，如 XML，甚至数据库，扩展它一个接口就可以了。
关于这一点， 这里有详细的描述: [url]http://code.google.com/p/nutz/wiki/ioc_ioc_loader[/url]

[b]比如 Mvc[/b]
至于Mvc，其实什么要放到 M 里边，什么要做成是 V，哪一个又需要写成 C，程序员主人们的理解都有或多或少的偏差。但是无论如何，他们最起码需要做的就是：

[align=center][b] HTTP 与 Java 之间映射 [/b][/align]

[url=http://code.google.com/p/nutz/wiki/mvc_overview]Nutz.Mvc[/url] 力图做到刚刚够用，只负责粘合 M-V-C， 关于权限，日志，验证，UI 组件的支持统统没有。
同时也不限制你的扩展，比如模板引擎，比如要想支持 freemarker， 添加起支持来很自然。

[b][size=large]它努力让配置，约定的形式最自然[/size][/b]

比如 [url=http://nutz.googlecode.com]Nutz[/url].Dao 中的各种注解， 比如 [url=http://nutz.googlecode.com]Nutz[/url].Ioc 的 JSON 配置文件语法。
基本上，现在还没有人抱怨它们很难懂。-- 当然现在 [url=http://nutz.googlecode.com]Nutz[/url] 使用的人很少也是一个主要原因。
我们还在不断聆听来自各方的抱怨，我们对于批评，尤其是具体的批评，是很饥渴的。

[b][size=large]说点形而上的东西[/size][/b]

对于现有工具和框架进行改良我是支持的，但是“改良”是一种手段，不是我们追求的目的，不是吗？

Nutz 追求的是让它的程序员主人们最大限度的少写代码：
[list]
[*]可以让程序员主人少写一行代码
[*]可以让程序员主人少读一段文档
[*]可以让程序员主人少理解一个概念
[*]可以让程序员主人少知道一个约定
[/list]
这些在我们看来，都是有很有意义的

所以 [url=http://nutz.googlecode.com]Nutz[/url] 的任何设计，都会考虑到是不是能利用程序员主人现有的知识。
它只假设你熟悉 JAVA，SQL 和 Tomcat。

因为我们的工作要能变得轻松一些，
当市场让老板让我们修改一些代码时，我们不用加班，加班很毁身体。
而且我们也知道如何修改，
因为我们的工具很简单，它让我很容易摆弄，我总能让它服服帖帖的干活，
虽然我们只会 JAVA，SQL 和 Tomcat 的配置

当然 [url=http://nutz.googlecode.com]Nutz[/url] 不能帮你做到这一点，它不是“银弹”，甚至它是不是“银色的”的都是个问题。
但是起码我希望它能 [b]“在你构思你的项目时，不会是你的另外的一个问题”。[/b]
你不会说，我要维护 XXX 的配置文件，我要维护 XXX 的支持类，好累啊。
我不希望它成为程序员主人们的另一个负担，
程序员主人们对待这个框架不需要小心翼翼的，不需要学习很多约定和规则。
我希望使用它不会为你增加工作量，相反，在很多时候，我希望它会帮你降低一点点工作量。
能做到这点我就很满足了。

如果通过改良 SSH 能做到这一点，我当然很高兴，因为能省了不少事。
[align=center][b]
但是真的能吗？
能做的彻底吗？
[/b][/align]

SSH 是头几年的设计，在它们发布之初，的确蕴含着很多创新的思想。
[align=center][b]
但是现在呢？
[/b][/align]

我想，你已经不会脱口而出的说：“扯淡！SSH 无懈可击！”，其实，很多人都不会，大家只能说：“SSH 真是好强大哟~~~”

我希望一个工具或者框架能够做到：
[list]
[*]替我做的，做到最好
[*]不替我做的，别挡我的路
[/list]
至于它强大不强大，干我屁事。

所以，[url=http://nutz.googlecode.com]Nutz[/url] 也不是大框架，它当然不是，它很小。我很同意你 “[i]不走大框架的路[/i]” 和 “[i]提高工作效率[/i]” 的观点。
但是关于 “[b][i]a,一个开发框架，注重实用[/i][/b]”
[align=center][b]
什么样的开发框架呢？
什么叫“实用”呢？
[/b][/align]

我想你给出的答案是: “[b]一组基于 SSH 的编码约定[/b]”
而[url=http://www.iteye.com/news/11439]springside[/url] 的答案似乎是: “[b]一组代码例子[/b]”

这里的问题在于，你只能完善 SSH，而不能让它有本质上的提升。 Spring 团队可能不会为你做太多修改。
Spring 团队总是有很多伟大的思路
因此，他们很可能干脆不理你。
那么，这会不会限制你呢？
这会不会导致：如果你有更好的主意，可以提高程序员的生产力，有些时候不得不“曲线救国”。

不过我想，[u]努力做出些东西，让程序员的效率变高[/u]，应该是你和我的一个共识
实际上它也是大多数程序员的共识。

而我，希望 [url=http://nutz.googlecode.com]Nutz[/url] 能成为你所说的 “[b]a,一个开发框架，注重实用[/b]”