最早用的代码生成好象是OLYMARS还有CODE CHARGE，市面上的这种工具也是多如牛毛。而如果建立在别人的代码生成的很大
问题是难于维护，看别人的生成CODE总是觉得难改，而且如果有新的版本时更难维护，总之是不好用。
所以干脆就自已做了一个Stored Procedure的代码生成。我们
当时是用TYPED DATASET来做为数据ENTITY，基本上DA这一层就变得很简单了。
最近把这个工具改了一下，多加了支持GENERIC，和生成对应TABLE的ENTITY。
可能大多数人都不看好代码生成，觉得不好管理，生成的代码难看。可是我觉得新出的 .net 2.0 其实让代码生成变得更好
维护。因为反正要用visual source safe完全可以把代码放到PROJECT下单独的目录，变成只读，然后只是在要修改某个表的
时候，再去把它CHECK OUT，然后重新生成代码，因为别的都是只读，所以只有更新的才会被覆盖。
另外一点是Paritial Class可以让我们轻松的加入新的代码到生成CODE中，却不需要修改源文件，所以可很轻松的进行扩展。
例如加入更新的函数，还有Lookup TABLE中的Description做为附加的PROPERTY等等.
而且只要我有代码生成工具的源代码或者模版,就可以很方便的进行修改，基于自已理解的Code的修改应该还是更省心吧.
现在做的没有什么太多功能,我所看到的是,大多数公司都还是在做行业应用MIS软件,而且也没见过有
公司彻底抛弃现有的数据库改用新的的情况,所以需要ORM那种要用DATA PROVIDER来可以支持多个数据库的情形，来扩展
自已的潜在客户。大多数做.NET的也都是在用SQL SERVER,而且也都是写STORED PROCEDURE来做数据存取.
（也是因为公司里掌权的都是些老人家，这些人常年做数据库起家，其实是比较排斥ORM这种OO的东西的）
所以我生成的代码也还是平面的以数据为主的而不是OO的。见过有用HIBERNATE来做的，但是遇到
复杂的数据存取时，他们还是要用STORED PROCEDURE，因为真的是要快好多。
所以KISS的原则，生成常用的CRUD SP，生成表对应的ENTITY，根据SP生成DATA ACCESS，然后再有一些UTIL可以增强TRANSACTION功能，
完全就够用了。在ENTITY中，我加一个COLUMN对应的ATTRIBUTE，这样就可以在用DATAREADER读取时，只对ENTITY的有标记ATTRIBUTE的
PROPERTY有用。这样子就可以保证SQL STORED PROCEDURE中返回的DATA会灵活的只和ENTITY中有对应关系的绑定。
看过TEDDY的框架，是很不错。不过不太喜欢类里的SET、GET都通过一个DICTIONARY来做操作。可能只有这样才是最快吧。
现在我还是只是CACHE每个ENTITY里的有CUSTOM ATTRIBUTE的PROPERTYINFO，然后用PropertyInfo.Set(obj,Value）来做。
那个IBATIS也是这样子而已。或许还是应该用CODEDOM或者EMIT，不知道到底能快几倍。
还一种方法就是直接在生成的Code里加就算了。
现在用的是SQL data reader来生成Generic List，采用的也就是Starter Kit里的做法。
That is it。觉得这样子倒也算简单方便，也还比较灵活。当然它不是一个框架或者ORM，只是大多数常用的Project生成烦人的
数据存取层。不知道大家有什么看法意见？
