创建代码生成器可以很简单：如何通过T4模板生成代码？[下篇]
但是这是一种基于单个文件的解决方案，即我们必须为每一个生成的存储过程建立一个模板。如果我们提供一种基于多文件的代码生成方式，将会为编程人员带来极大的便利。借助于T4 ToolBox这个开源工具箱，多文件的SQL Generator的实现变得异常简单。[文中的例子可以从这里下载]目录 二、创建自定义的Generator 三、ProcedureGenerator如何被使用？一、多文件代码生成器会带来多大的便利？我们先来直观的感受一下较之《上篇》提供的单一文件的代码生成器，基于多文件的代码生成解决方案会为开发人员带来多大的便利。 同样对于《上篇》创建的数据表T_PRODUCT，之前我们为了生成三个不同的存储过程，我们不得已需要创建3个不同的T4模板文件。实际上我们更需要的方式只需要创建一个T4模板，让我们的SQL Generator自动为我们生成3个包含相应存储过程的.sql附属文件,如左图所示（点击看大图）。有的时候，基于单个数据表的存储过程生成方式我们依然觉得不方便。如果我们能够在T4模板文件中指定的数据表的列表，让我们的SQL Generator为列表的每一个数据表都生成CUD三个存储过程，这样的方式更加具有吸引力。如右图所示（点击看大图），一个订单模块包含两个具有主子关系的两张表（T_ORDER和T_ORDER_DETAIL），现在我们在一个T4模板中指定这两个表明，通过SQL Generator可以帮助我们生成6个包含存储过程的.sql附属文件。甚至有的时候我们连数据表列表都无需指定，让SQL Generator为所有的表都生成相应的存储过程。我的例子中没有提供这样的功能，但是实现自来不会存在任何问题。二、创建自定义的Generator在《上篇》中我创建了一个抽象的ProcedureTemplate类，以及三个基于生成CUD存储过程的具体ProcedureTemplate：InsertProcedureTemplate、UpdateProcedureTemplate和DeleteProcedureTemplate。它们都将直接服务于我们今天将要提供的基于多文件的SQL Generator。在《上篇》中，这四个Template分别定义在4个不同的TT文件中，3个具体的ProcedureTemplate通过#@include指令将抽象ProcedureTemplate模板文件包含过来。由于我们将要创建的T4模板将会使用到这四个类，如果我们用四个#@include指令将四个TT文件包含过来，由于T4引擎将会导致对ProcedureTemplate的4次包含，最好将会导致变异问题。个人觉得这应该算是T4引擎解析包含关系的一个局限性，为了解决这个问题我们不得不抽象的ProcedureTemplate和三个具体的ProcedureTemplate都合并成一个TT文件。T4 ToolBox为类库中为了提供了一个抽象的T4Toolbox.Generator类用于实现多文件的代码生成。为此我们创建一个TT模板文件，定义了如下一个继承自该类的ProcedureGenerator。ProcedureGenerator的核心是通过属性Templates定义的类型为IEnumerableProcedureTemplate的ProcedureTemplate列表，这个列表在存储过程中进行初始化。而对于ProcedureGenerator的构造函数，处理定义了一个表示数据库连接字符串的databaseName的参数外，并以数组参数的形式指定了生成的存储过程基于的数据表名的列表。#@ import namespace="System.Collections.Generic" ##@ include file="ProcedureTemplate.tt" ##@ include file="T4Toolbox.tt" ##+publicclass ProcedureGenerator : Generator{public IEnumerableProcedureTemplate Templates{get; private set;}public ProcedureGenerator(string databaseName, paramsstring[] tableNames) {if(null == tableNames || tableNames.Length == 0) {thrownew ArgumentNullException("tableNames"); } this.Templates = InitlizeTemplates(databaseName,tableNames); }private IEnumerableProcedureTemplate InitlizeTemplates(string databaseName, string[] tableNames) { foreach(string tableName in tableNames) {yieldreturnnew InsertProcedureTemplate(databaseName, tableName);yieldreturnnew UpdateProcedureTemplate(databaseName, tableName);yieldreturnnew DeleteProcedureTemplate(databaseName, tableName); } }protectedoverridevoid RunCore() {foreach(ProcedureTemplate tempalte inthis.Templates) { tempalte.RenderToFile(tempalte.GetProcedureName() + ".sql"); } }}#真正的存储过程的T-SQL脚本实现在重写的RunCore中。由于具体的文本转化逻辑都定义在了ProcedureTemplate中了，所以在这里我们需要遍历的ProcedureTemplate集合中每一个Template对象，调用RenderToFile方法将相应的存储过程的脚本写入以存储过程命名同名的.sql文件中。三、ProcedureGenerator如何被使用？我们最后来看看我们创建的ProcedureGenerator最终如何被应用于具体的代码生成。其实很简单，我们只需要创建相应的模板文件，通过#@include将定义ProcedureGenerator类的TT文件包含近来，最后以代码语句调用块（#StatementCode#）的形式实力化该对象，并调用Run方法即可。在构造函数中指定数据库连接字符串的名称和数据表名的列表。下面是基于但表的T4模板。#@ template language="C#" hostSpecific="true" debug="true" ##@ include file="Templates\ProcedureGenerator.tt" ##new ProcedureGenerator("TestDb","T_PRODUCT").Run();#下面是基于多表的T4模板：#@ template language="C#" hostSpecific="true" debug="true" ##@ include file="Templates\ProcedureGenerator.tt" ##new ProcedureGenerator("TestDb","T_ORDER","T_ORDER_DETAIL").Run();#当你代码生成工作执行之后，会多出一个与TT文件同名的附属文件，你需要手工删除掉它。从数据到代码——通过代码生成机制实现强类型编程[上篇]从数据到代码——通过代码生成机制实现强类型编程[下篇]从数据到代码——基于T4的代码生成方式
大家觉得哪个.net代码生成器最好用
LTP.Net代码生成器
--------------
软件简介：
Codematic (原名:LTP.Net代码自动生成器)是一款为 C# 数据库程序员设计的自动代码生成器，Codematic 生成的代码基于基于面向对象的思想和三层架构设计，结合了Petshop中经典的思想和设计模式，融入了工厂模式，反射机制等等一些思想。采用 Model + DAL + BLL + Web 的设计，主要实现在 C# 中对应数据库中表的基类代码的自动生成，包括生成属性、添加、修改、删除、查询、存在性、 Model 类构造等基础代码片断，使程序员可以节省大量机械录入的时间和重复劳动，而将精力集中于核心业务逻辑的开发。
Codematic 同时提供方便的数据库查询管理，SQL脚本生成，存储过程生成，数据库文档生成，Web项目文件发布，代码生成自动导出文件等多项开发工作中常用到的功能，您可以很方便地进行项目开发。
EasyCode 代码生成器和动软代码生成器比较，谁更有优势？
两个虽然都是.Net代码生成器，但是区别还是挺大的啊。动软只是数据库反向生成代码，EasyCode主要功能是设计系统，生成只是其中一部分。动软是生成代码，EasyCode是生成完整的解决方案，还直接支持界面设计和预览。从生成出的代码来看，EasyCode也更加专业，动软的BUG还是挺多的。总体来说，两个不是一个类型的，一个是生成器，一个是辅助设计生成系统。最后，动软虽然功能不如EasyCode，但毕竟是免费的。EasyCode功能的确彪悍，不过要280块的许可费用。如果是专业软件开发人员使用，更多会选后者吧。
上面的那些方法是对数据表的操作（比如Add，就是向数据表里添加数据；Update，修改数据，Delete，删除数据；GetList,根据条件返回一个数据集(DataSet) ）
在VS2008添加项目（比如项目SQL_OPER），将代码复制进项目里的类（比如tab_oper）,把你复制进去的代码的命名空间改为SQL_OPER,类名改为tab_oper(你也可以向里面添加自己的方法)，再找到Maticsoft.DBUtility.dll所在位置（你实在找不到，就在动软的安装目录搜索它），然后添加引用找到它就OK了，最后你就可以SQL_OPER.tab_oper用了
-----------------------------------------------------------
主要是生成数据库的三层结构代码和N层结构代码，主要是其中的通用的如添加、修改、删除、列表等功能的代码自动生成和存储过程自动生成。
自动生成代码的是什么软件
不知道你说的是程序代码自动生成工具还是代码生成工具。
都是有特定场景的，比如数据库的增删改查自动生产的，比如数据库代码生成工具Mybatis-Generator能生成mybatis使用的代码，使用查询编辑器能将可视化的数据库关系及查询转换为查询语句，还有拖动图形界面会自动生成图形界面对应的代码的视图编辑器等。
除此之外，还有记录执行动作后生成脚本，如excel的宏功能，脚本精灵也有这样的功能。
在这里，我定义程序代码生成工具是生成可执行的程序代码，代码生成工具是为程序生成部分被操作代码，便于被程序使用。当然，一般情况下，两者是一个意思，我这里只是大致的区分下。比如生成手机app和生成点击事件还是两个不同的概念，我用两个名词稍微区分下。
以上，有误请指正。
有哪些生成前端代码的神器呢？
在前端开发的过程中，很多相同的代码会写很多遍。如：开始新项目的时候，要写和旧项目类似脚手架代码；新建一个组件的时候，要按约定写组件结构。如果这些重复代码能用工具来生成，能提升前端的开发效率。
生成代码的工具分为两类：基于命令的和基于图像界面的。
基于命令的工具的优点是，可配置高，效率快。缺点是，可发现性差。适合配置项目很多，配置可以组合的情况。
基于图像界面的优点是，可发现性强，操作简单。缺点是如果配置项很多，容易变得很难用。
罗嗦了一堆，下面开始介绍正题。
项目脚手架代码生成工具
项目脚手架主要做的项目的构建流程，环境的配置等。做到开箱即用。
基于命令的
yo 曾经流行过的一个脚手架生成工具。支持定义脚手架内容。基于 yo 的第三方脚手架也很多。
vue-cli 。 Vue 项目脚手架。支持自定义脚手架内容，感兴趣的可以读读 从vue-cli源码学习如何写模板。
create react app React 脚手架。比较轻量级，只是整合 webpack 和 react-router。
react boilerplate React 脚手架。比较重量级，整合了webpack 和 react router, redux, redux suga, reselect 等。
基于图形界面的
定制 Bootstrap 3
组件代码生成工具
基于命令的
react boilerplate 的 nam run generate 可生成组件的脚手架代码。
页面代码生成工具
基于命令的
代码编辑器的代码片段(Code Snippent)功能。主流的代码编辑器(Sublime,Atom,VS Code，Web Strom等) 都支持代码片段。也有写好的代码片段的编辑器插件。主流的框架基本都有对应的代码片段工具。
Emmet 提供 HTML，CSS，JS 的自动补全功能。
Bootstrap 3 Snippets
Vuejs Snippets
基于图形界面的
H5营销页面生成工具。有一大堆。
Maka
初夜
兔展
GrapesJS 强大的网页生成器。开源。
LayoutIt 托拽 Bootstrap 组件，生成页面。
gitspring代码自动生成
简单的代码生成工具，主要是用来做代码的自动化生成。根据各自的需求，可以修改里面的源码。
代码是程序员用开发工具所支持的语言写出来的源文件，是一组由字符、符号或信号码元以离散形式表示信息的明确的规则体系。
GIT与CVS、SVN相比最大的不同，它是分布式版本控制系统，集中式可以理解为将版本的管理集中到了统一的位置，缺点就是对于中央仓库依赖强，一旦中央仓库出现问题，即不可以提交也不可以更新，无法进行版本控制，而GIT本地是有本地仓库，及时远程仓库宕掉了，仍然都可以进行版本控制。但是我认为他们都会有单点问题，一旦远程仓库宕掉了，就无法获取彼此最新的代码。
有什么增删改查代码生成器可以推荐？
自动化开发工具，我用过，比较著名的有普元，浪潮楼上平台等。 首先，我要纠正下，ANT并不是自动生成代码用的工具； 那些所谓的自动代码生成器根本原理就是根据实现写事先好的模板，再根据你提供的数据库结构，生成一系列的增删改查方法。的确是可以减少程序员的工作量，但是不能包含复杂或者特殊的业务逻辑，否则程序员全都失业了。