我认为任何业务系统的开发，不管b/s还是c/s，核心精力都应该是放在对逻辑和对高性能，安全性的几H的处理，底层和系统结构应该由架构师考虑好形成统一风格，前端应该由美工来完善，因此我觉得一个节约人力又要把系统做很好，一方面前期把系统结构考虑好，另一方面用codesmith类试的生成整个系统。尤其像CMS后台这种，结构固定，如果还用EXT来做，前端展现也固定，可以快速生成出来，再少量人对细节进行处理，前台或者面向最终用户的，也基本可以生成基础结构，并具有基础功能。之前看到过博客园有人发了自己的快速CMS生成系统，经过简单配置就行了，但如果有codesmith，不仅可以很方便的只修改模版，或者自定义其他类，就可以自定义更精确的控制自己想要的生成结果。
突然想到一个“笑话”：
有一个生产香皂的工厂，工厂生产出来的香皂，都装在一个漂亮的纸盒子里。
但是工厂的装香皂的流水线存在一个问题，总是有一些纸盒子，经过流水线以后，香皂没装进去，成了空纸盒子。
要把这些纸盒子全部捡出来是一个很伤脑筋的事，厂长增加了很多工人检查流水线，但是空纸盒还是存在。
这天，厂长去研究所找到一些专家和博士，“你们给我研究出一个装置，能把空纸盒全部捡出来，我出100万”
专家和博士立即成立攻关小组，在经历了半年的艰苦研究，并花费了上千万的资金，终于制造出一种光电扫描器，香皂盒经光电扫描装置扫描后，里面没有香皂的盒子被扫描出来，并且被机械手捡出。
终于解决了这个问题，厂长舒了一口气。
话说另外一家生产香皂的小工厂，也存在同样的空纸盒的问题，另厂长十分恼火。
这天，厂长把几个农民工召集起来“给我找个办法把空纸盒捡出来，否则我把你们都开除了”
农民工聚到一起，想啊想，想了足足有一天的时间。。。。
最后。。。。
一个农民工买来一个大功率的风扇。。。
对着流水线上的香皂盒吹，空香皂盒就这样被吹跑了。
终于解决了这个问题，厂长舒了一口气。
。。。。。。。。。。我对这个只能说没有人对也没有人错，小工厂确实很小成本解决了问题，节约了钱；大工厂虽然花了很多人力财力，但是有可能会带来技术革命，带来其他收益。
同样软件开发一样，有的张的很像的结构和代码，可以用快速生成器生成，节约了人力成本；有的想了很久，发明了ORM这些等等，各有各的好处，但当系统结构稳定时，我觉得用一个快速生成器也是很不错的选择，尤其像codesmith这样基于模版生成器，扩展性也非常非常好的框架。
该具体说了技术方面的了，前几天由于项目需要，粗略分析了下codesmith，以前也用的很少，这次要自定义根据oracle数据库生成一定结构的代码，遇到些小麻烦，记录下。
之前对<%@ Assembly Name="SchemaExplorer" %>，<%@ Import Namespace="SchemaExplorer" %>没有很搞明白，这个虽然不影响其他使用，但一直没怎么明白，现在才知道，Assembly 就像引入程序集，可以在运行时用它处理逻辑，就像VS的引用程序集，Import 就像C#里using命名空间，如果没有了它，编译就通不过。
<!-- #include file="a.cs" -->,将在编译和运行期间自动编译并加载a.cs类；自定义类来生成自定义代码时将会常用它，它将实时被编译，其他地方用改类时自动就有了智能提示。
<% %>讲在运行时自动执行
<%@ Register Name="DominService" Template="Domin/Domain.Service.cst" MergeProperties="False" %> ，像这个就像用用户空间一样，引入Domain.Service.cst这个模版，对模版可以RenderToFile(..生成出来，SetProperty设置该模版变量
<%@ Property Name="ClassName" Type="String" Category="Context" Description="类名的描述" Default="a.cs"%>，这个添加属性，cst文件自动识别在分类为Context下添加一个可以输入字符串的输入框。
用的最多的<%@ Property Name="SourceTable" Type="SchemaExplorer.TableSchema" Optional="True" Category="Data" Description="指定数据表." %>
<%@ Property Name="SourceDatabase" Type="SchemaExplorer.DatabaseSchema" Optional="True" Category="Data" Description="指定数据库." %>，由codesmith自已的制定数据表和制定数据库的属性，根据数据库快速生成代码，必不可少的属性。
当然比较重要的是codesmith自己的SchemaExplorer.dll文件，位于codesmith安装目录下的AddIns文件夹下面，它包括了生成数据库用的类和方法。
生成数据库类型比较重要，oracle和mssql生成后的类型字段又不一样，因此导致经常生成好数据库，不同数据库文件类型不一样，比如某个表的某一列ColumnSchema，mssql数据库获取类型是用该对象的DataType属性，值将有DbType.Double，DbType.Int64，DbType.String等，但oracle不一样，获取oracle数据库的属性是NativeType属性，它是一个string类型的结果，将会是比如clob,number,timestamp(6),这样的，由于oracle数据库一般用number类型，不用int类型，因此当自定义类转换为具体类型时，要参考ColumnSchema对象的Precision, Scale, Size来判断了。其中scale是精确到小数点后的位数，如number(6,2),则scale属性为2，size是用于计算Nvarchar2这种类型的长度，如nvarchar2(100)，则size属性为100，precision为小数点前精确位数，如number(6,2),则precision属性为6，但是timestamp这几个属性没有值，它是直接从NativeType里看的出来时间长度，可能为3,6,9，默认为6，NativeType值将为timestamp(6)。
最近比较忙，没有很细研究，只是前端时间按用SchemaExplorer.DatabaseSchema自动生成整个oracle数据库做个一定的研究，过段时间再仔细看下，希望能写篇更好更细的文章记载。