MVC与三层架构？

MVC和3层架构之间的基本区别是什么？

三层是一种架构风格 ， MVC是一种devise模式 。

所以是不同的。

但我们可以在三层架构风格中使用mvc模式。

所以：

演示层 ：MVC模式中的“控制器和视图”。

业务层 ：MVC模式的“模型（数据）”。

数据访问层 ：原始数据访问层。

在较大的应用程序中，MVC只是一个N层体系结构的表示层。 模型视图和控制器只关心表示，并利用中间层来利用数据层中的数据填充模型。

MVC也可以被用作整个三层体系结构，其中视图是你的演示，控制器是你的业务逻辑，模型是你的数据层（通常由诸如entity framework之类的DAL生成）。

理想情况下，虽然你希望你的控制器很瘦，愚蠢，把逻辑传递给一个“业务组件”，这基本上会成为你的中间层。

在三层架构中，层之间的通信是双向的。 在MVC中，通信是单向的; 我们可以说每个“层”由左边的那个更新，并且反过来更新右边的那个 – “左”和“右”仅仅是说明性的。

3层体系结构通常在3个独立的networking节点上部署为3个独立的进程。 但是MVC被devise为在单个networking节点中作为单个进程部署。 （如桌面应用程序）

3层的业务层通常包含实现业务委托，业务外观，业务对象，服务定位器，数据传输对象等着名模式的不同层次。但是MVC本身就是一种用于表示层的devise模式。

3层的目标是将业务逻辑从客户端和数据库中分离出来，从而提供多种客户端协议，高可扩展性，异构数据访问等。但是MVC的主要目标是实现部分的更改不需要改变另一部分。

与迈克尔在回答中所说的相比，我采取了一种不同的方法。

控制器永远不会成为您的业务逻辑。 对我来说，业务逻辑属于模型层。 尽pipe如此，MVC应用程序中的视图（以及某种程度上的控制器）和表示层的一部分，模型从来不是它的一部分。 模型应该是MVC应用程序的核心和灵魂，这就是域驱动devise的全部内容，可以在MVC应用程序中轻松实现。

请记住，您不必在同一个项目中使用模型（对于ASP.NET MVC）。 它可以驻留在完全不同的项目中，它仍然可以作为应用程序的模型

作为表示层的MVC应用程序只能在具有多层的大型项目中工作，但在三层体系结构中，它绝不能作为一个表示层，而这正是提问者所要求的。

所以我们可以说MVC在三层体系结构的三层中创build了两层（第三层可能不是MVC架构本身的一部分）。

谢谢。

什么是三层架构？

三层（层）是一种客户端 – 服务器架构 ，其中用户界面，业务stream程（业务规则）以及数据存储和数据访问都作为独立的模块进行开发和维护，或者经常在不同的平台上进行。 基本上，有3层，第1层（表示层，GUI层），第2层（业务对象，业务逻辑层）和第3层（数据访问层）。 这些层可以分别开发和testing。

DAL – 数据访问层（具有Connectionstring和Data读取和执行过程）

BOL – Bussiness对象层（它有查询）

UI – 用户界面（表单和代码隐藏）

更多细节： 3层架构

三层体系结构是线性的，客户层永远不会实际与数据层进行通信 – 所有的通信都通过中间层。 另一方面，MVC更多的是三angular形，视图向控制器发送更新并从模型接收更新，控制器更新模型。

（请参阅http://en.wikipedia.org/wiki/3-tier_architecture上的“与MVC体系结构比较”;

国际海事组织没有三层架构和MVC之间的直接比较 。 两者都用于结合，因此我们倾向于通过相同的镜头来看待它们。 从概念上讲，他们不需要一起使用。 我可以有三层架构， 不使用MVC所提供的。

我没有详细说明定义部分，但简而言之：

3层是一种软件体系结构方法，其中用户界面，业务stream程是逻辑的，数据层独立开发，最常见的是在不同的平台上。

