mvc与三层架构的区别

朋友您好！

首先,MVC和三层架构，是不一样的。

三层架构中，DAL(数据访问层)、BLL(业务逻辑层)、WEB层各司其职，意在职责分离。

MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的WEB层，也就是说，MVC把三层架构中的WEB层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。

所以， net的三层结构中，并没有action这个概念。

aspnet mvc 是微软新发布的一种网站开发架构。为了解决传统aspnet开发中不能分离Model,View和Controller而设计的。

普通的网站为了解决可移植，可维护，可扩展等问题，会把网站设计成三个独立的模块，Model负责数据库部分，View负责网页的界面，而Controller负责界面与数据的交互及业务逻辑，这样设计的网站如果想设计或者重新开发某一个模块对其他的模块是没有影响的。但是aspnet的页面后台代码与每个页面代码都是一一对应的，业务逻辑在某些情况下不可避免的被写到了与View关联的后台代码中。这样就不能保证View与Controller的分离，也就很难实现网站的重写和升级。

而在MVC中页面代码并不是与后台代码一一对应，而是分别被存放成Controller和View两个部分，彻底的解决了，View和Controller不能独立的问题。从而改善网站的重写和升级过程。

但是MVC也有其缺点，由于在页面代码中不再可以使用服务器控件，因此给某些aspnet服务器端控件的使用带来了麻烦，而且MVC也页面的设计工作带来了很多障碍。

ASPNET MVC 是微软在2009年4月份发布的一种新的网站开发架构，http://msdnmicrosoftcom/en-us/library/dd394709aspx，它是把传统意义上的MVC开发思想融合到了ASPNET的开发当中。

那么我也来讲讲我对这两者的理解吧。

首先对这个题目，本身是存在问题的，“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模式可以较为随意。

(1)为什么使用MVC而不是用WebForm呢？这个是临时想的，因为咱就是想说明一下WebForm和MVC的优缺点，能够更好地理解MVC和WebForm，而不像某些人说MVC会替代WebForm，个人认为这个可能性很小，因为各有各的好处，看在哪里使用吧，下面就简单介绍下WebForm和MVC的优缺点。

(2)WebForm介绍

1)优点

1)：支持事件模型，取决于微软提供了丰富的服务器端组建，WebForm可以快速的搭建Web应用。

2):使用非常方便，入门也很容易，但是要了解底层还是要付出很大的努力的，这就是NET程序员被称为只会拖控件的原因。

3):微软提供了很大的一部分控件，也有很多公司开发出来了很多的控件来供程序员使用。

2)缺点

1)：封装性特强，很多从底层封装出来的东西让初学者不是非常明白。

2):入门非常容易，但是如果不研究底层的话提升非常困难，所以一定有时间的话要研究底层。

3):复杂的生命周期模型学习起来并不是非常的容易，好多事件。

4):控制不是非常的灵活，服务器控件的控制非常不容易。

5):ViewState处理，在请求和响应之间来回的传递，当使用WebForm开发完网站之后，可以在浏览器中右键查看源代码会看到很多的ViewState，非常浪费资源和浪费服务器宽带。

6):异步请求的时候每个请求后台必须都有一个一般处理程序或者aspx页面对应。

(3)MVC

1)优点

1)：MVC很容易的将复杂的应用分成M，V，C三个组件模型相对应，通过Model，View，Controler有效的简化了复杂的架构，体现了非常好的隔离原则。

2):因为没有使用server-based forms(事件响应模型)，所以能够使程序员控制起来更加的灵活，页面更加的干净。

3):可以控制自定义的URL,也就是MVC中的路由机制，这可以说是MVC的一个亮点，再也不用在WebForm时代的配置静态页的过程了。而且对于SEO友好。能够更加的利用网络爬虫。

4):强类型的View实现，更加的安全，更加的可靠，更加的高效。

5):让Web开发者(程序员)可以更加的专注某一个层的开发，有利于分工配合使用大型架构的开发。

6):MVC下面对异步的处理更加有一个很好的支持，一个控制其下面可以有很多action，而每个action对应的可以有不同的请求。

