关于T4代码生成器的使用

为什么有些开发人员从来不用代码生成器

    代码生成器,我想很多开发人员估计都使用过,起码也听说过．为什么有些开发人员从来不用代码生成器呢，我总结有以下几种情况：
    1.个人习惯，不喜欢用工具，喜欢什么事都亲自处理．
    2.没有遇到让自己特别满意的代码生成工具，而自己又不想去改造．
    3.有些公司好几年一直维护那么几个项目，除非大规模的重构，否则没有代码生成器什么事．这类公司注意的业务逻辑，技术深度之类的问题．
   

 企业小项目特点
    正好我最近做的项目都是小项目，属于企业内部的一些系统应用，这种项目有如下特别：
    1.规模小，也可以理解为投入的资金不多．
    2.人员规模小，一般开发人员加上测试人员不会超过8个.
    3.项目周期短，一般不会超过3个月.
    4.小规模的项目多．
   

代码生成能解决哪些问题
    遇到我上述的场景的话，如果有一款适用于企业内部风格的代码生成器就相当有必要了，它能有效解决如下问题：
    1.能够快速搭建一个项目解决方案，这里指的解决方案是指简单的创建工程以及分层．
    　比如，创建什么样的UI项目，是MVC还是asp.net webform,如何分层，是传统的三层还是基于领域模型的．

       下图是我生成的项目结构：

　　　
    2.能够快速生成一套基于整个公司风格的内部系统UI
    　这个非常重要，有些公司的系统非常多，但如果每个系统在UI风格上差异太大，不是一件好事,维护难度特别大，而且用户需要适应不同的系统风格．无论是出于哪方面　　　考虑，实现一套标准统一的UI对公司是非常有帮助的．
    3.能够快速构建一套对业务数据表进行简单增删改查的功能模块．
    　只要有数据表，就肯定需要有地方去维护这些数据，我们可以将这些简单而且枯燥的活让代码生成器帮助我们自动完成,谁也不想天天玩那点增删改查这类hello world．
    4.能够集成大多数通用的解决方案
    　4.1 记录数据库执行情况来分析数据库查询性能问题    　　　

            这个功能在一定程度上能够帮助我们收集数据库查询的情况，能够比较简单且直观的监控数据库的访问情况．
    　4.2 一个比较通用简单易用的配置功能   

            它可以简化程序员对于配置文件的使用，支持基于类对象的访问方式，当然包含集合型的配置数据读取．(如何分离web.config改进版本)　

       4.3 日志功能

             可以基于log4net，在此基础上做进一步的包装．
        4.4 缓存功能，缓存对于具备一定并发性的系统来讲都是必不可少的功能模板，成熟的解决方案更加重要．

　　　　　网站架构之缓存应用(1)概念篇   

　　　　　网站架构之缓存应用(2)实现篇 

　　　　　网站架构之缓存应用(3)实现篇   

　5.能够实现统一的仓储模式
      我们可以采用EF 4.3实现存储功能，然后在些基础上增加上传统的仓储模式．
   6.可以构建所有项目的分层结构
    　比如我们可以在UI层与业务逻辑层之间增加服务层，以此来实现更好的解耦,再比如我们可以在服务层与UI层之间通过Ioc来实现进一步的解耦．

需要注意的地方：
    1.代码生成器最好基于模板形式．
    　基于模板的工具具备非常强的灵活性，当需要生成其它种类项目时，编写模板的成本远低于写代码．于是我选择了T4 text template,微软的MVC也是采用它来实现，所以我没有理由不选择它．
    2.代码生成器不仅仅是生成代码
    　如果只是用来生成代码，我认为还不够，对我个人来讲，我是希望通过它可以将团队中的各种好的经验以集成的方式提供给团队重复使用，优点如下：
    　2.1 项目成员不用为了同一功能反复找解决方案
    　2.2 项目成员有一个集中的地方学习一些通用解决方案，是一个重要的学习平台．
    
    在园了里找了一会，发现了一款基于T4的代码生成器，而且UI是用WPF做的，觉的还不错就拿下来试试，最终决定在此基础上做出我自己的代码生成器．
    
代码生成器改进点：
    1.原项目不能生成全套的解决方案，只能生成文件．
    　经过改造后，能够生成完整的解决方案，用户直接就能运行．
    2.新创建了一套模板．
    　是采用EF 4.3 Code First模式，UI采用MVC 3,存储模式为传统的仓储模式，同时对于服务器以及UI层引用了Ioc，以实现进一步解耦．
    3.修改了部分原项目中个人感觉不太对的地方．