Skip to main content

Web应用程序的MVC架构和三层架构的区别

 今天我正式开始学习Go编程语言!

好几年前我就尝试学习Go的基础,但是我最终没有坚持把基础学完,我现在相当于完全忘记了Go的语法的状态了。

管他的,直接开始学一个综合的Web项目!

从今天开始,我学习孔令飞写的这个课程 -- 《Go 语言项目开发实战》。

在第一篇课程文章中,讲师提到了2个常见的软件架构模式,分别是:

  • 前后端分离架构
  • MVC架构
由于我对于软件开发的知识可以说是菜鸟,从上下文来看,前后端分离似乎意味着"微服务架构",微服务架构中肯定还有许多细分层面的架构模式,比如Saga、DDD等。
而MVC,从上下文来看意味着"单体架构"的其中一种应用程序架构模式。
在这个第一篇教程文章中,与MVC一起提到了一个叫做"三层架构"的软件开发架构,我引用一下原文:
除此之外,还有一种跟 MVC 比较相似的软件开发架构叫三层架构,它包括 UI 层、BLL 层和 DAL 层。其中,UI 层表示用户界面,BLL 层表示业务逻辑,DAL 层表示数据访问。在实际开发中很多人将 MVC 当成三层架构在用,比如说,很多人喜欢把软件的业务逻辑放在 Controller 层里,将数据库访问操作的代码放在 Model 层里,软件最终的代码放在 View 层里,就这样硬生生将 MVC 架构变成了伪三层架构。
我是第一次听说这个"三层架构",光是看这段话我不理解这个三层架构和MVC有什么区别,于是让我问问AI吧。

展开了解下"三层架构"

我的提问:

"""
MVC 的全名是 Model View Controller,它是一种架构模式,分为 Model、View、Controller 三层,每一层的功能如下:View(视图):提供给用户的操作界面,用来处理数据的显示。Controller(控制器):根据用户从 View 层输入的指令,选取 Model 层中的数据,然后对其进行相应的操作,产生最终结果。Model(模型):应用程序中用于处理数据逻辑的部分。
MVC 架构的好处是通过控制器层将视图层和模型层分离之后,当更改视图层代码后时,我们就不需要重新编译控制器层和模型层的代码了。同样,如果业务流程发生改变也只需要变更模型层的代码就可以。在实际开发中为了更好的 UI 效果,视图层需要经常变更,但是通过 MVC 架构,在变更视图层时,我们根本不需要对业务逻辑层的代码做任何变化,这不仅减少了风险还能提高代码变更和发布的效率。除此之外,还有一种跟 MVC 比较相似的软件开发架构叫三层架构,它包括 UI 层、BLL 层和 DAL 层。其中,UI 层表示用户界面,BLL 层表示业务逻辑,DAL 层表示数据访问。在实际开发中很多人将 MVC 当成三层架构在用,比如说,很多人喜欢把软件的业务逻辑放在 Controller 层里,将数据库访问操作的代码放在 Model 层里,软件最终的代码放在 View 层里,就这样硬生生将 MVC 架构变成了伪三层架构。这种代码不仅不伦不类,同时也失去了三层架构和 MVC 架构的核心优势,也就是:通过 Controller 层将 Model 层和 View 层解耦,从而使代码更容易维护和扩展。因此在实际开发中,我们也要注意遵循 MVC 架构的开发规范,发挥 MVC 的核心价值。
"""

以上的文本来自一个Go编程语言的Web应用程序开发教程。

我以前从事过Java web应用程序开发,对MVC这个开发模式/应用程序的架构模式算是有一定直观的认识。
但是我没有听说过所谓的"三层架构"。

请问这个"三层架构"是否是由来于英文的软件设计相关的资料?

ChatGPT的回答:


是的,"三层架构"(Three-tier architecture)确实源自英文的软件设计领域,并且在软件开发中非常常见。

三层架构的起源与定义

三层架构(Three-tier architecture)是一种软件架构模式,通常分为以下三个层次:

1. 用户界面层(UI Layer):也叫表示层(Presentation Layer),主要负责与用户的交互和界面展示。它接收用户的输入,向用户展示数据和结果。
   
2. 业务逻辑层(BLL - Business Logic Layer):也称为应用层(Application Layer),负责处理应用程序的业务逻辑。它从数据访问层获取数据,并根据业务规则进行处理。
   
3. 数据访问层(DAL - Data Access Layer):负责与数据库等数据存储进行交互。它封装了对数据库的操作,比如读取、写入、更新和删除数据。

这种架构的好处是将不同的功能模块进行解耦,使得每一层可以独立地进行开发和维护,便于扩展和测试。

三层架构与 MVC 的区别

三层架构和 MVC(Model-View-Controller)有一些相似之处,但它们的侧重点和应用场景有所不同:

- 三层架构是从软件系统架构的角度出发,着重于逻辑分层:UI 层、业务逻辑层、数据访问层。它更强调逻辑上如何处理数据流、业务规则、以及数据持久化。
  
- MVC 架构则是从用户界面交互和控制角度出发,用于分离应用程序的表现(View)、控制(Controller)和数据(Model)部分。它更强调界面如何响应用户输入,以及如何协调数据和显示。

尽管两者有一定的重叠,尤其是在 web 应用开发中,但它们解决的问题和关注的重点并不完全相同。

为什么三层架构有时被误用为 MVC?

在一些项目中,开发者可能会将 MVC 架构和三层架构混用或混淆,原因如下:

- 在 MVC 中,Controller 的职责是协调 View 和 Model,但有些开发者会将业务逻辑放入 Controller,而不是在一个单独的业务逻辑层(BLL)中处理,这使得 MVC 架构看起来更像三层架构。
  