7):MVC的校验非常的好，只需要给每个方法打入节点就可以实现不能为空等校验。

[requred]

Public string Name{get;set;}

8):表单提交的时候，提供了自动装配的功能。

9):微软提供了很多全局的过滤器(身份校验过滤器，异常过滤器，Action过滤器，视图结果过滤器)，这些都是MVC带来的新功能，使自己的开发能够更加的快速开发。

说说Mvc的优缺点

优点:

1各施其职，互不干涉

在MVC模式中，三个层各施其职，所以如果一旦哪一层的需求发生了变化，就只需要更改相应的层中的代码而不会影响到其它层中的代码。

2有利于开发中的分工

在MVC模式中，由于按层把系统分开，那么就能更好的实现开发中的分工。网页设计人员可以进行开发视图层中的JSP，对业务熟悉的开发人员可开发业务层，而其它开发人员可开发控制层。

3有利于组件的重用

分层后更有利于组件的重用。如控制层可独立成一个能用的组件，视图层也可做成通用的操作界面。

4MVC设计模式可以说实现了分层开发。各个层都有各个层的作用。

5降低了层与层之间的依赖，有利于代码的标准化开发

6再用新的代码业务逻辑替换时，只需要替换相对应的层，大大降低了我们的工作量，分工明确。

缺点:

1增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

2视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

3视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

4目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。

5麻烦，有些代码重复的过多，不利于在实际开发中使用，所以我们要学习框架，下面的鸟瞰图分析了框架在MVC里都替代了哪些层。

MVC主要就是在java开发中的一种设计模式：

M：Modle（模型，主要是Service业务逻辑层和Dao和数据库取得连接并发送数据的层）

V： view（视图，也就是用户看的界面，通常是我们所熟知的前台页面，jsp等）

C： controller（控制层，可以把他看作一个中转，他接收从前台用户发来的请求，并调用service,dao把数据发送到后台，后台经过数据库的操作及业务逻辑分析又将数据返回给controller，最后再返回前台jsp页面）。

ASPNET MVC Framework是微软在ASPNET中所添加的一组类别库，这组类库可以使用Model-View-Controller的设计模式来开发ASPNET的应用程序

Model：包括数据、验证规则、数据访问和业务逻辑等应用程序信息。

View：封装了应用程序的表示层，是呈现给使用者看的信息。

Controller：包括控制流逻辑，控制信息流和应用程序的执行。接受来自用户的指令与数据，并将Model与View做整合的控制器，当服务器接到对ASPNET MVC应用程序的要求时，服务器（IIS）会先使用UrlRoutingModule(ASPNET Routing的 HTTP 模块)，由它来解析是否有包含ASPNET MVC应用程序的URL，若有，则会产生一个MvcRouteHandler对象，这个对象会装载执行的必要信息，并且会呼叫包含在URL中的Controller的Execute方法来执行工作。

Web应用程序MVC化的优点有：

更易操作HTML标记

更方便地与Jquery整合，实现Ajax技术

创建SEO友好的URLS

驱动式开发更容易

Aspnet MVC发展史

ASPNET MVC Framework的第一个版本于2009年3月17日释出RTM版本，新的MVC 20也已在2010年3月11日释出供NET Framework 35版本使用的RTM版本，MVC20在Visual Studio 2010已有集成。接下来的一系列文章使用的工具就是VS2010 MVC20

Aspnet MVC20新特性

MVC20的新特性主要有：

Areas：允许组织多个逻辑层，便于团队开发。

UI Helpers:可以使用strongly-typed helpers修改和展示数据，更易于维护旧有程序，从而提供高开发效率。

服务器端验证：可以使用声明式注解定义模型的验证规则。

客户端验证：自动产生基于模型验证的客户端验证

MVC是三个单词的缩写，分别为： 模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。 View层用于与用户的交互，通常用JSP来实现。 Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。

MVC(Model View Controller)模型(model)－视图(view)－控制器(controller)

MVC本来是存在于Deskt

op程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC copyright: Apple Inc

的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

