动态语言+约定，剩下的只需要文件系统就够了
最近在工作中一直用jdk1.4和一些旧技术，ejb2/spring1.x之类，配置繁琐，开发中间也是规规矩矩，一层层的代码copy——竟然没有感觉到什么不爽，好像很多第一批用java做企业系统的先锋们都接触过这些技术吧。
?
回到正题——个人思索加上以前的开发积累和经验（虽然很少很少），提出一下几个观点：
?
1. 在以数据库为数据中心的业务系统的开发模型中，DDL本身就是一个符合业务的数据模型结构了，没必要在Java层面上对应或者再抽象或综合出另一套vo去对应，如果只是为了遵循命名规则，则更不必。
?
2. 延伸第一个观点，关于数据类型，可以通过匈牙利命令约定，加上更细致的业务相关的前后缀做到命名与类型和校验信息结合。传统的贫血模型很适合此类做法，即在Java层做一个相对宽松的参数输入的通道，这些参数来自不同的客户端，参数名称比较规范，只不过在数据流向控制方面严密些。
?
3. 一些jdbc封装组件已经不做传递class参数的方式了（类似queryForList(MyVO.class)）——比如groovy的Sql，这个当然和groovy脚本语言本身特性很相关，脚本语言在基本数据结构的处理方面有着天然的优势。
?
4. 另外一些很早都出来的，比如url route，还有把java的接口或方法包装下概念换成service provider或resource entry等的，本身就没什么延伸的新东东。系统设计所要做的一直都是关注耦合性，模块化，需求变化，而做好这些换换概念或技术都是次要的（当然先进的工具会提高生产力）。
?
5. 不能偏离主题了——COC盛行的时候大家才开始更多关注，但在ROR之前，肯定有不少在java方面有沉淀的公司有着自己的一些”COC“，加上一些辅助工具，说不定不比ROR的差——好多喜欢电脑桌面清洁的coder还会经常整理电脑文件夹呢，归归类，删除无用文件，重命名**，coding过程不都是经常搞类似的事么。
?
6. 从一个格式化过的磁盘重新创建一套文件目录，并且随着文件的种类越多，内容越丰富，数量越多，一直保持着一个令人赏心悦目的文件目录结构并能有效地从中快速准确所需要的信息——这就是一个工程一直在做的事儿。
?
?
拍砖开始，钢盔顶起……TT
?
?
?
