前端与后端分离的架构实例（一）

看了《系统架构：Web应用架构的新趋势---前端和后端分离的一点想法》 这篇文章，对前端与后端的分离很是认同，这样作对于系统的维护是有至关大的好处的。正好本身也设计了一个这样的系统，因而把它拿出来，和你们讨论一下。这个架构，与其说是想出来，还不如说是我作系统总结出来的最佳实践。

咱们作的系统，前端的页面基本都是使用 JavaScript 的富户端页面，主要应用的框架用，jquery、jquery ui、knockout js、Durandal、另外，还有本身封装的一些 UI 组件，后端的主要采用到的技术有 OData、MVC、Linq to SQL 以及本身写的一个权限管理组件，数据库采用的是 SQL Server 2005。

下面向你们介绍一下各模块的功能以及其划分的目的，咱们先从用户界面看起吧

1、关于前端的 dataProvider

简单点说，就是一个给界面调用的数据访问层，不少人都人这样的疑问，在这里加一个数据访问层，是否是多余？只要你作的前端，你都会碰到下面这些问题：

一、一个产品或者项目，前端与后端是同时进行了，这时候，根本没有后端的接口，甚至能够说，连个接口的定义都没有。做为前端开发人员，你如何去开展本身的工做？

二、做为前端开发人员，你有没有碰到，由于后端的接口挂掉，致使你的工做无法继续作下去的情形？

三、做为前端开发人员，每每免不了要和第三方的接口进行对接，你有没有碰到过，和你作对接的人员，忽然由于项目紧，被抽走了，留给你的只有一堆须要传N个参数，传了后接着出“对象为空”的异常呢？你根本不知道哪里参数传错了。面对这些接口，你除了破口大骂，得不到任何帮助。

四、做为前端开发人员，你有没有试过，你向后端的开发组，要一个接口，他们须要讨论个几天，而后再花几天才能给你，给你以后，还不能用，又得再花几天时间调试呢？

若是你向我同样，都曾经都碰过这些问题，你就不会怀疑这个 dataProvider 存在的必要了，有了这个 dataProvider，能够最大减小后端接口对前端开发的影响。下面是一个 dataProvider 的实例：

var dataProvider = (function () {

    var fakeProvider = {
        countries: new Countries()
    };

    var realProvider = {
        countries: new JData.WebDataSource()
    };

    //下面的接口，根据状况二选一
    return fakeProvider; //这个是假的 dataProvider，从本地读
    return realProvider; //这个是真正 dataProvider，从接口读
})();

从上面能够看出来，这个 dataProvider 使用了工厂模式来建立，它有两个实例，fakeProvider和realProvider，fakeProvider是用来提供一些模拟数据，而realProvider提供从接口读取出来的数据。当没有接口，或者接口挂掉，咱们能够先从 fakeProvider 来读取数据。等接口好了，切换到 realProvider 。

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

一、数据的验证。用户在界面输入数据后，接着调用 dataProvider 里的接口对数据进行处理，可是在向服务端提交以前，得先对数据进行验证。那个这个验证如何进行呢？dataProvider先从服务端获实体的描述信息，这些描述包括但不限于：主外键、属性的验证信息（好比是否可空），固然，这个实体信息是能够缓存起来，以便重用的。而后 dataProvider 再根据这个描述信息来对数据进行验证。

二、错误信息的显示

当验证到某一个属性不合法，验证信息的模块就在页面查找出对应输入控件，它是怎么查找的呢？好比说，Contry 的 Name 输入为空是不能够的。那它就先查找 id 为Coutry的元素，而后再Coutry元素下面再找id 或者 name 为 Name 的控件，若是找不到则直接弹窗显示错误信息。例如：

<form id="Country">
       <input name="Name"/>
</form>

 

3、关于后端使用 OData

一、做为后端开发人员，你有没有碰到过这种前端开发人员，今天让你加一个字段，好，加了，而后打包发布。明天又让你加一个字段。后天忽然又说，前两天加的字段，不须要，你会不会有种想喊“操”的冲动？

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

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

4、关于后端使用MVC

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

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

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

5、数据访问层

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

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

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

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

 

这篇文章到此结束，欢迎你们的板砖。

PS:过年的时候，我会把 ALinq 和 Visual Entity 更新到 2013，各位用户就别催更了，最近实在是忙，抽不出时间更新呀。

 

 

公司招聘

初级程序员：懂 JQuery、JQuery UI、JQuery Validate、Knockout JS 等JS 框架，略懂 Linq to SQL，能阅读文档，根据文档示例写代码

中级程序员：有阅读上述框架的代码，并根据项目作订制开发

高级程序员：具体很强的编码能力，能解决各类疑难杂症

牛人：能把设计模式、代码玩弄于股掌之间

地点：上海市闸北区

网站：http://www.vknew.com/index.html

在找工做的朋友能够私信我。