三层架构中，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模式能够较为随意。html
因此呢，你能够彻底不用ORM那套东西，直接用代码生成器，生成三层架构，把WEB层换成mvc模式的，like this:linux
