C++ 全栈知识体系

架构设计原则 - 分层架构MVC

参考资料

DANGER

待补充 MVC框架 的具体样例。

概念

MVC是三个单词的首字母缩写，它们是Model（模型）、View（视图）和Controller（控制）。

MVC（Model–View–Controller）模式是软件工程中的一种软件架构模式，它把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

MVC 模式的目的是实现一种动态的程序设计，简化后续对程序的修改和扩展，并且使程序某一部分的重复利用成为可能。除此之外，MVC 模式通过对复杂度的简化，使程序的结构更加直观。软件系统在分离了自身的基本部分的同时，也赋予了各个基本部分应有的功能。

  • 模型（Model）：承载数据，并对用户提交请求进行计算的模块；
  • 控制器（Controller）：负责转发View的请求，找到相应的Model对用户请求进行处理；
  • 视图（View）：为用户提供使用界面，与用户直接进行交互。

MVC 模式的描述如下图所示：

MVC框架图

MVC 模式中三个组件的详细介绍如下：

  1. 模型（Model）：用于封装与应用程序业务逻辑相关的数据以及对数据的处理方法。Model 有对数据直接访问的权力，例如对数据库的访问。Model 不依赖 View 和 Controller，也就是说， Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，由此，View 可以了解在数据 Model 上发生的改变。（例如，软件设计模式中的“观察者模式”）；
  2. 视图（View）：能够实现数据有目的的显示。在 View 中一般没有程序上的逻辑。为了实现 View 上的实时刷新功能，View 需要访问它监视的数据模型Model，因此应该事先在被它监视的数据那里注册；
  3. 控制器（Controller）：起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据 Model 上的改变。

Router

  • 路由是URL映射到处理程序的模式
  • 处理程序可以是MVC应用程序中的控制器
  • 路由表中定义了支持的URL与传入请求的URL之间的四配模式
  • 当路由引擎在路由表中找到匹配的传入请求的URL时，它将请求转发给相应的控制器和操作
  • 如果在传入请求的URL中的路由表中没有匹配，则返回404 HTTP状态代码

SpringMVC简介

SpringMVC是spring框架的一个模块，SpringMVC和spring无需通过中间整合层进行整合。

SpringMVC是一个基于mvc的web框架。

SpringMVC 表现层：方便前后端数据的传输

Spring MVC 拥有控制器，作用跟Struts类似，接收外部请求，解析参数传给服务层

MVC是指，C控制层，M模块层，V显示层这样的设计理念，而SSM框架里面SPRING MVC本身就是MVC框架，作用是帮助（某种意义上也可以 理解为约束）我们要按照MVC这样的设计来开发WEB项目，而另外两个框架spring主要是用作IOC,AOP等其他的一些设计原则，至于mybatis是用来方便操作数据库的，所以他们都在MV里面，至于V指的是展示部分，一般是指JSP，freemarks这种前提其实，和SSM就没有太大的关系了

SpringMVC项目架构图

SpringMVC项目架构图

Springmvc架构原理解析

  1. 发起请求到前端控制器(DispatcherServlet)
  2. 前端控制器请求HandlerMapping查找 Handler，可以根据xml配置、注解进行查找
  3. 处理器映射器HandlerMapping向前端控制器返回Handler
  4. 前端控制器调用处理器适配器去执行Handler
  5. 处理器适配器去执行Handler
  6. Handler执行完成给适配器返回ModelAndView
  7. 处理器适配器向前端控制器返回ModelAndView，ModelAndView是SpringMVC框架的一个底层对象，包括 Model和View
  8. 前端控制器请求视图解析器去进行视图解析，根据逻辑视图名解析成真正的视图(jsp)
  9. 视图解析器向前端控制器返回View
  10. 前端控制器进行视图渲染，视图渲染将模型数据(在ModelAndView对象中)填充到request域
  11. 前端控制器向用户响应结果

组件

  1. 前端控制器DispatcherServlet（不需要程序员开发）作用接收请求，响应结果，相当于转发器，中央处理器。有了DispatcherServlet减少了其它组件之间的耦合度。

  2. 处理器映射器HandlerMapping(不需要程序员开发)。

    • 作用：根据请求的url查找Handler

  3. 处理器适配器HandlerAdapter。

    • 作用：按照特定规则（HandlerAdapter要求的规则）去执行Handler

  4. 处理器Handler(需要程序员开发)

    • 注意：编写Handler时按照HandlerAdapter的要求去做，这样适配器才可以去正确执行Handler

  5. 视图解析器View resolver(不需要程序员开发)

    • 作用：进行视图解析，根据逻辑视图名解析成真正的视图（view）

  6. 视图View(需要程序员开发jsp)

    • View是一个接口，实现类支持不同的View类型（jsp、freemarker、pdf…）

优缺点

优点

  • 低耦合

    • 通过将视图层和业务层分离，允许更改视图层代码而不必重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变，只需要改动 MVC 的模型层（及控制器）即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。

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

  • 重用性高

    • 随着技术的不断进步，当前需要使用越来越多的方式来访问应用程序了。MVC 模式允许使用各种不同样式的视图来访问同一个服务端的代码，这得益于多个视图（如 WEB（HTTP）浏览器或者无线浏览器（WAP））能共享一个模型。

    • 比如，用户可以通过电脑或通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式（流程）是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面（视图）使用。例如，很多数据可能用 HTML 来表示，但是也有可能用 WAP 来表示，而这些表示的变化所需要的是仅仅是改变视图层的实现方式，而控制层和模型层无需做任何改变。

    • 由于已经将数据和业务规则从表示层分开，所以可以最大化的进行代码重用了。另外，模型层也有状态管理和数据持久性处理的功能，所以，基于会话的购物车和电子商务过程，也能被 Flash 网站或者无线联网的应用程序所重用。

  • 生命周期成本低

    • MVC 模式使开发和维护用户接口的技术含量降低。

  • 部署快

    • 使用 MVC 模式进行软件开发，使得软件开发时间得到相当大的缩减，它使后台程序员集中精力于业务逻辑，界面（前端）程序员集中精力于表现形式上。

  • 可维护性高

    • 分离视图层和业务逻辑层使得 WEB 应用更易于维护和修改。

  • 有利软件工程化管理

    • 由于不同的组件（层）各司其职，每一层不同的应用会具有某些相同的特征，这样就有利于通过工程化、工具化的方式管理程序代码。控制器同时还提供了一个好处，就是可以使用控制器来联接不同的模型和视图，来实现用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。

缺点

  • 没有明确的定义

    • 完全理解 MVC 模式并不是很容易的。使用 MVC 模式需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考软件的架构。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。

  • 不适合小、中型应用程序

    • 花费大量时间将 MVC 模式应用到规模并不是很大的应用程序通常会得不偿失。

  • 增加系统结构和实现的复杂性

    • 对于简单的界面来说，非要严格遵循 MVC 模式，使模型、视图与控制器分离的话，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

  • 视图对模型数据的低效率访问

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

说明：如果通过控制器访问模型层（而非视图层直接访问），或许可避免对未变化数据的不必要的频繁访问，从而解决此问题。

← 架构设计原则 - 整洁架构 →