1. 系统常见的分层
在开发asp.net mvc应用的时候，visual studio 给我们创建了默认的文档结构，一般情况下我们在一个项目下工作，参考微软的官方例子：ContosoUniversity.sln
一般情况下我们可以将DAL单独出来作为一个项目，最多还加一个接口Layer的项目，构成了简单的三层架构模式。或者跟进一步讲一部分业务独立出来成为一个Business 层。分离出来的好处，相信大家都有体会：
1. 独立出来的Layer或说组件，便于替换。特别是通过接口层的引入后，能够做到程序不依赖于具体的实现类。特别是通过一些Ioc容器的注入，基本可以做到客户端（调用接口的一端）程序的零修改。这也是设计模式里讲的对扩展开发，对修改关闭原则，里氏替换原则-依赖于抽象而不是具体的原则。
2. 大的项目中，方便于多个团队的开发。比如不同的团队可以开发不同数据访问层，业务逻辑层。特别是在分布式系统开发过程中，服务端提供给客户端只是方法的接口。
3. 可维护性，当某个模块出现bug的时候，你只需改改对应的位置，然后compile，然后copy到服务器上去，不需要整体编译。
4. 版本化，不同版本的服务层可以给客户提供不同的服务。通过客户的不同身份，定位到不同的Controller。
等等，各种好处就不一一细说了。
2. 系统的进一步分层，将Controllers，Filters，Models分拆
接下来，我们来个更彻底的分离这个唯一的项目到多个项目。我们新建一个MvcApplication2项目来做试验
我们将里面的Controllers，Filters，Models作为三个项目独立出来
我们为什么要将Models独立出来？有时候出前台提交数据到Action直接包装成了Model，如果涉及到数据的更改，业务的操作，我们直接将此model作为DTO（Data Transfer Object）会比较方便。为什么将Filters，controller独立出来？大家可以参考上面的论述去琢磨下。不需要修改任何代码，只需要各个项目里面添加对应的引用即可，然后F5运行，没有任何问题。
3. 系统更进一步的分拆，将Area独立到各个模块。类似于插件式的系统开发
我们模拟两个模块Admin和api，右键添加Area…，输入Admin，右键添加Area…，输入API，新增解决方案文件夹Admin，api，然后在这两个文件夹下新建两个Application，MvcApplication1.Admin和MvcApplication1.API，然后将Areas->Admin, Areas->API下面的文件全部剪切到刚刚创建的两个项目下面。如下图
接下来，我们需要修改路由的注册部分。将主程序里面Controller的寻找的命名空间给明确下。
同理修改Admin和api模块的AreaRegistration。
再接下来，我们要添加这两个子模块的Build Events Post-build event：
mkdir "$(SolutionDir)$(SolutionName)AreasAdminViews"
xcopy "$(ProjectDir)Views" "$(SolutionDir)$(SolutionName)AreasAdminViews" /S /E /C /Y
将对应的View Copy 到主目录。这是ASP.NET MVC Area寻找View的机制，除非我们自定义ViewEngine。
然后build all，F5运行。
如果你认为上面的做法比较麻烦，那么可以采用第二种方式，引用第三方库MvcContrib。
在Package Manager Console里面输入：Install-Package MvcContrib，但是本人在mvc4下没有试验出来。下篇介绍asp.net mvc插件式架构