JS分层的概念与本地存贮

核心提示：以前学了一个月的asp.net算没学，把三层结构的概念改改就套在JS上，JS分层的概念与本地存贮，^^，那JS要怎样分层呢？其实主要是多了一个页面级的数据库表现层：处理UI呈现业务逻辑层：除了上面跟下面的都算在这个里面，或者某些后台管理、QZone等那些一个页面搞定一切的网站，当然这也不是空口说白话的，当然我不介意你再

以前学了一个月的asp.net算没学，把三层结构的概念改改就套在JS上。^^，那JS要怎样分层呢？其实主要是多了一个页面级的数据库

表现层：处理UI呈现

业务逻辑层：除了上面跟下面的都算在这个里面。当然我不介意你再细分^_^

数据与数据维护层：JS存数据也不是一天两天的事。可有多少人在网页维护JS数据库呢？

为什么要给自己找麻烦呢，把本来简单的东西复杂化，要数据找服务器要，自己干啥还得维护多一份数据，多无聊。主要的原因是：

页面缓存数据，减少与服务端之间的交互。

页面缓存数据有什么意义，比如在不稳定的无线网络里，不是每个操作都去访问网络，也就不会有因为不稳定网络引起的一大堆乱七八糟的问题。

实现预加载，加快访问速度。

Gmail的新版本号称邮件一点就开，其实是在网络空闲的时候，把数据先当下来。我没去看Google那些恶心的代码。估计也是用JS构建一个页面级的数据库。

方便数据二次呈现。

变更数据呈现有个“本地数据库”来查询自然方便多了。挖哈哈

当然也有一些负面的作用。比如性价比没那样高，以前，我们从服务器要到数据后一般就直接或者转换一下innerHTML到界面，如果按这种方式就一定要多存份到“数据库”。去掉某些东西时也要去通知“数据库”。由于JS的受限，我们折腾了半天的“数据库”在刷新一下就干掉了。这不是折腾吗? 看看Gmail是怎样做的，虽然它也是一刷新就干掉，但它已经养成用户一种习惯了GMail是不用刷新滴，挖哈哈。

当然，我们还是比较贪心的。如果能再加上本地存贮的话，折腾就少了点。现在离线比较出名的算是google的Gears，不过我对它没兴趣，估计我做的产品的用户们没人听说过它，再别说会使用，好像最近也给GFW的样子 。本地存贮如果要用的话，应该尽可能使用浏览器的原生技术。比如IE有userData、Firefox有sessionStorage，怎样用呢？石头老大写过一篇关于怎样操作的。当然也有人用flash来存东西，100K哦。

综合来说页面级的数据库并非适合所有的产品，个人认为最适合邮箱，或者某些后台管理、QZone等那些一个页面搞定一切的网站。当然这也不是空口说白话的，我已经在项目中一个模块尝试过。一点就开的感觉很爽滴~