对于前端 MVC 来说, DOM API 是否是过度封装了?

Question

没从C++/Java学起,对MVC和面向对象的理解还是后来慢慢积累起来的
相对我觉得脚本语言各种范式各种灵活,只是缺少面向对象组织代码的整齐呆板
而且从前使用DOMAPI时候就觉得DOM就像一种数据类型,
JS操作数据同时,也在更改界面.通过直接访问界面,也能读取数据,很强大对吧但我接触Backbone一段时间,困惑也觉得越来越多
而从前灵活解决前端问题的思路,随着MVC提出的分离有了各种阻碍,或者不方便直接JSDOM操作吧
MVC在Backbone里是Model和View-Controller两者分离,另加上Collection.
每次Model(Collection)发生改变,View重新渲染一次,然后搞定
或者DOM上的事件从Controller传到Model里进行一次改变,View跟着改变好
这样其实jQuery丰富的DOM操作就显得无所用处如果在Backbone的应用里加上大量的DOM操作,View刷新时又变得尴尬
为了性能,JS在进行DOM操作时会讲操作全在HTML字符串里存储好,一次写入
可在Backbone里,如果小的item也是Model,那么render也是分开了自己做的
我理解,这样两者就不能够很好地兼容,至少有一个方面要打折扣了另一个功能是实时保存和更新,纯的DOM操作,JS监听DOM,在背后保存数据很简单
可在MVC里Model被监听,每次更新操作就会导致界面被重新绘制,也显得很怪

Answer 1

Backbone基本没有关于Dom渲染的功能.所以从jQuery角度讲,数据ajax过来后直接操作Dom感觉很直观,没必要在重新定义一个model.但是如果同样的数据在同一个页面多处使用呢?同一个数据在多个页面多出使用呢.作为SPA,所以都在一个页面上,这样把ajax过来的数据抽象成一个model,就比较方便.但Backbone的view没有加入bind的功能,所以感觉上还需要在view上监听model变化再render刷新整个view.建议使用一个插件modelbinder.这样数据变化后就不需要刷新整个view而是只更新某个属性对应的小dom,一般就是span标签或某个input标签,这样大大简化程序复杂度,代码方便,而且性能更好.backbone,由于没有C,整个都是view里面,而view的设计有没有集成模板和dom渲染,显得有些不太好用.所以其他的框架例如angularjs,knockout都提出ViewModel的概念就是数据绑定的概念,只要model变化了数据,view会自动变化,非常方便.而backbone并没有提供这些功能,而只是一个代码组织的框架.angular里面基本不在需要jQuery操作DOM,就是数据和View是一体的.数据和view是绑定的,没有在单独操作dom的概念.