给做快速开发框架的人泼泼凉水

很多人谈到市场去了。。。。。

凡是代码生成的一般绝对不会去使用，
ORACLE ADF那套东西拖拉就行，或者知道表结构以后点几个按钮 N个针对表的维护页面就已经出来了，确实快，但是维护起来很恐怖。

生成代码不如好好设计设计框架，组件重用就好。慢也慢不到哪去。

谈谈个人看法，首先分析一下所谓快速开发框架的背景和目的，应该不外乎以下4种：
1，一切从0开始，既没有快速的，也没有不“快速的”，为了做东西而做；
2，已经有成熟的框架，不够“快速”、重复代码多，为了减少这些弊端，针对具体业务进行重构，加快开发人员的开发速度；
3，为了学习，在研究自己框架的同时，加深对现有框架的理解；
4，像LZ这样的有心人，别人做的我也能做，还要比别人做的好，比别人的开发起来快，生成代码、灵活配置。。。。。

===========
这样一分析，结合LZ的观点，我想大家可以统一意见吧？
前两种是适可而止，有益无害，我们不会反对。
第三种个人学习，不强求别人，在一定领域中实现其价值，也是鼓励的。
第四种应该就是LZ所要表达的意思，由于在学习推广和应用推广方面的问题，不宜投入太多。

作为一个软件设计人员，我们一直追求又＂好＂又＂快＂，然而它们是那么的难以和谐．EJB很好，但是不够快，于是就有了ssh，J2EE很好，但是不够快，于是有了RoR,RoR很快，但是还不够好，我们又要给它install plugin．

快速框架没有什么不好，但是要着眼于我们要解决的问题．这几年快速框架这么流行是因为我们发现我们的业务原来大部分都不是很复杂，共性的东西很多．

一个好的框架，至少是要满足开闭原则的．当碰到一个比较特别的需求时，查是让我把它开肠剖肚把源码改一遍，肯定是个不合格的产品了．

各位业内资深人士们，我要告诉你们我的多年的思考结论：

可理解性才是各种开发框架最本质的需要。这种需要是超越一切名词之争压倒一切的。

可理解性，就是指在看到一段代码的时候，是否能够快速的理解这一段代码的功能。
结构化编程，对象化编程，层次模型，高内聚低耦合，乃至现在流行的动态语言，
泛型，AOP，等等等等，无一不是在为此服务。



至于现在流行的开发框架，本人离开正经的软件行业已经很久了，所知不多，就不班门
弄斧了。仅仅对一个特点做一下评论，常见的开发框架，为了达到灵活的目的，常常采
用极其庞大的配置文件。这一点，是与可理解性背道而驰的。背负着庞大的配置库的一
段过程代码，无论如何是做不到容易理解的，往往还不如写入到代码中更为简洁明快。

其实，即使是配备庞大的配置文件，开发框架也可以通过各种我称之为“代码透视图”
的方法来达到这种可理解性的要求，让使用，生成和各种层次的修改都变得简洁。这
是另外一个层次的事情了，就不多言了。

上面认为硬编码好的原因是居然是因为可以热部署，是动态的。

这就荒唐了。动态特征自古就有。动态性自古也有。
http://fireflyc.iteye.com/
如果说动态性能支持硬编码的话那么实在是说不过去的。

按照这个理论所有的配置我都定义常量好了，反正总是要重新编译重新打包发布的。
~也许我们期望有一天tomcat没有了配置文件，而是提供一堆java代码，我们修改常量然后编译发布。我们修改apache代码然后编译，使用。
我们还必须让windows公布源代码，因为注册表实在是太麻烦了。我们修改windows源代码，然后编译。任何安装程序都必须重新编译操作系统内核。

如果仅仅把软件把java作为一个简单的web开发未免太狭隘了。

至于说注解是否符合阅读性我觉得是仁者见仁的问题。为什么？注解本身就是一种附在代码上的东西，说它影响阅读那是一点也不差的。

对于是否减少重复的言论，可以这样说明，注解几乎是不可能减少重复的。你说配置我能做，那么注解也能做。哪里的注解比起配置是减少了配置所做的重复呢？

java语言本身的从1.4开始几乎没有进步。每次升级无非是增加更臃肿的API而已。仅仅如此。比起C#它可以说是一直在原地踏步走。

以上讨论我的所有观点不涉及商业，如果硬扯商业那就没有边了，我们坐下来能扯3天3夜。;-)~~~

热部署的言论我愣是没看到，估计是我不仔细吧。

