中山网站建设：浅谈表现与数据分离

0.表现与数据分离是什么
伴随着一个程序的业务逻辑，会产生数据；数据从---层抽出，经过一定逻辑，就会表现到程序界面上。一个程序在界面上的表现和保存下来的数据不应该是耦合的，数据应该可以对应多个表现界面。我们常说的表现与数据分离一般是指实现这个现象的技术，尤其是指一种代码组织的方式。

1.常用方式
mvc是我们经常听到的一种代码组织方式，用于使表现与数据分离。传统的mvc结合http请求，把respone到浏览器的html全部算作为v。web2.0兴起后，在html上也包含着较多的业务逻辑，于是前端的mvc也逐渐产生，并有mvvm等新的针对于前端的代码组织方式及其他mv*框架。

2.回顾
之前我有谈及到传统mvc以javaee的struts为例，见这里)及我自己的在结合实现业务需求写的一个js模板

3.比较
3.0.传统mvc
struts这种传统的mvc，思路很清晰：你发起一个http请求，我根据请求的数据及---层查到的数据m把相应的htmlvrespone到浏览器上，处理这两者关系的那一部分是控制器c，要拿出具体代码来应该是配置的xml及相应处理这个抽象逻辑的类。

3.1.前端mvc
angular、backbone等前端的mvc，大体上也差不多。当然前端的话可以用另外一种方式：你发起一个ajax请求，服务端返回一堆json数据m，再根据特定的规则c表现到html上v。这些框架一个重要的特点是拥有路由router的概念，这是他们能称为mvc框架的一个重要原因。

3.2.mvvm
以avalon为例的mvvm框架，着力点在数据已经在前端之后，怎么样---的展现成html及维持与用户的交互。前端mv*框架一般封装的是数据与视图的直接、双向的绑定，基本操作都比较单一，数据怎么变，表现层就跟着怎么变，而没有较复杂的逻辑关系。其实我们大多数的操作也就是需要一个简单的双向映射即可，业务的复杂我们应该细拆，用多的数据去描述，而不要把多个业务逻辑描述到一个数据字段上来。

3.3.jquery
要对html操作就必然要用dom。jquery是操作dom的---js库，但以上没有一个mv*框架是基于jquery的。我认为有三点原因

1.mv*框架针对单一的双向操作，jquery针对复杂的逻辑操作。我们没---去用一个庞大的sizzle去选择到我们要操作的节点，再进行操作。mv*框架宣扬的是一种清晰的前端数据与表现分离思路，数据应该是有计划有目的地通过界面表现的，而不是-奇想忽然而来的一个操作。
2.jquery不针对文本节点和注释操作，看过源代码可知，nodetype===3 || nodetype===8的节点被jquery抛弃了，而这些都是mv*框架打着旗号能操作的，所以原生的dom操作会适合mv*框架。
3.体积、效率、代码清晰度等其他方面的原因，你把jquery引用起来，那jq到底是属于哪方面的职责？违背mv*框架的初衷了。
3.4.js模板
本人写的js模板，实质上是一个单向的mvvm框架，只考虑到了m->;v的转换，其基本思路是：用数据分别去描述一段没有业务逻辑html模板和一些分散的业务逻辑，再用一段通用的逻辑代码去把它们组合在一起，形成html展现到界面上。缺少像avalon那样的scan方式，所以是做不到v->;m的即时反馈的。

4.深入思考mv*
mv*框架一般都定义好自己的扫描范围。像angular的ng-app、avalon主要是在scan的参数上。遍历dom树寻找要绑定的数据及要展现数据的地方，否则白白浪费效率。

除了单一的双向数据绑定，mv*框架还会定义几种稍微复杂的数据表现约定。像针对数组、针对函数、针对表格等，本质上还是制定一种约定：数据只要按照这种方式去放置，我的框架就有一种内置的现成的表现形式，你就不用再去关注里面的业务逻辑了。框架就是把各位码农每天重复写来写去而技术含量不高的操作像crud给抽象出来，帮我们从繁重的重复业务中解放出来，而关注一些---的、较复杂的业务逻辑。

框架一般会给出一套事件绑定机制，让你去用它的事件。当然了，我们在input框中输入，那边的数据就立马改变，靠的必然是事件，如果用了这些框架还去自己定义事件，容易产生一些未知的错误。

引用一篇国外的博文，里面有提及到mvc的好处

?易于维护
?便于单元测试
?剔除一些重复、低层的代码
?分离了程序逻辑与表现界面，使得负责这两块的人可以同时工作
5.总结
再回到文章的，表现与数据分离是我们的目的，mvc、mvp还是mvvm，都只是一种手段。每一种语言每一个框架有其实现的具体细节。但总的思想就是：如何---地组织代码，解决表现与数据分离的问题。如果不这么组织，后果可想而知：当需求变化时，我们无法估计要修改多少处代码，也无法估计修改后会产生多少的bug，因为很多东西耦合在一起了，牵一发而动全身。我们也不一定要---于这些代码约定好的组织方式，毕竟是开源的，可以根据自己当前的项目产品实质需求进行改造。我们也不能太依赖于框架，要看到低层的实现，对于开源软件也很容易处理。

声明提示：

本页信息（文字、图片等资源）由用户自行发布,若侵犯您的权益请及时联系我们，我们将迅速对信息进行核实处理。