为ASP.NET MVC RC分离Controllers-Views项目后添加“脚手架”功能
连续忙了好几个月，好久没有写东西了，最近稍微有点空，空闲的时候回到了对ASP.NET MVC RC（以下简称MVC RC）的研究上来。MVC RC的“脚手架（Scaffold）”功能可以说为MVC RC的开发如虎添翼，不过应用到真实的开发环境中似乎存在一些遗憾的地方：很多时候我们并不希望把Models、Views和Controllers放在同一个项目里面，而是把它们分离到不同的项目，然后由一个项目（比如Views）统一引用其他所有的项目程序集。但是这样做了以后，Controllers项目中脚手架的功能就“消失了”。
在Web（MVC RC）项目中，我们可以这样在Web项目中使用脚手架创建View页面：
或者创建Controller文件：
甚至可以在Controller文件中自动创建或者查看对应Action的View页面：
不过这一切经历了Views和Controllers的“生死离别”之后，就再也无法在Controllers中使用了（原因会在下文中说明）。下面我们来做一个测试。
首先我们先把M、V、C三层分离，比如这样：
需要注意的是当这样做的时候，在Controllers项目中需要引用以下这三个核心的程序集：
System.Web.Abstractions.dll
System.Web.Mvc.dll
System.Web.Routing.dll
以及一些在默认的Controller.cs文件中被引用到的命名空间，如：
System.Web
System.Configuration
以下是分离M-V-C（M之所以也要分离出去是因为C需要引用M，而C不能引用V）之后，运行的默认界面，说明这样的分离是成功的：
OK，到此为止MVC工作正常，只不过……无法在MyMvc.Controllers中使用MVC的脚手架：
分析一下原因：我们在把Controller分离出来的时候是建了“类库（Class Library）”，一个普通的类库当然无法使用MVC（Web）的脚手架，于是我打开了MyMvc.Web的项目文件MyMvc.Web.csproj，用记事本打开这个文件（本质上是一个XML文件），发现了一个和其他项目与众不同的地方：
<ProjectTypeGuids>{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
这个节点中用分号分割了3段看似Guid的代码，分别是：
{603c0e0b-db56-11dc-be95-000d561079b0}
{349c5851-65df-11da-9384-00065b846f21}
{fae04ec0-301f-11d3-bf4b-00c04f79efbc}
立刻对比了一下MyMvc.Controllers下面的MyMvc.Controllers. csproj，发现没有这个节点。喜出望外！于是马上将这个节点复制到MyMvc.Controllers. csproj对应的地方，重新加载项目以后，发现MyMvc.Controllers的脚手架功能回来了！
不过通过这样简单的添加还是发现了一些小小的瑕疵：细观MyMvc.Controller的项目图标类型，怎么和Web的时一样的(下图)？不爽。
看来这样的直接复制是把整个MVC Web Application下面的类型都一起复制过来了，为了避免日后不必要的麻烦，还是需要让Controllers变回“类库”，于是打起了那三个Guid的注意，经过两次两两搭配后（{fae04ec0-301f-11d3-bf4b-00c04f79efbc}一定要保留）发现，只要删除中间的{349c5851-65df-11da-9384-00065b846f21}之后，MyMvc.Controllers项目又回到了“类库”的状态：
于是猜测{fae04ec0-301f-11d3-bf4b-00c04f79efbc}对应了Web Application的项目类型，而{603c0e0b-db56-11dc-be95-000d561079b0}对应了MVC RC的模板。
注意：{603c0e0b-db56-11dc-be95-000d561079b0}对应了MVC RC(v1.0)的项目代码，
如果您使用的是MVC 2.0（包括Preview版本在内），对应的编码为：{F85E285D-A4E0-4152-9332-AB1D724D3325} ！
如果您使用的是MVC 3.0（包括Beta和RC版本在内），对应的编码为：{E53F8FEA-EAE0-44A6-8774-FFD645390401} ！
通过以上这些操作，分离了M-V-C结构，并且在Controllers中“完整”保留了MVC RC的脚手架的功能。
上面的“完整”之所以要突出一下，是因为这种保留实在是太“完整”了，以至于在Controller中自动添加View页面会添加到Controller项目中，而不是我们所希望的MyMvc.View项目中（查看对应View页面也存在相同的问题）。这倒是个大问题，如果这个问题不解决，那么“脚手架”反而成了“绊脚石”，这个问题如何解决呢？
中讲到如何分离Controllers和Views项目，并且为Controllers项目添加MVC RC的“脚手架”，可惜“脚手架”的功能保留的过于完整，以至于自动创建和察看View页面都会在当前项目中进行，除非你心甘情愿每次创建完成后手动将文件转移到Views（Web）项目，否则这个“脚手架”的意义几乎就失去了。并且，及时转移了.aspx之类的View文件，那么查看还是在当前项目中进行，这可怎么办呢？本文将为此创造一个“一石二鸟”的方法，可以同时解决View页面新增和查看的问题。
View查看
由于没功夫研究这个“脚手架”内部的机制（如果有朋友能够实现hack的话也就不用这么麻烦了，呵呵），所以想到了一个变通的方法：能不能在Controller对应的地方加上一些“快捷方式”，然后当查看的时候直接查找源文件呢？经过了一些尝试，发现直接创快捷方式文件（.lnk）是行不通的。
于是又打起了MyMvc.Controllers.csproj的主意。经过一些测试研究，发现. Csproj文件支持一个<Link>的标签，可以在VS程序中起到“快捷方式”的效果（具体如何设置节点在本文后面提供的解决方案程序和下载代码中可见，这里不再详述）。
经过一系列测试，这些被Link的文件不会被编译到MyMvc.Controllers.Dll中，OK，View的问题就此告一段落，剩下的工作由统一的解决方案来完成。
View新增
既然MyMvc.Controllers中的View都是没有实际意义的快捷方式，那么新增的文件显然也不能让他留在MyMvc.Controllers项目中，于是想到了“乾坤大挪移”——把新建的View自动移动到MyMvc.Web项目中，并且在MyMvc.Controllers.csproj中将对应的文件编程一个“快捷方式”。
最终解决方案——MvcScaffoldTool
MvcScaffoldTool是本人原创，并开源的一个用于解决之前提到的脚手架创建、查看文件路径问题的小工具，也同样适用于其它一些类型项目的其他地方。
既然要从外部入手，那么最直接、最自动的方法当然是写一个程序，用于自动“监控”MyMvc.Controllers中的状态，当其发生变化的时候自动转移文件并且处理对应的. Csproj文件。
由于很少做WinForm，所以粗制滥造了一个：
双击该图表可以恢复操作窗口的显示，同时暂停监测。
注意：以上方法在VS2008（Sp1）和VS2010中测试成功，由于尚不知道VS2005及以下版本是否有办法安装官方提供的MVC RC及其“脚手架”，所以未作测试，也欢迎反馈。
MvcScaffoldTool的使用方法
MvcScaffoldTool的使用很简单：
1、将MvcScaffoldTool.exe复制到解决方案（一般即所有项目文件的上级目录）：
2、在需要使用Controllers中的脚手架创建View页面之前运行MvcScaffoldTool.exe（和项目一起开启也可以），并选择正确的项目文件夹和项目文件：
程序会优先选择.csproj类型的文件作为项目文件，如果有多个，可以自行选择。
3、单击“确认并启动”按钮，MvcScaffoldTool.exe会创建一个xml文件并在后台运行。如果已经创建过xml文件，以上的设置会从xml文件中读取，不必每次开启都设置。
------------------------------------------------------------------------------------------------
接下去的操作和普通使用MVC RC开发几乎一模一样。
4、使用Controllers项目中的“脚手架”从Action中创建View页面：
5、Controlllers下面会自动创建对应的View页面：
奇怪，怎么MvcScaffoldTool.exe怎么没有起作用呢？别急，请看下一步：
6、现在删除文件还来得及，如果确认添加，点击“全部保存”按钮：
7、不出意外地话，你马上会看到这样的提示：
以及:
不用担心，这说明修改已经成功，单击“重新加载”即可。
重新加载项目后的结果：
可以清楚地看到，MyMvc.Controllers下面刚才创建的.aspx文件已经转移到了MyMvc.Web下面，同时原来的文件成了一个快捷方式。点击这个快捷方式即可查看MvcScaffoldTool.aspx的原文件。
8、怎么还没有完？对！还有“Go to View”没有测试呢！
单击MvcScaffoldTool()中的Go to View：
这时候虽然“解决方案管理器”中的当前文件是MyMvc.Controllers下面的一个快捷方式，不过打开的文件却是MyMvc.Web下真实的View文件：
实现代码已经提供下载，这里不再占用大贵的视野。
由于时间有限，暂时只做了一些基本的功能。原理大致如下：
指定Views(Web)和Controllers项目文件夹及文件，监视Controllers项目文件对应节点的变动，当发现有新文件加入的时候，立即将该文件转移到Web项目下，并且修改两个项目的项目文件（.csproj），为Controllers项目中的对应文件建立“快捷方式”，同时为Web项目创建真实的文件包含。
除了以上这些基本功能，还有一些可以扩展和优化的地方，比如当Web下面删除一些View页面的时候，使Controllers中的快捷方式也同步删除，原理与上面类似。另外，MvcScaffoldTool自动隐藏后会运行在后台，目前只能通过“任务管理”将其关闭(此功能已升级)并缩小到系统开始栏的系统托盘：