对象生成数据库还是数据库生成代码

      最近一件事情另我非常摇摆不定,就是在使用快速开发的时候,是使用设计的模型直接生成数据库和代码,还是选择先设计模型,再建立数据库,而后根据数据库生成代码。通常我是通过数据库,使用代码生成器生成代码的,这样做的好处显而易见,使用的可选择的工具很多,生成规则非常明显,因为数据库的字段属性等等都是非常明了的。

 

      但是从模型对象生成数据库和代码似乎已经是趋势,微软的EF,就是提倡直接生成数据库和代码,显然,这样开发人员不需要关心数据库,直接根据业务模型开发系统,使用系统提供的方法和函数。

 

      我们都知道一般一个系统的研发,需要从需求分析到架构开始构建整个系统,E-R图式必须的,UML之类的也是非常好用(当然我从来不用,因为不懂这个)。如果根据客户的需求,和分析师的分析,建好了模型,就能生成一切,开发人员搬动代码调整逻辑关系,生成可运行的系统版本?似乎一切都是那么完美吗。代码工作者的工作如此简单吗,问题是,我时常考虑模型生成数据库的可行性,稳定性,和易维护性方面,除非模型与数据库有着相同的规则,相同的约束,一切都是无缝集成,完美的,否则,任何一点瑕疵得地方都会导致数据库的不兼容,和程序性能或BUG。

 

      在此之前其实已经有人将EXCEL同数据库形成了统一的平台,通过EXCEL设计表单或列表来形成系统,这有很多出色优秀的功能,但是这恐怕不是完美所说的系统。我现在的设计思路大概是这样的,需求分析--系统分析--E-R图(或业务流程图)--数据库设计--代码生成--根据业务变动重新设计部分数据库--调整业务层代码--系统运行调整性能--项目完工。

 

      当然我认同从对象生成数据库和基础性的代码是正确的,符合面向对象的设计要求,但是数据库和基础代码就是对我们来说是完全透明的。而设计数据库和根据数据库生成代码,不易管理,散乱,使用ORM则会出现两种问题。真是左右为难啊。

 

      以上只是自言自语,勿以为是精华。

posted @ 2011-02-04 20:11 拒绝潜水的鱼 阅读(...) 评论(...) 编辑 收藏