风云

总结的很好，楼主辛苦了。

正在给我的项目，写代码生成器。嘿嘿，学习，

以前做过第一种，面向逻辑的.
现在在做第二种，但是又好像不一样，我是很多存储过程。
而且主要还是靠视图做桥梁，存储过程是为了业务服务，而非仅仅为了代码生成。采用面向对象封装的逻辑，方便以后将对象属性，配置化（比如新加的枚举配置管理）。

另外其他几种都不太懂，如果时间方便，心情方便，帮忙鉴定一下我的是那一种，有什么优缺点。谢谢（要帮就在我博客有下载）！！

明天去公司学习你的DEMO--NDO.Tools

http://www.spdevelop.com 上的那个代码生成工具也挺不错的。

@a[匿名]
这个代码生成器不错,它属于我所说的第四种,自己写了一个模板引擎,这个引擎很像CodeSmith的模板引擎

@Clark Chan
Clark Chan 你好,我刚找到你的代码生成器,我看了一下,做的也不错,该类型属于第一种,是一种比较传统的那一种,如果把代码生成的展现逻辑用模板引擎就好了!

@风云
感谢指导！学习中。

今天学习了几个代码生成器，一个都没有搞明白。
最后在本机G:\My Documents\CodeSmith\Samples\v4.0\Projects\CSharpCodeGeneratorSample\businessobject.cst

里面是这样写的
<script runat="template">

public string GetCamelCaseName(string value)
{
return value.Substring(0, 1).ToLower() + value.Substring(1);
}

===================================
public string GetReaderMethod(ColumnSchema column)
{
switch (column.DataType)
{
case DbType.Byte:
{
return "GetByte";
}
case DbType.Int16:
{
return "GetInt16";
}
case DbType.Int32:
{
return "GetInt32";
}
case DbType.Int64:
{
return "GetInt64";
}
case DbType.AnsiStringFixedLength:
case DbType.AnsiString:
case DbType.String:
case DbType.StringFixedLength:
{
return "GetString";
}
case DbType.Boolean:
{
return "GetBoolean";
}
case DbType.Guid:
{
return "GetGuid";
}
case DbType.Currency:
case DbType.Decimal:
{
return "GetDecimal";
}
case DbType.DateTime:
case DbType.Date:
{
return "GetDateTime";
}
default:
{
return "__SQL__" + column.DataType;
}
}
}
=====================================
</script>
给我很强的震撼，因为我的生成器里面就是这样写的！！
只是不知道他如何把脚本翻译成C#代码执行的。

我终于理解风云兄的意思了：
像这样：
protected <%= GetPrimaryKeyType(SourceTable) %> _id;
<% foreach (ColumnSchema column in SourceTable.NonPrimaryKeyColumns) { %>
<%= GetMemberVariableDeclarationStatement(column) %>
<% } %>
把代码展现逻辑公开！！才好.

注：以上代码都来自codesmith的脚本中。

@Clark Chan
哈哈!!是的,这样降低了系统的耦合度,以后如果想改变输出模型,可以不用动引擎,直接该模板就可以了!

@风云
要把这个解析引擎做出来，真不是盖的啊（真不容易）。
1》既要能处理脚本转C#执行。(处理固定函数)
2》又要能解析<%%>等字符按换，传递参数<="123"> 键值对。(处理变量)
3》还要能读取固定代码，输出固定代码。(处理固定代码)

开发spdevelop.com 的家伙，真猛，居然把引擎搞出来了！佩服！

我现在都想放弃给我的项目做代码生成器了，复杂。而且我最终的目的仍然是我的项目，而非代码生成器。犹豫了~~·是否应该直接用别人的生成器，完成我的项目呢，嘿嘿！用引擎的代码生成器太强了。

@Clark Chan
是,厉害,很佩服,国内有这样的人真是感到很高兴呀!

@风云
说的很有道理，我确是花了太多时间在这个鬼代码生成器上面了，
是因为我当初开发NToggery1.0的时候也开发了一个代码生成器：EntityCode2.0,当时她确是让我很快完成了20个表的业务逻辑以下的所有代码。但是这些代码基于SQL语句的方式，有很多自定义的地方，我只好手动修改，虽然也不需要太多的时间，但是感觉还是到处在补丁。

我深刻的体会到前期程序架构合理性 和 前期代码生成器的好与坏，
将直接影响后期的代码开发的速度。所以现在开发NToggery2.1 我花了2个月的时间在生成器上，实在累。现在面对codesmith和spdevelop等强大引擎下，觉得自己要继续开发好的生成器，太难了（时间需要太多了，而且不能总停留在生成器上面，最终是期望能早日开发出完整成熟的进销存），似乎别人做好了，我却在那里受难（困难的难）。实在没效率（今天想了一天也没能有个修改方向~~）。

只要NToggery设计合理性，稳定了。代码生成器能凑合就先用起来的。不敢大改了。（但是代码生成器不稳定，以后大改动也会对进销存造成威胁，只好找平衡了。）

如果NVelocity或StingTemplate等开源引擎，能实现 楼楼楼楼楼上(codesmith)的 类似代码处理，到是非常愿意尝试使用的。能合理使用第三方的技术，是最好不过了，嘿。

ps：别人的生成器，最大的麻烦，我想是学习成本，和维护成本！！（搞了n天都没有学会codesmith和spdevelop 生成一次代码~~~~~)

最后：很佩服你应用“NVelocity或StingTemplate这些比较稳定的开源模板引擎,”的效率，真快，嘿嘿。
感谢你的指导意见。（今天虽然，没有代码上面的进步，不过思想丰富了许多，谢谢风云兄）

不错,分析的很透彻!

丰富了不少思想呀!

好文章呀

不错