个人对前后端分离的一些看法

最初的见解

前后端只通过api通信的就是前后端分离

有一种很特别的见解

前端开发过程中能完全不依赖后端的才是真正的前后端分离

指的是工作过程中，前端的的代码中往往会掺杂一些后端的逻辑。

例子

后端返回了一个json对象：

const data = {
    total:100,
    apple:30
}
复制代码

前端需要展示的apple的占比，因此在展现的过程中会在业务逻辑或者html模版中含有了数据的转换处理

这种因为后端返回的数据并非是完全处理完的数据，从而导致前端代码掺杂了一些‘多余’代码的情况，可以视为‘非完全的前后端分离’

缺点

• 前端代码不够简洁
• 后期维护差
• 拖慢工作进度
• 前后端联调累

一种更加友好的前后端分离的工作模式

前端的mvc（mvvm）的软件设计，这个概念往往只是针对整个代码的逻辑做出的抽象。然而单纯的看代码目录我们是无法区分这个项目有没有用mvc（mvvm）。 那么我们是否可以通过文件划分实现的目录层面的mvc划分呢。

• m：api数据转换层（关键）
• v：html视图层
• c：js业务逻辑层

api转换层（关键）

项目中专门起一个目录作为api转换层，对内做数据转换，对外暴露api接口。

一个例子

前后端并行开发的过程中，前端无视后端，在需要接口的页面先mock一个符合前端业务需求的最简洁的数据结构进行开发。后期前后端联调的时候我们只需针对后端返回的数据做一个转换层，输出之前mock的数据形式。

    // 数据转换层
export const getUserInfo = () => {
    // 定义一个Promise在内部作数据转换处理
    return new Promise((resolve, reject) => {
        axios
            .get(`/sys/user/info`)
            .then(({
                data
            }) => {
                // 接入api并在自定义的handler函数转换数据结构
                resolve(
                    handler(data)
                )
            })
            .catch(error => {
                // 在没有接入api之前在这里resolve输出mock数据
                resolve({
                    code：0,
                    errMessage：'success',
                    data: {
                        user: {
                            userId: 1,
                            username: 'admin',
                            email: 'admin@126.com',
                        }
                    }
                })
                reject(error)
            })
    })
}
复制代码

项目的后期维护

后端随意改接口：只需改接口转换层，无需更改业务逻辑。

项目需求更改： 前端可以在接口转换层中转换输出更加简洁的数据结构，业务逻辑层的改动更加少

转载于:https://juejin.im/post/5cfa9b275188254abb1117fe