三层架构与MVC的区别
http://baike.baidu.com/view/687468.htm
与MVC的区别 MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。
同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。
在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或 MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典 型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
http://topic.csdn.net/u/20090710/14/07f4447d-60c4-4b74-af1c-ea1b6e2e9ca7.html
当然啊，你要明白三层架构的MVC的区别和联系：
三层架构是最基本的项目分层结果，而MVC则是三层架构的一个变体，MVC是一种好的开发模式。首先你要明白MVC分别代表的是什么意思.
M 即Model(模型层)，主要负责出来业务逻辑以及数据库的交互
V 即View(视图层)，主要用于显示数据和提交数据
C 即Controller(控制器)，主要是用作捕获请求并控制请求转发
三层:UI 界面层 BLL 业务逻辑层，DAL数据访问层，Model 实体层
MVC中的的M 不是三层中的Model(实体层)，他其实包括三层中的 BLL，DAL,Model,这是非常要注意的，这也是他们之间的区别的关键所在
其有点有如下：
低耦合性
高重用性和可适用性
较低的生命周期成本
快速的部署
可维护性
有利于软件工程化管理
当然优点也有缺点，那就是内部结构复杂，不容易理解，文件数量大，管理难度自然也就大
三层架构…
他们细分之后得到的是：View(UI)、BIZ（BLL）、DAO（DAL）、Entity（Model）、Controller
MVC把 BIZ（BLL）、DAO（DAL）、Model（Entity） 统一称之为 模型(MODEL)，得到：View、Controller、模型(MODEL)
三层 在我使用中 暂未体会到控制器的存在，完全是：UI、DAO、BLL
他们相同的设计理念就是：把视图设计与数据持久化进行分离，从而降低耦合性，易于扩展，提高团队开发效率。
三层是基于业务逻辑来分的，而mvc是基于页面来分的
根本就没有什么可比性。
其实两个一起用我感觉很好
MVC模式是一种复合设计模式，一种解决方案
三层是种软件架构，通过接口实现编程
三层模式是体系结构模式，MVC是设计模式
三层模式又可归于部署模式，MVC可归于表示模式
没有什么取舍的，说的根本不是一回事。在所谓的“三层”中，它要求你将BLL层独立出来，它只是告诉你表示层和业务逻辑层之间的静 态关系。而MVC则告诉你在这个具体的地方如何处理其动态驱动流程，尽管mvc仍然粗糙（甚至mvp也是粗糙的），但是已经比所谓三层更细致一些了。
谢谢大家的关注，这几天都在忙面试，没来结贴。再次谢谢大家。
我大概明白了：三层架构和mvc设计模式侧重点不一样，三层是一种笼统的架构思想，没有限制具体的设计；而mvc就比较具体的说明它的设计方法。
还是自己动手做一下，理解会更深一些，以前都是用三层架构的方法
---------------------------------------------------------------------------------------------------------------
http://apps.hi.baidu.com/share/detail/15057889
ASP.NET MVC 与 WebForm 三层架构 区别
1.传统WebForm开发中存在的一些问题
传统的ASP.NET开发中，微软的开发团队为开发者设计了一个在可视化设计器中拖放控件，编写代码响应事件的快速开发环境。然而，它所带来的负面效应是：
由于控件封装了很多东西，开发者很难了解这背后的HTML是如何运作的
容易得到一个包含大量ViewState的页面，使得页面尺寸远远超过所需的内容，使得页面的打开速度较慢
不容易被测试
2.什么是MVC?
MVC（Model-View-Controller，模型-视图-控制器模式）是软件工程中的一种软件架构模式。它把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
3.什么是ASP.NET MVC?
ASP.NET MVC是微软的开发团队基于MVC开发的一个易于被测试的框架。它具有以下特性：
没有数据回传
没有在页面中保存视图状态
开发者可以完全掌控页面的呈现过程
易于单元测试
易于测试驱动开发
可扩展、可替换
支持WebForm中的有关特性，如：用户控件、母版页、数据绑定、本地化等
不在基于文件目录结构，而是将URL映射到控制器中
4. 为什么使用ASP.NET MVC?
易于进行单元测试
易于进行测试驱动开发
避免了WebForm中大量的ViewState导致页面文件变得臃肿
5. MVC与三层架构?
MVC是一种模式
ASP.NET MVC是一个基于MVC模式的开发框架
三层架构是一种架构
至于区别，可以严格的从概念上区分开来。
下图是MVC与三层架构的对应关系
6. MVC与Webform如何抉择?
7. 两种技术并存
ASP.NET MVC框架只是给开发者提供欧诺个了开发web应用程序的一种选择，并不是要取代Webform
这两种技术各有优缺点，开发者需要根据实际情况，选择对应的技术
有时候，可以在同一个项目中混合使用这两种技术
8.ASP.NET MVC与Webform技术的架构图
总结：
看完本文，相信ASP.NET WebForm与ASP.NET MVC的选择相信大家应该可以做到心中有数了，我始终觉得，很多时候并不是什么技术好不好的问题，而是适合不适合不适合的问题或者能否把它用好的问题。
打个比方：如果让千里马犁地，恐怕未必能达到理想的效果，最终可能还会抱怨，什么破马，一点劲都没有。
========================================================================
http://blog.sina.com.cn/s/blog_677b66170100mv16.html
asp.net mvc和三层架构联系与区别
首先,MVC和三层架构，是不一样的。
三层架构中，DAL(数据访问层)、BLL(业务逻辑层)、WEB层各司其职，意在职责分离。
MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的WEB层，也就是说，MVC把三层架构中的WEB层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。
所以， .net的三层结构中，并没有action这个概念。
asp.net mvc 是微软新发布的一种网站开发架构。为了解决传统asp.net开发中不能分离Model,View和Controller而设计的。
普通的网站为了解决可移植，可维护，可扩展等问题，会把网站设计成三个独立的模块，Model负责数据库部分，View负责网页的界面，而
Controller负责界面与数据的交互及业务逻辑，这样设计的网站如果想设计或者重新开发某一个模块对其他的模块是没有影响的。但是asp.net的页面后台代码与每个页面代码都是一一对应的，业务逻辑在某些情况下不可避免的被写到了与View关联的后台代码中。这样就不能保证View与Controller的分离，也就很难实现网站的重写和升级。
而在MVC中页面代码并不是与后台代码一一对应，而是分别被存放成Controller和View两个部分，彻底的解决了，View和Controller不能独立的问题。从而改善网站的重写和升级过程。
但是MVC也有其缺点，由于在页面代码中不再可以使用服务器控件，因此给某些asp.net服务器端控件的使用带来了麻烦，而且MVC也页面的设计工作带来了很多障碍。
ASP.NET MVC 是微软在2009年4月份发布的一种新的网站开发架构，http://msdn.microsoft.com/en-us/library/dd394709.a spx，它是把传统意义上的MVC开发思想融合到了ASP.NET的开发当中。
那么我也来讲讲我对这两者的理解吧。
首先对这个题目，本身是存在问题的，"XX结构"与"XX模式"的区别？请问中国社会制度与美国人生活方式有什么区别？
这两者本身讲的是不同方向与角度的问题，在实际应用中他们的确存在一些相似的特点，在很多书籍中也没有深入讲解，以致于造成困惑，为了更好的理解他们，姑且来说说区别吧。
首先N层结构是一种软件抽象的层次结构，是对复杂软件的一种纵向切分，每一层次中完成同一类型的操作，以便将各种代码以其完成的使命作为依据来分割，以
将低软件的复杂度，提高其可维护性。一般来说，层次之间是向下依赖的，下层代码未确定其接口（契约）前，上层代码是无法开发的，下层代码接口（契约）的变
化将使上层的代码一起变化。三层结构是N层结构的一种，是人产在长时间使用中得出来的一种应用场合广泛的N层结构，被当作一种典型的软件层次结构而广为流
传甚至写入教科书。
MVC模式是一种复合设计模式，一种在特定场合用于解决某种实际问题来得出的可以反复实践的解决方案。巧合的是他也有三个事物组成，于是乎人们就有了一种想当然的对应关系：展示层-View；业务逻辑层-Control；持久层-Model。首先MVC中的三个事物之间并不存在明显的层次结构，没有明显的向下依赖关系，相反的，View和Model往往是比较独立的，而Control是连接两者的桥梁，他们更像是横向的切分。这样一来就出现一个结果，MVC中每个块都是可以独立测试的，而三层结构中，上层模块的运行测试势必要提供下层代码或者提供相同接口的桩。相对来说，MVC复杂得多，但是结构更清晰，耦合性更低。
另外，MVC中每一块内部特别是Model内部经常被设计为多层的。在我认为的一个良好的MVC模
式构建的结构中，Control是核心，小且较为稳定的，可以作为一个核心框架来提供，有扩展点，但基本上可以简单配置不需要任何代码就可以运行。而
View则可能是一套或多种可选择的视图引擎，决定了软件展示给用于的界面，使用时的主要工作量在于扩展点以及根据需要而数量不同的视图模板。Model
则是业务提供者，决定了软件提供的功能，其内部可能是一些普通的类或者是实现了某些接口的类，在这一块当中可能根据业务的不同而色彩缤纷，对于复杂的软件
可能会分成很多层，如业务逻辑层、业务提供层、系统提供层、数据提供层、数据访问层等。
我经常用于比喻MVC的例子是小时
候玩的那种卡带式游戏机，Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。View则是电视机和游戏手
柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大
的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，要遥杆还是带震动的。Model则是游戏卡带，他绝定了我玩的是什么游戏，是
魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要
而设计。
有朋友提到游戏主机提供的卡带插槽的接口，在设计中，有时也由Control提供一组接口，以用于Model或View的实现，这样
就形成了依赖。一般来说这样设计也没有太大的问题，只是会提高模块间的耦合度，也会带来一些侵入性。为了更完美，可以不用接口来提供契约，可以用配置信息
（或称元数据信息）+反射来提供契约，那么这个类接口就可以退化到只要符合CLS就可以了，也就是普通的类，就像现在的计算机接口广泛采用USB，无论是
U盘、打印机、扫描仪或者是加密狗，他们都是普通的USB设备而已。
提到USB有一个题外话，模块的可插拔性设计甚至是热插拔设计，系统可以在不停止运行的情况下动态的挂载或移除模块，动态挂载模块需要系统能够自动发现新模块并根据自描述的信息进行自动配置，移除可能情况更复杂一点，需要"安全删除硬件"类似的功能。
在设计广泛重用的框架时会考虑多种情况以达到更大的适应性，一般项目中应用MVC模式可以较为随意。