Magicodes.NET框架之路——让代码再飞一会（ASP.NET Scaffolding）
首先感谢大家对Magicodes.NET框架的支持。就如我上篇所说，框架成熟可能至少还需要一年，毕竟个人力量实在有限。希望有兴趣的小伙伴能够加入我们并且给予贡献。同时有问题的小伙伴请不要在群里询问问题，QQ群仅限于技术交流。
所有有关Magicodes.NET的问题，请在此https://github.com/magicodes/Magicodes.NET/issues页面根据类型提交相应Issues。在使用Magicodes.NET之前，请先查看官方文档并且阅读FAQ（点此阅读）。
上篇提到了T4代码生成，随着生成的深入，我愈发觉得这种生成模式存在问题：
- 太过依赖前端脚本（增删改查都在同一个页面处理，后台控制器只是返回View）
- 不便于更换页面主题（前端太重）
- View对服务器端代码支持不够好（因为基本上都是依赖前端JS绑定的）。
- 不便于扩展或者扩展起来比较麻烦。比如新增和编辑时，下拉框的绑定，复选框组的绑定（当然这些都有解决办法），都需要编写大量通用的脚本。随着数据模型的复杂，这种方式维护会越来越麻烦。
基于以上原因，本人决定放弃此模式，开始新的T4模板生成研究之旅。
很多时候，只有重新再来，才能站得更高。所以我说框架成熟可能至少还得一年，因为我还在不断的尝试和学习。也希望小伙伴们能够多多支持，大牛们能够多多指导。
在研究的时候，我将目光定格到了ASP.NET Scaffolding上……
ASP.NET Scaffolding Template（ASP.NET基架模板）
ASP.NET Scaffolding。可能很多小伙伴们没听说过，但是其实你已经在用它呢。这玩意儿是微软的一个工程师编写的，然后集成到了VS2013中。这是个什么玩意儿呢？看看下面的图你可能就想起来了。
添加控制器的时候：
然后选择模型类，DbContext等：
点击添加后，你就会发现他干了很多碉堡了的事：
控制器和增删改查都生成好了！！！
我们来看看生成的控制器代码：
增删改查一应俱全，而且还考虑到了安全性。同样的，相关视图也生成好了，能够展示简单的列表以及增删改。
具体请看：http://www.asp.net/visual-studio/overview/2013/aspnet-scaffolding-overview
我们来看看生成的原始界面：
虽然灰不溜秋，但是不失为一种很强大的方式。好像瞬间把代码生成拉高了几个档次，个人觉得这种方式相当不错。给我的第一感觉是，妈的，好高大上啊，老子要自定义。
自定义ASP.NET MVC基架
关于ASP.NET MVC基架的资料国内还比较欠缺，FQ研究了一会，也有一点成效：
是不是瞬间又高大上了很多？人靠衣裳啊，别介意，这个还不够美。只是粗浅的。想想，如果能够根据控件类型生成相应JS控件，再加点逻辑控制，那就完美了！！
废话不说，我们先来看看怎么自定义这玩意儿。
第一步，安装SideWaffle：
可以在这个网址下载：http://sidewaffle.com/
第二步，选择ASP.NET基架T4文件：
然后，你就会发现项目工程里多了一个CodeTemplates目录，里面有很多T4文件：
这就是MVC基架T4模板（包括WebAPI等等），然后我们就可以Happy的定制了，只是目前是：
比如编辑模板，我们可以加点样式点缀点缀：
于是就成了上面的样子。
刚Happy不久，然后发现问题来了！！！
ASP.NET MVC基架模板的问题
比如在List.cs.t4模板里，我需要获取模型类的类特性，方便干点坏事。比如获取列表标题啊等等，然后我发现我杯具了。先来看看模板参数（在文件Imports.include.t4中）：
<#@ parameter type="System.String" name="ViewDataTypeName" #>
<#@ parameter type="System.String" name="ViewDataTypeShortName" #>
<#@ parameter type="System.Boolean" name="IsPartialView" #>
<#@ parameter type="System.Boolean" name="IsLayoutPageSelected" #>
<#@ parameter type="System.Boolean" name="ReferenceScriptLibraries" #>
<#@ parameter type="System.Boolean" name="IsBundleConfigPresent" #>
<#@ parameter type="System.String" name="ViewName" #>
<#@ parameter type="System.String" name="LayoutPageFile" #>
<#@ parameter type="System.String" name="JQueryVersion" #>
<#@ parameter type="Microsoft.AspNet.Scaffolding.Core.Metadata.ModelMetadata" name="ModelMetadata" #>
从参数不难看出，我们能够用的就是这些了。默哀一会。然后我们发现微软那哥们给我们打开了一扇窗子，自己却被门夹了脑袋。我们唯一可以寄托希望的参数在类型：Microsoft.AspNet.Scaffolding.Core.Metadata.ModelMetadata
咦，这玩意儿咋这么眼熟，咋一看跟MVC的ModelMetadata还有EF的ModelMetadata有点像。但其实差的有点远。
就给我这么点东西，模型类型都拿不到，你让我咋玩！！！同样的属性也是拿不到类型的，妈蛋，让我白高兴了一把。微软那哥们，哥知道参数T4模板不好写，参数传过来还经过了序列化，不大好传递类型，不然反序列化会有问题，但是你丫的也想想办法呀，都是你家东西，你就搭了一个宏伟的架子，然后就没了，让哥情何以堪！！果然只是基架。为此，哥还在stackoverflow上用蹩脚的英语提了一个问题：
这是博客园的飞机票：http://q.cnblogs.com/q/69370/
好吧，为了便于T4模板参数传递，微软那哥们是将ViewModel的属性处理好然后通过参数传递过来的，T4模板参数用到了序列化和反序列化，如果传递模型类型，就得把相关dll丢GAC里面，于是就成现在这样了。自然，理论上应该是无解，于是无奈放弃。
尾声
看来伟大的想法行不通啊，看来还是自己老老实实重新写过吧。目前控制器这块的T4生成已经重构了，准备开始重新编写View的T4模板了。开启全新模式，我将在下篇介绍新的T4模板生成。
╮(╯▽╰)╭，蛋疼。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
