以anyline-aliyun-sms为例，每个工具类都会对应一个配置类与默认实例化类 如SMSUtil对应SMSConfig与SMSBean SMSConfig用来配置帐号密码等 SMSBean用来在系统启动中往Spring上下文中注入一个默认的SMSUtil实例 SMSUtil就是开发中常用的工具了，如发送短信、查询短信接收状态、创建短信模板等 其中SMSC

为可视化前端提供数据，会同时面临以下几种问题 数据结构复杂 数据源结构多变 数据源标准不一，甚至冲突 数据来源多 数据量大 查询慢，但响应速度要求快 相同数据在不同接口中对外提供的结构不一样

WebUtil.params(request)只是简单的把get post参数封装起来不会作任何处理，在校验签名时通用需要用到 WebUtil.value(request)会把所有形式(包括body,get,post等)的参数解析出来，有可能还会执行解密、解码

这个参数默认用来控制在alter(Table table)时,如果发现数据库中存在而table中不存在的列是否删除 如果值为true则删除,false则忽略 实际应用中发现这样设置一个全局开关比较危险，因为设置了true之后会影响所有的ddl操作，不能单独针对一个table进行设置 更新后变成了根据

WebUtil.download(HttpServletRequest request, HttpServletResponse response, File file, String title) WebUtil.download(HttpServletRequest request, HttpS

Table,Column,Trigger,Function等几个类已经从anyline-data-jdbc包提到了anyline-core包中，  因为core中的基础类需要引用他们，取消了原来的Table,Column接口，因为在实际开发中接口类的频繁切换给许多人造成了疑惑，原来编码过程

这里的空值说的是在自动生成查询条件是的情况，如果是原生的SQL条件，则不会处理 service.quers("CRM_USER", " CODE='' ", "NM IS NULL") 这种提供原生SQL的情况不处理  需要处理的是以下3种情况 service

构造SQL太麻烦 如生成个IN的查询条件，要先取值，再判断是否为空，是多个值还是一个值，再遍历，经常要在XML中配置SQL，遇到不同的数据库时SQL语法还可能不一样 这些机械的操作，不应该浪费开发人员的时间，应该只提供个参数能说明要实现什么就可以， 如query("CRM_USER", c