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

内容简介：前端开发过程中能完全不依赖后端的才是真正的前后端分离指的是工作过程中，前端的的代码中往往会掺杂一些后端的逻辑。后端返回了一个json对象

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

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

例子

后端返回了一个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)
            })
    })
}

项目的后期维护

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

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

以上所述就是小编给大家介绍的《个人对前后端分离的一些看法》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。