- 另外,有些开发者会将 Model 仅用作数据访问层(类似于 DAL),而忽略了它其实应该是一个处理数据和业务逻辑的部分,这进一步导致 MVC 被误用为三层架构。

总结

三层架构(Three-tier architecture)确实是源自英文的软件设计领域,并且与 MVC 架构有一些相似之处。但它们的重点不同:三层架构更注重逻辑分层和数据处理,而 MVC 架构则侧重于用户界面和应用逻辑的分离。两者各有优缺点,在实际开发中都可以根据具体需求来选用。

在软件开发领域,一般来说MVC被认为是比三层架构更先进的软件架构模式吗?

ChatGPT的回答

在软件开发领域,MVC 并不一定被认为是比三层架构更“先进”,而是它们各自有不同的用途和适用场景。两者解决的是不同的问题,关注的重点也不同。

1. MVC 的特点

MVC(Model-View-Controller) 是一种设计模式,主要用于分离应用程序的用户界面(View)、业务逻辑(Controller)和数据模型(Model)。该模式的主要目的是解耦用户界面和业务逻辑,从而使得用户界面的变化不会影响业务逻辑部分的实现,反之亦然。

MVC 的优势:
- 清晰的职责分离:每一层都有明确的职责,便于维护和扩展。
- 增强可测试性:因为控制逻辑和界面分离,单元测试可以很容易地对业务逻辑进行测试。
- 灵活的用户界面更新:View 和 Model 的解耦使得应用的用户界面可以独立变化,而不需要更改业务逻辑。


MVC 的适用场景:
- Web 应用开发:特别是在处理复杂的用户交互时,MVC 模式可以有效管理数据和界面的关系。
- 前端框架:许多前端框架(如 React、Angular)使用了类似 MVC 的设计模式来管理视图和数据。


2. 三层架构的特点


三层架构(Three-tier architecture) 是一种软件架构模式,典型地分为以下三层:
- 表示层(UI 层):负责用户交互与界面展示。
- 业务逻辑层(BLL):负责应用的业务规则和逻辑处理。
- 数据访问层(DAL):负责与数据库或其他数据源交互,处理数据存取。

三层架构的优势:
- 逻辑上分层清晰:不依赖于特定的用户界面,业务逻辑和数据访问层可以独立于表示层开发。
- 良好的代码复用性:业务逻辑和数据访问可以在多种前端(例如 Web、桌面、移动应用)中复用。
- 易于扩展和维护:各层独立开发,变化时可以只修改某一层而不影响其他层。


三层架构的适用场景:
- 企业级应用:特别是在处理复杂的业务流程和数据访问时,三层架构更适合,因为它本质上关注的是系统的逻辑分层
- 分布式系统:三层架构的业务逻辑层和数据层可以部署在不同的服务器或服务中,适合分布式应用。


3. MVC 与三层架构的比较


关注点不同:
- MVC 主要关注的是用户界面与业务逻辑的解耦,它的设计初衷是让用户界面(View)和数据模型(Model)独立变化,控制器(Controller)则充当协调者。
- 三层架构更多的是关注逻辑功能的分离,即表示层、业务逻辑层和数据层的分离,目的是让每一层的代码职责单一,便于复用和维护。


适用场景不同:
- MVC 更适用于用户交互复杂的应用,尤其是前端驱动的应用,它为表示层和业务逻辑层的交互提供了很好的方式。
- 三层架构更适用于复杂的企业级应用,它强调的是业务逻辑、数据访问和表示层的分离,使得每一层可以独立扩展、部署和维护。


结合使用:
实际上,MVC 和三层架构可以结合使用。在一些情况下,MVC 可以作为UI 层的一部分,而三层架构可以用于整个系统的架构设计。比如:
- UI 层可能使用 MVC 模式来管理用户界面和交互。
- 业务逻辑层(BLL)数据访问层(DAL)则独立于 MVC 之外,处理复杂的业务规则和数据操作。
这种组合方式在许多现代 Web 开发中非常常见。例如:
- 前端使用 MVC 模式来管理用户界面(如 Angular、React 等)。
- 后端使用三层架构来处理服务端的业务逻辑和数据存储(如 Spring Boot、ASP.NET 等)。


4. **总结**


MVC 并不比三层架构更先进,它们只是解决了不同的问题:

- MVC 强调的是用户界面与业务逻辑的分离,让 UI 和数据模型之间的交互更加灵活。
- 三层架构 强调的是逻辑分离,主要用于将表示层、业务逻辑层和数据层分开,使得应用程序更容易扩展和维护。

因此,二者并不是一个进化关系,而是可以互补使用的架构模式。根据项目的需求和开发环境,开发者可以选择或结合使用 MVC 和三层架构。

Comments

Popular posts from this blog

System Admin's Savior? Generating Command Cheat Sheets with DeepSeek, Gemini, and Copilot

I. Introduction Are you tired of sifting through messy command notes, struggling to find the right syntax for your HPE Ezmeral Data Fabric Object Store tasks? Managing on-prem Object Stores can be a complex endeavor, often requiring a vast collection of commands for various operations. Creating and maintaining accurate, easily searchable cheat sheets is crucial for efficiency, but the traditional methods can be time-consuming and frustrating. I recently found myself in this exact situation. My command notes, accumulated over months of working with our HPE Ezmeral Data Fabric environment, had become a disorganized mess. Searching through them in Sublime Text was a nightmare, and I knew there had to be a better way. That’s when I had an “aha!” moment: why not leverage the power of Large Language Models (LLMs) to automate the cheat sheet creation process? In this blog post, I’ll be sharing my experiment comparing three popular tools and LLM APIs: Roo Code with DeepSeek, Roo Code with Gemi...