我强调了不知道多少遍的部署型配置和专用型配置，不过好像只适合于项目，既然你谈到APP了，那就可以认为是不能用ant解决的部署型配置，那很正常啊，但是绝不等于专用型配置文件会让客户随意修改配置，这是不可能的。请不要总是把这两大类配置文件混在一起讨论，以前JDBC写出来的程序应用哪会有hbm这种配置文件，难道你就能说以前写的那种程序无可配置性？是因为这类配置文件根本就不是为客户服务的，是为开发人员服务的。

假设，一个不恰当的假设，用hibernate+mysql做一个桌面的应用，可能让用户随意修改hbm配置文件么，这是基本不可能的事，hbm配置文件就是专用型配置文件，这种类型的配置就应该放到代码中去，增加可读性。专用配置是写给开发人员看的，不是让用户随随便便改来该去的。

除了通用型配置（如spring的事务配置），xml配置（专指xml）的字符数一般一定是超过注解的，还有不要以为注解就是简单的配置用途，如果要实现某些配置文件中“继承”的特性要方便得多，请先多实践一下annotation的本质（这又不是简单的xdoclet文本）。

根据我说的两种配置文件的分类，请再仔细想想专用配置文件的用途到底是什么。

岔出去举个例子，某些动态语言，本身写起来就像写配置文件，然后你就把它看成配置文件不就行了，针对配置文件编程嘛。

回过来我还可以说，你如果写C的话，不也是写配置文件么，这个配置是用来告诉编译器生成二进制代码用的，不是么？

你怎么提到Java语言和C#的问题了？有人挑头了？

减少成本肯定是和商业有关的，否则为什么要说时间成本，技术的改进有相当一部分就是用来减少软件工程中各个环节的时间成本。

典型的简单的事情复杂化


没有强制你所有的代码都用代码生成器，也没有强制你从项目一开始到后期维护全都用代码生成器，更没有说是动态生成。只是在需要的时候，生成一下， 简少一些机械性的重复劳动，为何不用？


打个比方，项目刚启动， 要写一堆POJO，DAO，XML，这个时候你是愿意用代码生成，只要往生成器里面填个类名，填几个属性，按钮一点，就把一些雷打不变的JAVA文件，映射文件，DAO中的CRUD方法都生成了，然后再抛开代码生成器，根据实际需要具体事情具体做，

还是愿意连长得都一个样的POJO都自己一个一个去写？

-----------－－－－－－－－－
快速开发框架 >> 代码生成器

这些快速开发框架并没有说要给你解决所有的问题，什么情况下都能用上，让你自己连一行代码都不用写。它它只是对常用的开发模式，一些遍地都能用上的方法进行封装，并附上一个代码生成器，让那些长得都一个样的代码动生成，并保护你的键盘，免得你把ctrl+c, ctrl+V给敲坏了。


如果我们的项目不是很个性化，那我们为什么要抛弃这些框架？

问题就出在“只是在需要的时候”，什么时候是需要的时候？每个人理解不一样，偏向性不一样，导致框架的发展方向也不一样。

举个例子，ror中的约定大于配置思想，hibernate中也可以自动把类名和属性名从驼峰式命名自动转换成数据库下划线分隔式命名（NormalUser -> NORMAL_USER，userName -> user_name），参考org.hibernate.cfg.ImprovedNamingStrategy。这是一种策略，当然另一种策略就是完全靠代码自动生成“注解”或“hbm”。

在有这两个策略之前，不同的人的倾向性一定会往不同的思路上去解决问题。当然不是所有的代码生成的实践都能用某种技巧或约定或运行时生成来代替，但是人一旦思维懒惰，当碰到一些棘手问题，本人已掌握的解决重复的能力（比如OO）不能很方便的解决时，就求-助于代码生成，这样的思维方式就是不对的。代码生成应该是比较靠后的解决方案，而不是优先方案，或者说在可能的情况下尽可能减少代码生成的比例。还是以上面这个例子为例，假设整个POJO都是代码生成的，如果用了ImprovedNamingStrategy，则可以减少代码生成的代码量，也是推荐的。

最后再说一下，“只是在需要的时候”每个人理解都不一样。

假设，一个不恰当的假设，用hibernate+mysql做一个桌面的应用，可能让用户随意修改hbm配置文件么，这是基本不可能的事，hbm配置文件就是专用型配置文件，这种类型的配置就应该放到代码中去，增加可读性。专用配置是写给开发人员看的，不是让用户随随便便改来该去的。

但有支持不同类型数据库的需求，使用hbm文件的换一套映射文件就行了，写注解岂不是要换代码