选用Vue作MVC架构模式

时间 2019-11-16

原文原文链接

关键词 并行开发 代码复用 关注点分离前端

经典的MVC架构模式

MVC架构模式是经典设计模式中的经典，是一种编程的方法论。具备高度抽象的特征，经典MVC用简单的定义体现出解决复杂通用问题的办法，只有不断思考和体会才能用来解决不一样状况下程序设计所遇到的问题。vue

MVC不能脱离具体的框架而独自存在，把握抽象必须用具体；把握具体的内在结构和外在关系只能用抽象。node

在前端领域中有表明MVC的Anguler、表明MVVM的Vue、和表明单向数据流的React都是很棒的前端框架，分别表明了一种具体的设计模式应用，在不一样的应用场景中使用对了框架才能把这些框架的特性充分的发挥出来，若是只是从字面上找对应，Anguler才是MVC的表明，Vue显然不是MVC的表明，为何我要选用Vue来作MVC架构模式呢？ 下面就来讲一下为什么这么作。ios

背景

我所在的部门业务场景上是分客群分产品的, 产品需求上迭代很是快，全场景一年要发布120多个版本，技术架构主要考量如下几点：git

产品稳定性
多产品并行开发，支持4-10个产品线独立开发部署
多产品公共功能可复用，保证开发效率
提高用户体验

技术架构自己的生命周期取决于业务的生命周期，好的架构模式应该是模块化的，能够针对其中的一个模块来进行优化升级，延长技术架构的生命周期就会节约不少成本。数据库

选择Vue

1.足够的小巧，轻量，关注点聚焦，不会干扰总体项目设计架构；同时也有全家桶来作关注点分离，须要更多能力时全家桶中有可选择的项，减小从新造轮子。
2.上手成本低、开发效率也很高
3.Vue生态成熟和有庞大的开发者群体

不选Angular的缘由： 我的角度仍是很喜欢Angular，但Angular也有一些问题，如大版本发布太快和变化太大；大而全，这是优势也是缺点，缺点就是设计太重不利于每一个团队根据实际状况基于Angular来从新设计架构，换掉其中的一部分设计，也很难让团队成员理解和适应。编程

不选React的缘由： 因Facebook的开源项目React嵌入了竞争防止协议，留下比较大的法务隐患，17年9月内部就抛弃了React框架，已经使用Ract的项目也要限按期限改成其余框架。即便后来FaceBook的开源协议有所改善，但这种事情仍是让你们心留余悸，不能再提了。axios

经典MVC回顾

MVC全名是Model View Controller，是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型(Model)、视图(View)和控制器(Controller)。后端

是一种软件设计典范，用一种业务逻辑和数据显式分离的方法组织代码，将业务逻辑汇集到一个部件里面，在界面和用户围绕数据的交互能被改进和个性化定制的同时而不须要从新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。设计模式

Model（模型） 是应用程序中用于处理应用程序数据逻辑的部分。一般模型对象负责在数据库中存取数据。

模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。模型与数据格式无关，这样一个模型能为多个视图提供数据，因为应用于模型的代码只需写一次就能够被多个视图重用，因此减小了代码的重复性。

View（视图） 是应用程序中处理数据显示的部分。一般视图是依据模型数据建立的。

视图是用户看到并与之交互的界面。MVC好处是它能为应用程序处理不少不一样的视图。在视图中其实没有真正的处理发生，无论这些数据是联机存储的仍是一个雇员列表，做为视图来说，它只是做为一种输出数据并容许用户操纵的方式。

Controller（控制器） 是应用程序中处理用户交互的部分。一般控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

控制器接受用户的输入并调用模型和视图去完成用户的需求，因此当单击Web页面中的超连接和发送HTML表单时，控制器自己不输出任何东西和作任何处理。它只是接收请求并决定调用哪一个模型构件去处理请求，而后再肯定用哪一个视图来显示返回的数据。

MVVM架构模式

MVVM模式是工程师在解决WPF应用程序开发复杂度时提出的解决方案，它实现了View和Model的自动同步，开发者不须要再手动的绑定输入监听和手动的将数据结果展现在view上，这就是双向数据绑定的优点，后来Backbone、Vue等都是MVVM模式的前端框架。