　　模型－视图－控制器（MVC）是Xerox PARC在八十年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Oracle旗下Sun公司Java EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。

MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。

视图

　　视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services

　　如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。

模型

　　模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。

控制器

　　控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

为什么要使用 MVC

　　大部分Web应用程序都是用像ASP，PHP，或者CFML这样的过程化(自PHP50版本后已全面支持面向对象模型)语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是毋庸置疑的。

　　首先，最重要的一点是多个视图能共享一个模型，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。　由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Adobe Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。

　　因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle，或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松耦合的构件。

　　对我来说，控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。

MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。

　　你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。

　　根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。

　　MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。

　　MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。

对象不同：

MVC包括三类对象，Model是应用对象、View为其屏幕表示、Controller定义了对用户输入的处理方式。在应用MVC方式以前，通常将这三个对象的功能合到了一起，应用MVC分离了它们，为设计提供了灵活性和可重用性。

MVC设计模式是目前最流行的Web应用设计模式，给项目代码的管理和维护带来了很大的便利。

结构不同：

B/S结构（Browser/Server结构）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。

在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。

BS优点：可以在任何地方进行操作而不用安装任何专门的软件。系统的扩展非常容易，只要能上网，再由系统管理员分配一个用户名和密码，就可以使用了。甚至可以在线申请，通过公司内部的安全认证（如CA证书）后，不需要人的参与，系统可以自动分配给用户一个账号进入系统。

BS缺点：个性化特点明显降低，无法实现具有个性化的功能要求。BS操作是以鼠标为最基本的操作方式，无法满足快速操作的要求。BS页面动态刷新，响应速度明显降低。BS无法实现分页显示，给数据库访问造成较大的压力。BS功能弱化，难以实现传统模式下的特殊功能要求。

MVC优点：各施其职，互不干涉；在MVC模式中，三个层各施其职，所以如果一旦哪一层的需求发生了变化，就只需要更改相应的层中的代码而不会影响到其它层中的代码。

MVC缺点：增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

MVC纵向切割了开发过程中的代码，从服务器到浏览器层层分离，层次之间耦合度很低，因为它是顺着底层的开发脉络进行封装，所以有利于开发者对整个程序过程流转的理解。但是MVC有一个非常大的缺点，这个缺点是和整个软件发展思路相背离的，那就是它无法封装、无法封装所以无法被重用。有谁看到过mvc下面的组件？有的只是一个个现成的案例，然后拿来修改。因为一个组件肯定牵涉到控制和显示，但是mvc的开发这两个层次是分离的。MVC只适合轻量级的开发，桌面开发是极少用到mvc模式的。然而web开发恰恰就是轻量级，至今所有的web开发都是轻量级的，因为网络硬件条件的限制，不需要也无法做到非常复杂的逻辑。这也是MVC非常非常适合web开发的原因。 WebForm是微软前面一套web开发的机制。它横向切割了代码，控制和显示是封装在一起的。它从开发者思维逻辑上而不是实际情况上对代码进行封装，开发webform容易上手的原因也就在此了，但这个不利于开发者对底层程序流转机制的理解。WebForm中view和controller是放在一起的，WebForm一出现后，随之而来的是大量的组件诞生，这是mvc模式下看不到的。微软的经验之一是硬件发展很迅速。代码的封装是靠牺牲运行效率来提高开发效率，牺牲的运行效率通过提高硬件性能来解决。但微软在webform上犯了经验主义的错误，这个经验不适合网络硬件，网络硬件要考虑兼容性而且是国家的基础设施，更新的灵活性远比单机要差。大量的组件因为硬件的瓶颈无法给WebForm带来什么优势。在发展了几年webform后，微软觉得这样下去不行，等到网络硬件发展起来不知道到猴年马月了，所以就抄了一下成熟的mvc，通过Entity Framework做数据库和对象的映射，很明显，它是为了充当mvc中那个Model。通过mvc来控制和展示。 webform生产关系是比mvc先进的，但是它不适合现在的网络设施生产力，如果要适合说不定要10年后。webform和mvc很好的印证了生产关系必须适合生产力，即使强大如微软也无法改变客观规律。