web前端与后端分离的架构实例分析

本文主要讲解“web前端与后端分离的架构实例分析”。感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习《web前端与后端分离的架构实例分析》！

一、关于前端的 dataProvider

简单地说，它是接口调用的数据访问层。很多人都有这个疑问。这里没有必要增加数据访问层吗？只要做前端，就会遇到以下问题：

1.对于一个产品或项目，前端和后端是同时进行的。此时根本没有后端接口，甚至没有接口的定义。作为一个前端开发人员，你是如何做好自己的工作的？

2.作为一个前端开发人员，有没有遇到过因为后端接口挂机而导致工作无法继续的情况？

3.作为一个前端开发人员，不可避免的要连接第三方接口。你有没有遇到过和你连接的人，因为项目紧张突然被带走，只剩下一堆需要传输的N个参数，然后“对象为空”的异常就出来了？你不知道参数错在哪里。面对这些接口，除了骂人，你得不到任何帮助。

4.作为一个前端开发人员，你有没有试过向后端开发团队要一个接口？他们需要讨论几天，然后还需要几天才能给你。给你之后就不能用了，还要几天调试？

如果你像我一样，以前遇到过这些问题，你不会怀疑这个数据提供者的必要性。有了这个数据提供器，你可以减少后端接口对前端开发的影响。下面是一个数据提供者的例子：

vardata provider=(function(){ varfakeProvider={ countries : newcounters()}；varreal provider={ countries : newjdata。webdata source()}；//下面的界面，根据情况选择returnfakeProvider之一；//这是一个假的数据提供者。在本地读取returnrealProvider//这是真正的数据提供者，从接口读取})()；从上面可以看出，这个数据提供程序是使用工厂模式创建的。它有两个实例，fakeProvider和realProvider。fakeProvider用于提供一些模拟数据，而realProvider则提供从接口读取的数据。当没有接口，或者接口挂起时，我们可以先从fakeProvider读取数据。当接口准备好了，切换到realProvider。

二、关于用户界面输入的验证

1.数据验证。在用户界面中输入数据后，再调用dataProvider中的接口来处理数据，但是在提交给服务器之前，必须先对数据进行验证。这种验证是如何工作的？提供者首先从服务器获取实体的描述信息，包括但不限于：主键和外键、属性的验证信息(如可空性)。当然，这个实体信息可以被缓存以供重用。然后数据提供者根据这个描述信息验证数据。

2.错误信息的显示

当某个属性被验证为非法时，信息验证模块会在页面上找到对应的输入控件。它怎么找到的？例如，不允许将控件的名称输入留空。然后它首先查找id为Coutry的元素，然后在Coutry元素下面查找id或Name名称的控件，如果找不到，就会弹出一个窗口直接显示错误消息。示例：

来自三、关于后端使用 OData的formid=' Country ' input Name=' Name '/表单

1.作为后端开发者，你遇到过这样的前端开发者吗？今天，我想让你添加一个字段。好的，添加，然后打包发布。让您明天添加另一个字段。突然后天我说前两天加的字段没必要。你有没有一种想喊“操”的冲动？

2、

作为后端开发员员，你有没有碰到过这种前端开发人员，今天跟你说接口不够用，要加个 GetUserByName 的方法，明天又说，还得加个 GetUserByEmail 的方法？然后，过了一段时间，你发现接口越来越多，维护的模块越来越痈肿，并且这些接口，你只敢加，不敢删除。因为，你根本不知道这些，有哪个不用的，你跑去问前端，他也回答不出来。所以一些接口哪怕是没用的，也只能永远系统里，直到它生命周期的结束。

如果你也碰到类似于我这种烦恼，使用 OData 也许是一个不错的选择，把查询的权限都开发给前端的开发人员，他爱怎么查就怎么查，都由它去。

四、关于后端使用MVC

我们的系统，使用MVC都是用来处理从前端提交上来的数据的，使用它主要是开发人员都熟悉MVC，然后MVC再调用业务层代码，同时，还需要处理:

1、对提交上来的数据进行验证

2、处理系统的异常，包括对异常进行重新的包装，再传回到客户端，以便于客户端的处理。对异常的信息进行记录。

五、数据访问层

关于数据访问层，在我们的系统里实际是一个 ORM 的包装器（ORM Wrapper），你在对 ORM 裹上一层外衣。目的在于：

1、对数据进行拦截。例如：有些数据，只对某个角色的开发。数据访问层需要对根据过滤条件，然后再结合查询条件，重新生成SQL。

2、对数据假删除的处理。见过很多系统，都是把删除放到业务层来进行的，其实这是不适合的，从业务的角度来说，关心的是删除，在执行删除后，这条数据从我眼前消失就可以了。至真删除还是假删除，这与我无关。数据访问层，要做的就是这工作，它可以数据在真删除与假删除之间进行切换，只要配置一下，就可以把真删除变成假删除（其实就是把Delete操作变成Update操作），使得进行业务开发人员，不用再关心数据的真假删除。

3、对数据进行跟踪、备份。你肯定碰到过这么一种需要，需要记下来，每一次的更新操作的时间，以及更新了些什么内容。对于删除的数据，能够把它还原回来。数据访问层，通过对 ORM进行包装，完全可以记录下每一次更新、删除这些操作，然后记录下来即可。当然，这些需求利用数据提供的功能也是可以实现的，不在讨论的范围内。

到此，相信大家对“web前端与后端分离的架构实例分析”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！