前言

在MVC、MVVC等前端经典常用开发模式中，V、C往往是重头戏，可能是前端业务主要集中这两块。结合实际业务，笔者更喜欢路由模式、插件式设计，这种在迭代和维护上更能让开发者受益（不过你需要找PM协调这事，毕竟他们理解的简化用户体验，多半是怎么让用户操作简单）。但我们今天来看看Model，看看M有什么扩展的可能。

背景

在读到本文之前，你实际项目（如React+Redux）中请求服务器数据，可能是如下策略：

1. componentDidMount 中发送redux action请求数据；
2. 在action中发起异步网络请求，当然你已经对网络请求有一定封装；
3. 在网络请求内部处理一定异常和边际逻辑，然后返回请求到的数据；
4. 拿到数据this.setState刷新页面，同时可能存一份到全局redux中；

正常情况下，一个接口对应至少一个接口相应Model，万一你还定义了接口请求的Model、一个页面有5个接口呢？

如果项目已经引入TypeScript，结合编写Model，你的编写体验肯定会如行云流水般一气呵成！但实际开发中，你还需要对服务器返回的数据、页面间传递的参数等涉及到数据传递的地方，做一些数据额外工作：

• 对null、undefined等空值的异常处理（在ES最新方案和TS支持里，新增：链式调用?和运算符??，请读者自行查询使用手册）；
• 对sex=0、1、2，time=1591509066等文案转义；
• （还有其他吗？欢迎留言补充）

作为一个优秀且成熟的开发者，你肯定也已经做了上述额外的工作，在utils文件下编写了几十甚至上百的tool类函数，甚至还根据函数用途做了分类：时间类、年龄性别类、数字类、......，接着你在需要的地方import，然后你开始进行传参调用。是的，一切看上去都很完美！

上面这个流程说的就是笔者本人，:)。

现况

随着项目和业务的迭代，加上老板还是压时间，最坏的情况是你遇到了并没有遵守上述"开发规范"的同事，那结果只能是呵呵呵呵呵了。下面直接切入正题吧！

上述流程虽说有一定设计，但没有做到高内聚、低耦合的原则，个人觉得不利于项目后期迭代和局部重构。

推荐另一个设计原则：面向对象五大原则SOLID[3]

下面举个例子：

• 接口里字段发生变更时，如性别从Sex改为Gender；
• 前端内部重构，发现数据模型不匹配时，页面C支持从页面A附加参数a、或页面B附加参数b跳入，重构后页面B1附加参数b1也要跳转C。从设计来说肯定是让B1尽量按照以前B去适配时是最好的，否则C会越来越重。

上面提过不管是页面交互，还是业务交互，最根本根本是数据的交换传递，从而去影响页面和业务。数据就是串联页面和业务的核心，Model就是数据的表现形式。

再比如现在前后端分离的开发模式下，在需求确认后，开发需要做的第一件事是数据库设计和接口设计，简单的说就是字段的约定，然后在进行页面开发，最终进行接口调试和系统调试，一直到交付测试。这期间，后端需要执行接口单元测试、前端需要Mock数据开发页面。

如何解决

接口管理

目前笔记是通过JSON形式来进行接口管理，在项目初始化时，将配置的接口列表借助于 dva[4] 注册到Redux Action中，然后接口调用就直接发送Action即可。最终到拿到服务器响应的Data。

接口配置（对应下面第二版）：

（编辑：柳州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!