需要记下来，对数据进行跟踪、备份。肯定碰到过这么一种需要。每一次的更新操作的时间，以及更新了些什么内容。对于删除的数据，能够把它还原回来。数据访问层，通过对 ORM进行包装，完全可以记录下每一次更新、删除这些操作，然后记录下来即可。当然，这些需求利用数据提供的功能也是可以实现的不在讨论的范围内。这样做对于系统的维护是有相当大的好处的正好自己也设计了一个这样的系统，对前端与后端的分离非常认同。于是把它拿出来，和大家讨论一下。这个架构，与其说是想出来，还不如说是做系统总结进去的最佳实践。
前端的页面基本都是使用 JavaScript富户端页面，做的系统。主要应用的框架用，jquerijqueriuiknockoutjsDurand另外，还有自己封装的一些 UI组件，后端的主要采用到技术有 ODataMVCLinqtoSQL以及自己写的一个权限管理组件，数据库采用的SQLServer2005。下面向大家介绍一下各模块的功能以及其划分的目的先从用户界面看起吧。
一、关于用户界面输入的验证
接着调用 dataProvid里的接口对数据进行处置，数据的验证。用户在界面输入数据后。但是向服务端提交之前，得先对数据进行验证。那个这个验证如何进行呢？dataProvid先从服务端获实体的描述信息，这些描述包括但不限于：主外键、属性的验证信息（比方是否可空）当然，这个实体信息是可以缓存起来，以便重用的然后 dataProvid再根据这个描述信息来对数据进行验证。错误信息的显示，验证信息的模块就在页面查找出对应输入控件，当验证到某一个属性不合法。怎么查找的呢？比如说，ContriName输入为空是不可以的那它就先查找 id为Coutri元素，然后再Coutri元素下面再找id或者 name为 Name控件，如果找不到则直接弹窗显示错误信息。例如：
<formid="Country">
<inputname="Name"/>
</form>
二、关于前端的dataProvider
就是一个给界面调用的数据访问层，简单点说。很多人都人这样的疑问，这里加一个数据访问层，不是多余？只要你做的前端，都会碰到下面这些问题：前端与后端是同时进行了这时候，一个产品或者项目。根本没有后端的接口，甚至可以说，连个接口的定义都没有。作为前端开发人员，如何去开展自己的工作？有没有碰到因为后端的接口挂掉；作为前端开发人员。导致你工作没法继续做下去的情形？往往免不了要和第三方的接口进行对接；作为前端开发人员。有没有碰到过，和你做对接的人员，突然因为项目紧，被抽走了留给你只有一堆需要传N个参数，传了后接着出“对象为空”异常呢？根本不知道哪里参数传错了面对这些接口，除了破口大骂，得不到任何协助；有没有试过作为前端开发人员。向后端的开发组，要一个接口，需要讨论个几天，然后再花几天才能给你给你之后，还不能用，又得再花几天时间调试呢？都曾经都碰过这些问题，如果你向我一样。就不会怀疑这个 dataProvid存在必要了有了这个 dataProvid可以最大减少后端接口对前端开发的影响。下面是一个 dataProvid实例：
vardataProvid=function{
varfakeProvid={
countries:newCountri
};
varrealProvid={
countries:newJData.WebDataSourc
};
根据情况二选一 //下面的接口。
returnfakeProvider;//这个是假的dataProvid从本地读
returnrealProvider;//这个是真正 dataProvid从接口读
};
这个 dataProvid使用了工厂模式来创建，从上面可以看出来。有两个实例，fakeProvid和realProvidfakeProvid用来提供一些模拟数据，而realProvid提供从接口读取进去的数据。当没有接口，或者接口挂掉，可以先从 fakeProvid来读取数据。等接口好了切换到realProvid。
三、关于后端使用MVC，使用MVC都是用来处置过去端提交上来的数据的使用它主要是开发人员都熟悉MVC然后MVC再调用业务层代码，系统。同时还需要处理:对提交上来的数据进行验证，包括对异常进行重新的包装，处置系统的异常。再传回到客户端，以便于客户端的处置。对异常的信息进行记录。
四、关于后端使用 OData，有没有碰到过这种前端开发人员，作为后端开发人员。今天让你加一个字段好加了然后打包发布。明天又让你加一个字段。后天突然又说，前两天加的字段，不需要，会不会有种想喊“操”激动？有没有碰到过这种前端开发人员，作为后端开发员员。今天跟你说接口不够用，要加个 GetUserByNam方法，明天又说，还得加个 GetUserByEmail方法？然后过了一段时间，发现接口越来越多，维护的模块越来越痈肿，并且这些接口，只敢加，不敢删除。因为根本不知道这些，有哪个不用的跑去问前端，也回答不出来。所以一些接口哪怕是没用的也只能永远系统里，直到生命周期的结束。使用 OData也许是一个不错的选择，如果你也碰到类似于我这种烦恼。把查询的权限都开发给前端的开发人员，爱怎么查就怎么查，都由它去。
五、数据访问层，系统里实际是一个 ORM包装器（ORMWrapper对 ORM裹上一层外衣。目的于：关于数据访问层。只对某个角色的开发。数据访问层需要对根据过滤条件，对数据进行拦截。例如：有些数据。然后再结合查询条件，重新生成SQL，都是把删除放到业务层来进行的其实这是不适合的从业务的角度来说，对数据假删除的处置。见过很多系统。关心的删除，执行删除后，这条数据从我眼前消失就可以了至真删除还是假删除，这与我无关。数据访问层，要做的就是这工作，可以数据在真删除与假删除之间进行切换，只要配置一下，就可以把真删除变成假删除（其实就是把Delet操作变成Update操作）使得进行业务开发人员，不用再关心数据的真假删除。