我认为任何业务系统的开发,不管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数据库做个一定的研究,过段时间再仔细看下,希望能写篇更好更细的文章记载。