前后端分离的架构示例

一个优秀的WEB架构一定要应用一些分层的设计思想，这样可以使系统开发更加灵活，也便于后期维护。本文作者麦树设计了前后端分离的架构。原文分享如下：看完《系统架构：Web应用架构的新趋势—前端和后端分离的一点想法》一文，赞同前后端分离。这对系统的维护有很大的好处。.正好我也设计了这样一个系统，就拿出来和大家一起讨论。这个架构与其说是一个想法，倒不如说是我从系统中总结出来的最佳实践。在我们做的系统中，前端页面基本上都是使用JavaScript的富客户端页面。主要应用框架有jquery、jqueryui、knockoutjs、Durandal。此外，还有一些我们自己封装的UI组件。后端主要用到的技术有OData、MVC、LinqtoSQL，还有自己写的一个权限管理组件。数据库使用的是SQLServer2005，下面介绍一下各个模块的作用和划分的目的。让我们从用户界面开始。首先，前端dataProvider只是一个接口调用的数据访问层。很多人都有这样的疑问。,在这里加一个数据访问层是不是多此一举？只要做前端，就会遇到以下问题：1、对于一个产品或项目，前端和后端是同时进行的。这个时候根本就没有后端接口，甚至可以说没有接口的定义。.作为一名前端开发人员，你是如何开展工作的？2、作为前端开发者，你是否遇到过因为后台接口宕机而无法继续工作的情况？3、作为前端开发者，很多时候都免不了要对接第三方接口。你有没有遇到过一个和你有缘的人，却因为项目太紧突然被带走，留给你的只有一堆需求？传N个参数，传完就抛出“对象为空”的异常怎么办？你不知道参数哪里错了。面对这些接口，你除了大喊大叫之外，得不到任何帮助。4.作为一个前端开发者，你有没有试过，你向后端开发团队要一个接口，他们要讨论几天，然后再过几天给你。调试需要多少天？如果你和我一样，以前遇到过这些问题，你就不会怀疑这个dataProvider的必要性了。有了这个dataProvider，就可以将后端接口对前端开发的影响降到最低。下面是dataProvider的例子：vardataProvider=(function(){varfakeProvider={countries:newCountries()};varrealProvider={countries:newJData.WebDataSource()};//如下接口，根据第二种情况ChooseareturnfakeProvider;//ThisisafakedataProvider,readfromthelocalreturnrealProvider;//ThisisarealdataProvider,readfromtheinterface})();从上面可以看出，这个dataProvider是使用工厂模型创建的，它有两个实例，fakeProvider和realProvider，fakeProvider用来提供一些模拟数据，realProvider提供从接口读取的数据。当没有接口，或者接口宕机时，我们可以先从fakeProvider中读取数据。当接口准备好后，切换到realProvider。二、用户界面输入的校验1、数据校验。用户在接口中输入数据后，再调用dataProvider中的接口对数据进行处理，但数据在提交给服务器之前必须经过校验。该验证如何工作？dataProvider首先从服务器获取实体的描述信息。这些描述包括但不限于：主键和外键、属性验证信息（比如是否可为空），当然这些实体信息可以缓存起来以供复用。然后dataProvider根据这个描述信息对数据进行校验。2、错误信息的显示当验证到某个属性不合法时，信息验证模块会在页面上找到对应的输入控件。它是如何找到它的？例如，Contry的Name输入是不允许为空的。然后它首先查找id为Coutry的元素，然后在Coutry元素下查找id或name为Name的控件。如果找不到，会直接弹出错误信息。例如：3、关于OData1的后端使用，作为后端开发者，你遇到过这样的前端开发者吗？今天让你加一个字段，好吧，加了，然后打包发布。让你明天再增加一个字段。后天突然说前两天加的字段不用了。是不是有想大喊“操”的冲动？2、作为后端开发者，你有没有遇到过这样的前端开发者，今天跟你说接口不够，需要加一个GetUserByName方法，明天又说必须加一个GetUserByEmail方法？然后，一段时间后，你发现接口越来越多，维护的模块越来越臃肿，而这些接口你只敢加，不敢删。因为你根本不知道这些东西，你问前端有没有什么用不到的，他也答不上来。因此，即使有些接口没有用，也只能永远存在于系统中，直到其生命周期结束。如果你也遇到像我这样的麻烦，使用OData可能是个不错的选择，把查询权限开发给前端开发人员，他想查什么就查什么，放手不管。4、关于后端MVC的使用我们的系统使用MVC来处理前端提交的数据。主要供熟悉MVC的开发者使用，然后MVC调用业务层代码。同时还需要处理：1.验证提交的数据2.处理系统异常，包括将异常重新打包返回给客户端，方便客户端处理。记录异常信息。5.数据访问层关于数据访问层，在我们的系统中其实就是一个ORM包装器（ORMWrapper），你是在ORM上面包裹了一层外衣。目的是：1.拦截数据。例如：有些数据只针对某个角色的养成。数据访问层需要根据过滤条件重新生成SQL，再结合查询条件。2、误删除数据的处理。我见过很多把删除放在业务层的系统。事实上，这是不合适的。从业务的角度来看，我关心的是删除。执行删除后，这条数据就从我眼前消失了。向上。真删还是假删与我无关。这是数据访问层必须做的。它可以在真删除和假删除之间切换数据。只需将其配置为将真删除更改为假删除（实际上是将Delete操作更改为Update操作）。让业务开发人员不再需要关心数据的真假删除。3.跟踪和备份数据。你一定遇到过这样的需求，需要记下每次更新操作的时间，更新了哪些内容。对于删除的数据，可以恢复。数据访问层，通过对ORM的包装，可以记录每一次更新和删除操作，然后记录下来。当然，这些需求也可以通过使用数据提供的功能来实现，不在讨论范围之内。