MVC 与 3 层架构?
Posted
技术标签:
【中文标题】MVC 与 3 层架构?【英文标题】:MVC vs. 3-tier architecture? 【发布时间】:2011-06-02 10:21:42 【问题描述】:MVC 和 3 层架构的基本区别是什么?
【问题讨论】:
MVC Vs n-tier architecture 的可能重复项 【参考方案1】:两者之间没有任何关系。 MVC 是一种表示层模式。整个 Model-View-Controller 存在于表现层中。
Model 是保存数据的对象(通常只是 VO),由 View 表示或从 View 填充。
Controller 是获取请求(并可能填充模型)并调用服务层的对象。然后获取另一个(或相同)模型并将其发送回 View。
View 是显示模型的内容,并提供组件来捕获用户输入。 (它通常是 Web 应用程序中的模板引擎,或桌面应用程序中的 UI 组件)。
当谈论 3 层(或 n 层)应用程序时,我们谈论的是整个应用程序的架构,它由表示层(整个 MVC)、服务层(业务类)和数据访问层组成。
服务层(及其背后的一切)隐藏在 MVC 的控制器后面。
【讨论】:
【参考方案2】: 3 层是线性架构。 (表示层 -> 逻辑层 -> 数据层然后数据层 -> 逻辑层 -> 表示层)但是 MVC 是三角建筑。 (控制更新视图和模型。模型 更新视图。) MVC 可以包含在 3 层架构中的表示层(移动应用程序、Angular 类 js 框架等...)和逻辑层(J2EE、Laravel 等...)。 3 层中的层可以在不同的网络节点中实现。但通常 MVC 中的元素在相同的网络节点中实现。【讨论】:
【参考方案3】:我不认为 MVC 会改变任何东西或帮助您构建更好或更强大的系统。 3层架构是成功且足够的系统。我/你可以在其中构建非常全面和强大的系统。我们都知道一个复杂的或现实生活中的网站需要所有层之间的大量交互。由于这个原因,我个人认为 php 比 .net 具有优势。如果你让一个书呆子、傲慢的程序员在 .net 中构建一个简单的论坛系统,他会为使用哪个控件来呈现它而挠头。然后他会将数据网格与一些转发器结合起来......但稍后如果你只是要求添加评论部分或图像,他会喜欢我是怎么做到的?另一方面,在 php 中...您可以将 html 与服务器代码混合以轻松实现任何表示层...所以不要吹嘘架构,因为它们具有相同的优点和缺点。但是问一下你建了什么?
【讨论】:
【参考方案4】:每个应用程序都有一个或多个以下层 1)表示层或UI层 2)业务层或业务逻辑层 3)数据访问层或数据层
三层架构通常每一层都被网络隔开。 IE。表示层在一些 Web 服务器上,然后通过网络与后端应用服务器进行业务逻辑通信,然后再通过网络与数据库服务器进行通信,并且可能应用服务器还调用一些远程服务(比如 Authorize.net 用于付款处理)。
有时我们需要更多的上述类型的层和更多的机器,然后它被称为 N 层
MVC 是一种编程设计模式,其中不同部分的代码负责表示某些应用程序中的模型、视图和控制器。这两件事是相关的,因为例如模型层可能有一个内部实现,它调用数据库来存储和检索数据。控制器可以驻留在网络服务器上,并远程调用应用服务器来检索数据。 MVC 抽象出应用程序架构如何实现的细节。 模型我们要在哪个模型上构建 View 表示应用程序的 UI 控制表示控制应用程序的逻辑
3-tier 只是指实现的物理结构。这两者有时会混淆,因为 MVC 设计通常使用 3 层架构实现。
【讨论】:
【参考方案5】:在 MVC 中:MVC 架构是三角形的:视图向控制器发送更新,控制器更新模型,视图直接从模型更新
在三层中:三层架构是客户端层从不直接与数据层通信 在三层模型中,所有通信都必须通过中间层
维卡斯·乔希 软件工程师
【讨论】:
【参考方案6】:我的经验是,MVC 只是写得不好的 3 层的另一个“流行”术语,其中一些通信在业务层之间跳跃,因此客户端和/或数据层也混入了业务规则.
我讨厌这样写的代码 - MVC 这个词一定是为了让 HR 招聘人员误以为年长的程序员(他们知道它是“三层”)不适合这份工作。
【讨论】:
这个答案是我在采访中发生的一个完美例子。我没有得到这份工作的主要原因之一是因为我不知道 MVC 是什么,但我已经在三层编程超过 10 年了。在研究 MVC 之后,它完全是三层混合的。就像这个用户指出的那样,IMO 三层优于 MVC,MVC 刚刚弄得一团糟 完全同意你的看法。还有一点,多亏了三角交互,许多 Web 框架都有自己的“MVC”方式,这会导致很多混乱。【参考方案7】:在 3 层架构中,层之间的通信是双向的。在 MVC 中,通信是单向的;我们可以说每个“层”都由左边的那个更新,然后又更新右边的那个——其中“左”和“右”只是说明性的。
3 层架构通常在 3 个独立的网络节点上部署为 3 个独立的进程。但是 MVC 旨在部署为单个网络节点中的单个进程。 (类似于桌面应用程序)
三层中的业务层通常包含实现著名模式的不同层,如业务委托、业务外观、业务对象、服务定位器、数据传输对象等。但 MVC 本身是一种用于表示层的设计模式。
3-tier的目标是业务逻辑与客户端和数据库的分离,因此提供多种客户端协议、高扩展性、异构数据访问等。但是MVC的主要目标是在一个部分的实现更改不需要更改为另一个。
【讨论】:
【参考方案8】:三层是一种架构风格,MVC是一种设计模式。
所以不一样。
但我们可以在 3 层架构风格中使用 mvc 模式。
所以:
表示层:来自 MVC 模式的“控制器和视图”。
业务层:来自 MVC 模式的“模型(数据)”。
数据访问层:原始数据访问层。
【讨论】:
仅仅说“3-tier 是一种架构风格,MVC 是一种设计模式”是不够的。 MVC 是一种设计模式,属于架构模式组。 其实 MVC 是一种架构模式,而不是设计模式。【参考方案9】:IMO 在 3 层架构和 MVC 之间没有直接的比较。两者都结合使用,因此我们倾向于通过同一个镜头来看待它们。从概念上讲,它们不需要一起使用。我可以拥有 不 使用 MVC 提供的 3 层架构。
我不是详细说明定义部分,而是简而言之:
三层是一种软件架构方法,其中用户界面、业务流程是逻辑、数据层独立开发,通常在不同的平台上。
MVC 在一段时间内已经从软件模式演变为架构模式,并出现在当今所有主要框架中。
【讨论】:
同意,它们是正交的,但互补的。【参考方案10】:什么是三层架构?
三层(层)是client-server architecture,其中用户界面、业务流程(业务规则)以及数据存储和数据访问作为独立模块开发和维护,或者通常在单独的平台上进行。基本上有 3 层,第 1 层(表示层、GUI 层)、第 2 层(业务对象、业务逻辑层)和第 3 层(数据访问层)。这些层可以单独开发和测试。
DAL - 数据访问层(它有连接字符串和数据读取和执行过程)
BOL - 业务对象层(它有查询)
UI - 用户界面(表单和代码隐藏)
更多详情:3 Tier Archtecture
【讨论】:
好吧,不过这最多只是问题的一半。你能增量 MVC 吗? 这个答案与问题无关。这说只有 3 层。【参考方案11】:与迈克尔在回复中所说的相比,我采取了不同的方法。
控制器永远不会成为您的业务逻辑。对我来说,业务逻辑属于模型层。虽然,视图(在某种程度上是控制器)和表示层的一部分,但模型在 MVC 应用程序中永远不是它的一部分。模型应该是 MVC 应用程序的核心和灵魂,这就是领域驱动设计的全部内容,可以在 MVC 应用程序中轻松实现。
请记住,您不必将模型放在同一个项目中(说到 ASP.NET MVC)。它可以驻留在一个完全不同的项目中,并且仍然可以作为应用程序的模型
充当表示层的 MVC 应用程序只能在具有许多层的大型项目中工作,但它永远不能充当提问者所要求的 3 层架构中的仅表示层。
所以我们可以说 MVC 在 3 层架构的三层中产生了两层(第三层可以是数据层,它本身并不是 MVC 架构的一部分)。
谢谢。
【讨论】:
【参考方案12】:三层架构是线性的,其中客户端层实际上从不与数据层通信——所有通信都通过中间层。另一方面,MVC 更三角,其中视图向控制器发送更新并从模型接收更新,然后控制器更新模型。
(请参阅http://en.wikipedia.org/wiki/3-tier_architecture 上的“与 MVC 架构的比较”)
【讨论】:
我相信你从***复制了这个答案。如果你引用你的来源会更好。 “检查与 MVC 架构的比较”段落@en.wikipedia.org/wiki/3-tier_architecture【参考方案13】:在大型应用程序中,MVC 只是 N 层架构的表示层。模型视图和控制器只关心表示,并利用中间层使用来自数据层的数据填充模型。
MVC 也可以用作整个 3 层架构,其中视图是您的表示,控制器是您的业务逻辑,模型是您的数据层(通常由实体框架等 DAL 生成)。
理想情况下,尽管您希望控制器又瘦又笨,将逻辑传递给“业务组件”,这实际上将成为您的中间层。
【讨论】:
如果 View=Presentation,Controller=Business 和 Model=DAL 那么它们之间的基本区别是什么?哪个更好,为什么? MVC 可以说是三层架构的实现,但也可以是其自身的顶层。 我同意你的第一段,但不同意你的第二段。 BL 应该不在控制器中。努力构建一个包含 BL 和精益控制器的健壮模型。以上是关于MVC 与 3 层架构?的主要内容,如果未能解决你的问题,请参考以下文章