（1）三层架构和MVC模式。

　　　　不知道大家有没有和我的类似经历。记得大学一次看见班长在学习JAVA中的MVC。就很好奇的问：班长，MVC到底是啥子嘛？）班长回答了半天总结出一句话：MVC就是“控制器，视图，模型”，和三层架构差不多。难道MVC就是分别对应了三层架构中的“DAL,BLL和UI”？下面分别分析下三层架构和MVC模式。

　　　　三层架构，在长期的软件开发过程中，人们经历了"UI"--->“UI+BLL”---> “UI+BLL+DAL”三种时代--->.....。

　　　　UI层时代：人们通常把所有的表现、业务逻辑和数据库访问的代码都放在一起。这样做的结果是维护起来是相当困难的，因为一旦遇见需求变更，维护起来将是一件相当麻烦的事情。也许你只想更改数据访问的一段代码，但是可能造成的结果却是你不得不修改大片业务逻辑和变现代码。因此，人们提出了“单一职责”和“职责分离”的原则，决定将表现和业务逻辑分开，这样就形成了“UI层”和“BLL”，他们之间由“服务接口”相连（依赖倒置原则），彼此活动互不影响。于是，聪明的人们就进入下一时代。

　　　　UI+BLL层时代：表现和业务逻辑的分离让我们更好的完成开发，但是为了降低数据访问和业务逻辑间的冗余，人们开始进入三层架构甚至多层架构的时代。

　　　　有了三层架构，人们可以很轻松的面对需求变更（也有可能出现各层级联修改的情况，这就要考软件设计师的功夫了，做到“开放关闭”），但是回到最开始的WEB层时代，现在的“表现层”就相当于当时的"WEB层"，只是外面将业务逻辑和数据访问等代码分离。但是，表示层依然会出现后台代码和展示混在一起的情况，但是至少不会或很少出现维护繁琐的情况。为了更好的实现“职责分离”，MVC模式诞生了。 Model层实现系统中的业务逻辑，View层用于与用户的交互， Controller层用于接收VIew提交的用户数据并转发给相应的Model，同时接收Model的数据处理结果转发给View。这样表现层的代码彻底做到“职责分离”了。

　　　　下面我们做三种假设：第一、项目中，仅仅运用MVC模式。第二、项目中，仅仅运用三层架构。第三、项目中，同时运用MVC模式和三层架构。

　　　　假设一，在项目中，所有的业务逻辑和数据库访问均由Model承担。这样的Model是不是略显臃肿呢?如果我仅仅改动数据访问会不会影响大片的业务逻辑代码呢？个人认为，不可取。

　　　　假设二，在项目中，仅运用三层架构，如上所说，至少逻辑上的变化不大，有问题也是表示层内部的事情。个人认为可取。

　　　　假设三，在项目中，运用三层架构可以减少逻辑和表现等方面的冗余，运用MVC又可以减少变现层内部的冗余。个人认为可取。

　　　　特别注意：以上三种假设和三种时代的划分，均是在项目足够大和足够复杂的前提下进行的。个人认为，技术架构的选择应该由项目环境决定，而不是越好的技术结构就能开发出越好的项目。比如说用C#开发一个小心的计算器，个人认为没有必要用什么架构和模式了（排除项目需求扩展等情况），如果用什么三层架构、MVC，开发成本就太大了，而且架构在一定程度上也会影响项目的性能 。

　　　　总结：1、三层架构和MVC模式并没有必然的关联，只不过是不同重心和程度上的解耦。三层注重解耦表现、业务逻辑和数据访问。MVC模式注重表现和逻辑（包括业务逻辑和数据访问等等）上的解耦，在一定程度上，三层架构的解耦更深，MVC的解耦更细。

　　　　　　　2、如果三层架构和MVC模式同时运用，MVC则侧重于解耦表现和业务逻辑接口， 和MVP,MVVM等模式一样构成表现层上的解耦。和BLL中的领域模型模式、DAL中的ORM模式等等一样

　　（2）ASP.NET MVC == MVC？？？

　　　　

　　　　仔细看出其实MVC其实由两条路组成：第一、Model和View直接通信。第二、Model和View通过Controller进行通信。而ASP.NET MVC就是第二条路的一个实现（策略模式）。第一条路就是外面常用的ASP.NET Form的实现，通过事件驱动模型（观察者模式）和回发机制（postback）实现Model和View之间的通信，到底微软为啥子不直接叫MVC，这个还真不晓得。 至于两条路同时走，这个我真不知道。

　　　　总结： ASP.NET MVC不过是MVC的一种实现，ASP.NET MVC 不等于MVC。

　　（3）、MVC是属于JAVA的嘛？

　　　　一开始MVC在Java中的运用非常广泛，所以像我这样苦逼的程序员在上学的时候都以为MVC是JAVA的固有特性，其实不然。MVC是一种思想，是无数个苦逼程序员经验和分析的积累。而Java中的MVC仅仅是仅仅是MVC的一种和Castle mvc，ASP.NETMVC一样。

　　　　总结 :MVC是对前人无数经验的思考和总结而得出的一种架构思想。

　　(4)、ASP.NET MVC是否将取代ASP.NET ？

　　　　ASP.NET MVC是否将取代ASP.NET?在项目开发的过程中，外面是否应该放弃ASP.NET，而用ASP.NET MVC？这是我刚看到MVC遇见过的问题。ASP.NET MVC 没有在继续ASP.NET的道路---事件驱动+回发，而是回到最原始的时期，给我们提供了一条新的道路。正如上面第二点所说。两者各有千秋。

　　　　ASP.NET MVC的优势:

　　　　　　ASP.NET MVC由前端控制器模式的思想实现。这使的他具有非常完美的地址映射。

　　　　　　ASP.NET MVC通过控制器、视图、模型的结构，可以更好的组织逻辑，解决复杂问题。

　　　　　　ASP.NET MVC更容易进行单元测试，有利于“测试驱动开发”--OOT；

　　　  ASP.NET MVC的掠势：

　　　　　　在开发过程中无法使用设计--代码的切换，不能做到所见即所得。无法使用控件等进行快速开发。无法使用视图状态（ViewState）等。。。。等等等等。

　　　　总结,从上面的陈诉可以看到，ASP.NET MVC面对开发，出现了很多不能，这些不能可以为我们的开发提供很多的便利，比如开发成本、周期、效益等等方面。可以看出，ASP.NET MVC并不能动摇ASP.NET的地位。个人认为，如果你是一个期望用短期的时间收获比较高的效益，而且你的项目复杂度较低，ASP.NET是最佳的选择。如果面临比较复杂的业务逻辑，ASP.NET MVC可以更好的帮助我们组织并实现它。

　　 貌似，当初的疑惑就只有这些，后面开始慢慢的总结下ASP.NET MVC的东东。