Why Nutz
今天，同事问我，为何选择nutz，而不是MVC。一时我也不知道为何，好用？方便？习惯了？
想了想还是有几个理由的，这来源于当初遇到的几个问题，那就从问题讲起。
问题1:android app数据同步
方案1:sql语句
曾经(呵呵，就在公司以前某个APP中)，见过这种同步方案：
想同步一个表，拼sql语句，然后无论是android客户端还是服务端，读取收sql语句，然后执行插入或者更新删除操作。
弊端(个人意见)
- 表增加代码就增加
- 代码量大，各种判断加上一大堆重复且毫无意义的sql语句
- 交互数据量过大
- 不优雅
方案2:
- 传递json,专注于数据。
- 代码通用，数据表动态配置，条件配置
- 一般情况json无须处理，直接入库
- 数据保存时，一些字段自动赋值(更新时间，操作人等)
- 数据解析时，可以方便的将json解析为相应的对象，并可进行个别赋值
- 数据库同步过程中，日志记录
能用尽量少的代码满足以上的需求，需要一个怎样的框架呢 - 一个好用的Json解析类
- 一个方便的数据操作类
- 一个强大的类反射操作类
而nutz恰好满足了以上的需求。接收json并保存到数据库只写了大约50行代码+几个model类
问题2:文件上传
在做一个项目时，excel导入导出的操作，excel导入需要上传文件。
公司没有一个好的现成的东西。
而nutz恰好提供了文件池的，几乎毫不费力实现了文件上传。
问题3:excel通用导入导出
excel通用导入导出开发过程中，依旧遇到了问题1遇到的问题。
将表格数据自动匹配表格并入库。
个性化的字段赋值。
再次见证了nutz的方便。
在几次遇到问题并解决的过程中，渐渐感受到了nutz的得心应手，并开始思考
什么是一个好的框架？
好的框架应具备以下特点
简洁，易于上手
最讨厌各种配置文件一大堆的框架，配来配去太糟心。
功能强大的类库
只有你想不到，没有框架做不到的，这才是最好的。
强大的日志
一个不健全的日志，排查错误对程序员来说简直是个噩梦。
稳定
一个时不时会崩溃的框架，估计谁也不会喜欢
写在最后的话
借用nutz的宣传语:
如果你觉得 Hibernate 控制比较繁琐，iBatis 编写SQL又比较麻烦，Nutz.Dao 专为你设计。
如果你觉得在多个服务器部署或者修改 Spring 配置文件很麻烦，Nutz.Ioc 专为你设计
如果你觉得直接写 XML 配置文件很麻烦，可视化编辑器又没控制感，Nutz.Mvc 专为你设计
如果你觉得 JSON 转换很麻烦（要写超过一行以上的代码），Nutz.Json 专为你设计
如果你觉得 Java 语法不如 Ruby 便捷， Nutz.Castor 以及 Nutz.Lang 专为你设计
如果你以前根本没接触过 SSH ，只使用 JDBC 编程， 整个 Nutz 专门为你设计
也许这就是我喜欢nutz的理由吧。