ViewModel解决了View和Model之间转换的开发效率问题。可是ViewModel内部的复杂度又变成了新的问题，其中一个问题就是双向数据绑定劣势。在双向数据绑定中，Model（能够理解为状态的集合）中能够修改本身或其余Model的状态，用户的操做（如在输入框中输入内容）也能够修改状态。这使的改变一个状态有可能会触发一连串的状态的变化，最后很难预测最终的状态是什么样的。使得代码变得很难调试。

为了解决这个问题便有了后来的Vue 单向数据流的解决方案-Vuex。在复杂度较高的业务上使用单向数据流来解耦View和Model的关系。

能够看出经典MVC架构模式的重点是要解决业务逻辑复用和数据显式分离，前端MVC本质要解决的仍是这两点，不一样的是前端用组件化和MVVM分别来解决业务逻辑复用和数据显式分离，MVC、MVVM都要解决MV这两层的的问题。先后端分离后、前端使用单页应用就能够完成用户界面部分的管理，此时在前端架构中须要有一层来管理页面切换这就是前端MVC的Controller控制层。

MVC和MVVM本质上这是两种架构模式，是为了解决不一样场景遇到的开发问题。二者解决的问题有类似之处，MVVM中的ViewModel和MVC中的Controller做用有些类似。用Vue框架的项目引入Vuex后ViewModel的做用被弱化，MVVM和单向数据流都没法反映整个框架的架构模式。同时总体架构还要解决单页应用等问题，更须要有一个准确的理论模型，从而选择MVC架构模式来作项目架构更适合实际状况。

front MVC架构定义

代码库结构图

在业务层（不包括基础组件）和经典MVC想比Front MVC的核心由Model变成了View。 View层的设计是重点，基础组件尽可能使用组件特性和MVVM、避免过分设计形成层级复杂度变大；业务组件能够用EventBus的方式来处理跨层级交互的问题。 Model层由Vuex来管理，Vuex适合数据量大而且函数集中处理，管理接口数据很合适；以便明确各类方式的最佳实践范围。

Model（模型） 是应用程序中用于处理应用程序状态管理和数据交互的部分。主要由状态管理Vuex和数据交互axios实现。

View （视图） 是应用程序中业务逻辑处理和内容展现的部分。不一样于经典MVC中的View，Front MVC的View层业务逻辑会比较重，这是因为前端的复用主要体如今组件上，前端框架Vue的Global API一系列特性也很是好的支撑这种组件化业务需求。这里的View层主要有基础组件库、公共组件库、产品组件库组成，其中前两个库是能够复用的。

Controller（控制器） 是应用程序中处理用户交互的部分。不一样于MVC中的Controller， Front MVC的Controller层是经过路由机制加载View主要是有viewRouter来实现，再有View根据交互逻辑来控制Model层的调用。在这里View是应用程序的核心部件。

这样设计的特色：

首先实现了单页应用，用户体验交回前端管理
MVC各层是模块化的，可灵活调整和复用
层级划分清晰，利于用最佳实践实现
Model层数据可复用，跨页面公共数据根据状况可只调用一次
View层可复用

并行开发模式

并行开发效率高，但产品多、开发人员多、发版频繁必定会形成冲突和相互影响，必须重点关注保证产品稳定性。控制好公共部分的改动频率和修改权限。

解决方法：

各产品库的node_module依赖项统一管理，兼容公共部分依赖项。
业务公共库各产品负责人有修改权限，既保证公共部分协同开发，也保证公共部分稳定。
基础组件库精心打磨，控制发版频次。
只在产品库中编译项目,公共库使用git sub module的方式引入，各产品单独发布部署包。
各产品单独部署。

结论

只要能解决问题，架构应该是越简单越好，就像经典MVC架构模式同样简洁，同样有力量。不断总结分析，寻求不一样的解决方法，设计时总体考量，常常在抽象和具体以前切换角度思考，才能兼顾开发效率和技术支撑。

本文是从项目总体设计上对MVC架构模式进行了一个实践总结，欢迎你们交流指正！