MVC已经在一段时间内从软件模式发展到架构模式，并且在当今所有主stream框架中都可以看到。

每个应用程序有更多的以下层1）表示层或UI层2）业务层或业务逻辑层3）数据访问层或数据层

三层架构通常每层都由networking隔开。 IE表示层位于某些Web服务器上，然后通过networking与后端应用程序服务器通信以获得业务逻辑，然后再通过networking与数据库服务器进行通信，也可能是应用程序服务器也呼叫某个远程服务（说Authorize.net进行支付处理）。

有时候我们需要更多的上述types的层次和更多的机器，然后称为N层

MVC是一种编程devise模式，其中代码的不同部分负责在某些应用程序中表示模型，视图和控制器。 这两件事是相关的，因为，例如，模型层可能有一个内部实现，调用数据库来存储和检索数据。 控制器可能驻留在networking服务器上，并远程调用应用程序来检索数据。 MVC抽象了应用程序的体系结构如何实现的细节。 模型 ，我们想build立的视图意味着应用程序控制的UI意味着控制应用程序的逻辑

三层只是指一个实现的物理结构。 这两个有时会混淆，因为MVCdevise通常是使用三层架构实现的。

两者之间没有任何关系。 MVC是一个表示层模式。 整个模型 – 视图 – 控制器存在于表示层中。

  • 模型是持有数据的对象（通常只是VOs），这些数据由View来表示，或者从View中填充。

  • 控制器是什么获取请求（并可能填充模型）并调用服务层。 然后获取另一个（或相同）模型，并将其发送回查看。

  • 视图是什么显示模型，并提供组件来捕捉用户input。 （它通常是Web应用程序中的模板引擎，或桌面应用程序中的UI组件）。

在讨论三层（或多层）应用程序时，我们讨论的是整个应用程序的体系结构，它由表示层（整个MVC），服务层（业务类）和数据访问层组成。

服务层（以及所有这些）隐藏在MVC的控制器之后。

我的经验是，MVC是另外一个写得不好的三层的术语，其中一些通信在业务层上跳转，因此客户端和/或数据层也混合了业务规则。

我讨厌这样写的代码 – 术语MVC必须被devise成混淆人力资源招聘人员，认为旧的程序员（谁知道它是“三层”）不匹配的工作。

在MVC中：MVC体系结构是三angular形的：视图向控制器发送更新，控制器更新模型，视图从模型直接更新

三层架构：三层架构是客户层从不直接与数据层通信在三层模型中，所有通信都必须通过中间层

Vikas Joshi软件工程师

  • 3层是线性架构。 （表示层 – >逻辑层 – >数据层，然后数据层 – >逻辑层 – >表示层）但MVC是三angular形体系结构。 （控件更新视图和模型。模型更新视图。）
  • MVC可以包含在三层架构中的performance层（Mobile应用程序，Angular如js框架等）和Logic层（J2EE，Laravel等）。
  • 3层中的层可以在不同的networking节点中实现。 但MVC中的元素通常在相同的networking节点中实现。

我不认为MVC会改变任何东西或帮助您build立更好或更强大的系统。 三层架构是成功而充分的系统。 我/你可以在其中构build非常全面和健壮的系统。 我们都知道一个复杂或真实的生活网站需要在所有的层之间进行大量的交互。 我个人认为，因为这个原因，php已经超过.net。 如果你问一个讨厌的屁股傲慢的程序员在.net中构build一个简单的论坛系统，他会挠头使用哪个控件来渲染它。 然后，他会把数据网格和一些中继器结合起来…但是如果你只是简单地要求添加评论部分或图像，他会像我这样做到底是怎么回事？ 另一方面在PHP … U可以混合在HTML与服务器代码，以实现任何表示层容易…所以不要夸耀架构，因为他们有同等的优点和缺点。 但问你有什么build立？

Interesting Posts