11.34 为什么框架没有提供代码设计器或代码生成器？

每个公司或团队都有自己的开发习惯或开发模式，光标科技这些年来一直坚持CodeFirst，对于实体对象的分析设计，我们的流程是，先根据业务需求分析设计出实体对象及对象之间的关系，最终生产出UML类图，为了避免管理图纸与需求文档花去过多的时间，其它UML图在业务简单的情况下默认省略，只在业务复杂的时候配上流程图，帮助程序员写代码；代码规范与写法每位员工入职时必须先学习，框架结构与操作流程 也在真正进入开发前灌输到每一位开发人员，再辅以开发样例学习，这样避免了向每一位同事讲述系统构架、组件功能等等这样的工作，使每一位开发人员可以在极短的时间内投入到工作中，得到的结果与资深程序员没有什么区别，即使他并不明白其中所有原理，可以做到一边工作一边学习，至于可以上升到什么境界则完全取决于自身。

前面说到我们的数据实体对象是先有代码，再根据代码直接生成数据库。业务对象一般情况下都与数据实体对象一一对应，偶尔也有设计抉择、性能抉择等因素使得业务对象与实体对象不一致的情况，这里不做特别讨论。现在我们有了数据库结构，生成业务对象的代码完全交给了CodeSmith，代码生成器只能完成与数据对象的交互，简单的数据验证等工作，与业务逻辑相关的操作必须手工添加，至此整个从需求分析到代码实现的过程已经完成。

因此，在数据实体对象设计并生成代码时，我们用不着代码生成器，在业务对象生成时我们使用了CodeSmith，因此不必花力气去造车轮了，况且数据访问层的技术也有变化，为不同的变化努力并花去宝贵的开发时间，并不值得，毕竟客户要的是软件产品和交货日期，没有人会在乎你克服了多少困难。

关于界面的编辑与生成方面，因为我们所有工作都在业务对象中实现了，界面只是个交互与收集用户输入的媒介，因此工作相对简单，只是简单的拖控件，目前感觉是越拖越爽，完全没有觉得拖控件是低等程序员的自卑，相反我们鄙视哪些为做一个界面花几天时间，界面中代码横飞，错误不断的程序员，为什么要把工作做得如此复杂，简单点不好嘛？这样的好处还有一点照顾了不同程序员的特长，有些人对审美完全是少根筋，有些人对写代码看作是苦役，我们的观点与习惯是让程序员做喜欢做的工作，做做得好的工作。

关于拖控件的编辑环境，目前我们没有发现比VS环境做得好的，因此在可预见的未来不提供界面编辑设计器等工具。用VS就行了。