内容简介:因为有2年的iOS原生app的开发经历,所以MVC架构模式对我有很深的影响。 其中数据模型model模块的使用和完善,对于多人协作开发项目的开发效率有着很大的影响。 app的开发主要是基于后台返回的业务数据和本地的逻辑数据协同进行对数据的展示和逻辑交互, 其中业务数据主流是通过接口以json数据类型返回,对应oc中的数据结构可以是NSDictionary或NSArray, 然后通过特定的数据模型解析数据,对数据进行初始化处理,生成更加适合页面渲染的数据结构。然而在从事前端SPA开发之后,发现虽然现有的SPA
因为有2年的iOS原生app的开发经历,所以MVC架构模式对我有很深的影响。 其中数据模型model模块的使用和完善,对于多人协作开发项目的开发效率有着很大的影响。 app的开发主要是基于后台返回的业务数据和本地的逻辑数据协同进行对数据的展示和逻辑交互, 其中业务数据主流是通过接口以json数据类型返回,对应oc中的数据结构可以是NSDictionary或NSArray, 然后通过特定的数据模型解析数据,对数据进行初始化处理,生成更加适合页面渲染的数据结构。
然而在从事前端SPA开发之后,发现虽然现有的SPA框架都或多或少的拥有MVC的设计思路,但是数据模型的使用并不普及。
在实际项目中明显感觉到业务逻数据的可读性并不高,经常会出现无法预先明确现有js中 Object对象中会存在的数据键值和对应数据的含义。所以开始思考为什么前端SPA应用开发不普及数据模型?并且前端SPA开发中引入数据模型的可行性和充分性。
对数据模型的理解 和 使用带来的一些收益:
对于MVC的初步理解,和各个模块之间的关系如下:
其中在没有数据模型的情况下会存在的问题,结合实际开发情况归纳如下:
- 在代码真正运行之前我们无法获知对应数据中的key和value。
- 在获取到数据之前对应的空数据类型无法很好的定义。对于后台返回数据的不确定性没办法很好的预处理,多层次获取数据时容易引发未知的undefined错误,所以需要添加很多的非空判断。
- 大量的业务数据与逻辑数据混杂在主控制流程之中,相互的关联并不明确,可读性不高,同时很大程度上的增加了控制器文件的代码量。
- 对于多层级嵌套的业务数据无法很好的添加注释,导致对数据含义的理解困难。
- 多个页面同时使用了相同业务数据时,数据操作方法在没有抽取的情况下存在一定的耦合。
- 当对业务数据进行解耦时,经常出现提取出来的数据处理方法和数据枚举类型,没有一个可以明确的安放的位置。
关于前端SPA页面为什么不普及数据模型的推测:
1、 静态页面
直接跳过
2、动态网页
通过对asp.net和django这个2个动态网站架构中MVC模式的使用情况,简单的说明数据模型对于动态网页开发的合理性
asp.net
在微软的主导下,是遵循MVC模式的。他的各部分功能拆分十分的清晰,初步归纳如下:
- .aspx:是view,视图层
- .aspx.cs:是controller,控制器层
- model:model,数据模型层
其中重点是model层,通过与数据库的交互,生成数据库中对应的数据实体,对数据库原始数据进行加工处理,然后通过 controller控制view的逻辑展示。
django
从django的模块划分上也不难发现他也遵循的是MVC的模式:
django的特别之处是他数据库表结构是直接根据对应的数据模型生成的,所以第一层级的数据模型更加的偏向于原始数据,为了方便之后的业务逻辑操作,往往会在控制器和获取到的原始数据对象之间添加业务数对应的数据模型。从而方便数据的融合和处理。
加上模板文件上丰富的逻辑处理样式,可以很方便的实现页面条件渲染。
3、SPA页面
vue
- view:temp模板和style模块
- controller:script中的 生命周期,methods
- 伪model:script中的data和computed
react
- view:render方法
- controller:.jsx中的生命周期和各种逻辑处理方法
- 伪model:state
支付宝小程序
- view:axml模板文件
- controller:.js中的生命周期和各种逻辑处理方法
- 伪model:.sj中的data
上诉3个框架,虽然文件组成的方式结构各不相同,但是通过对各个功能模块的拆分,还是可以很清晰的归纳为MVC模式。
再结合动态页面的结构和SPA架构的比较:
SPA将原来服务器端的 页面渲染逻辑 和 业务控制逻辑 提前到浏览器层级上,从而减轻了服务器的压力,同时加强了前端的异步展示的能力,但是在硬性的对 页面 和 控制逻辑 的迁移中丢失了 MVC 架构中作为粘合剂存在的 model 模块。
数据模型使用的充分性
数据模型的缺失在功能实现上并不会出现大的问题,同时对于一些简单页面的开发,因为少了数据模型的构建环节,反而可以提升页面的开发效率,毕竟自己写的代码,短期内的维护是难度不大的。
但是随着各页面逻辑和数据不断的添加model的缺失开始导致:
- 作为controler载体的文件代码体量将迅速的增加,其中会混杂这很多的原始数据处理方法。
- 各个类型的伪model中将持有大量的数据,主要为页面逻辑控制数据 和 业务数据。
- 业务数据往往有着很深层级的嵌套,导致数据初始化时很难赋予合适的初始值,从而在使用数据时需要添加各种非空判断。
- 数据解释注释缺失。
理想中的对于一个陌生页面短时间内的的学习流程是:
- 能通过controller直接了解到页面的大致控制逻辑
- 能通过model了解到对应业务的大致业务逻辑
然而在缺失model的情况下,伴随着时间的推移和项目组人员的调整,无论是老成员对于代码的维护还是新成员对代码的学习,都开始变得不友好。
小结
综上,对于前端SPA项目来说,为了解决或者优化上面提到的一些问题,提升多人协作开发的效率和代码的可读性,在遵循MVC的设计思路时,添加数据模型是有充分性的。
至于数据模型的实现方式,可以之后另外讨论,毕竟js作为一种灵活的语言,要实现像iOS中的MJExtension之类的数据模型转换框架会相对容易一些。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 前端科普系列(三):CommonJS 不是前端却革命了前端
- 前端科普系列(三):CommonJS 不是前端却革命了前端
- 前端技术演进(三):前端安全
- 【前端优化】前端常见性能优化
- 【前端学习笔记】前端安全详解
- 前端监控和前端埋点
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Java5.0Tiger程序高手秘笈
BrettMclaughlin / 东南大学出版社 / 2005-10 / 28.00元
代号为 “Tiger”的下一个 Java 版本,不只是个小改动版。在语言核心中有超过 100 项以上的变动,同时有大量的对 library 与 API 所做的加强,让开发者取得许多新的功能、工具与技术。但在如此多的变化下,应该从何处开始着手?也许可以从既长又无趣的语言规范说明书开始看起;或等待最少 500 页的概念与理论巨著出版;甚至还可以直接把玩新的 JDK 看看能够有什么发现;或者借由《Jav......一起来看看 《Java5.0Tiger程序高手秘笈》 这本书的介绍吧!