初探前端架构

2019 / 08 / 04

前端MVVM

前端MVVM的架构已经成为了定势,强大的组件和复杂的数据流的需求,导致前端开发者不得不写功能强大的View层和专门提供数据需求的ViewModel层。

MVVM其实很简单,相比于MVC它更注重的是V层,而在前后端分离的架构中后端的V层是最轻的。其实目前一个网站从后端到前端连起来的话大概像下边这样

M -> C -> V(后端)和M(前端) -> VM -> V

而前端的MVVM是这样的

项目结构

为了更好的组织代码,可以尽可能的满足业务场景,代码结构通常是这样的

承担v层的有components和pages,承担VM层的是mock和store,过于简单的M层也会被放在store中。除此之外config和utils来帮助进行统一配置和增强全局功能。

每个组件或者页面都会由样式和jsx组成。

当然也会有特别复杂的组件,内部又有各种各样的子组件,但是并没有把这些子组件拿出来,因为他们几乎不会被复用

项目模型

模型图大概这个样子:

工具方法也可以分为基础增强类的工具和业务类的工具

Store的话会有mock和request作为M层

当然业务组件会太多,页面也会太多,所以网站也会按照功能划分为若干模块。一般来说前端项目最重的都是v层。这个网站的v层有routes,components和pages共同构成。

总结

优点:

1. 简单。这是最简单最简单的架构了,没有比这个更简单的前端架构了,因为从最开始搭建工程化的项目的时候,写出来的结构就是这个样子,连文件夹的名字都用了最基本的pages,components,routes之类的,上手非常简单。

2. 易扩展,易调整。这个也是简单的好处,可以随时调整为其他的模型,反正都分类好了,只是如何堆放的问题。

3. 适合所有的中小型前端应用,适用各种前端框架。

缺点:

1. View层分离到不同的地方。routes,components,pages,styles其实放在一起可能更好。他们都是专注于表现层的,

2. store耦合了Model层和ViewModel层。如果分离可以更方便的调整和后端的对接,做共同的服务层。当然耦合起来也会让写起来更加方便。

3. 应该适合两年以上经验的开发者,对初级开发者还是略微的不太友好。因为建设UI组件和utils库是一件非常考验基本功的事情。多人协作的时候也要求契合度比较高。

4. 模块化的不够清晰。当然前端的业务逻辑容易棘手,不像后端那么清晰,导致前端天然不适合高度的模块化。

以上分析都是纯个人理解,如果有什么不对的或者不好的,欢迎各位读者指正。

嗨,请先 登录

加载中...
(๑>ω<๑) 又是元气满满的一天哟