wpf+mvvm代码组织结构及实现方式

还记得我上大学时候有幸接触wpf开发&＃xff0c;也是那时候我开始接触到了mvvm模式&＃xff0c;心里一阵欣喜&＃xff0c;心想这个模式使得我们可以更加的专注于业务并且更加高效的完成业务代码编写&＃xff0c;而不是还要考虑其他跟业务配套不相关的代码&＃xff0c;那个时候还是流行mvc的开发模式&＃xff0c;不过在我心目中mvvm是吊打mvc的存在。同时代web前端还是估计还是大量用jquery&＃xff0c;没什么前后端分离的概念。

举一个当没有mvvm的时候的处理数据跟ui交互的例子&＃xff0c;先设置数据

设置ui&＃xff0c;这部分如果你做过pc开发或者移动开发就知道一般都是编辑器拖动控件完成的&＃xff0c;也相当于与现在前端里提到的组件化

接下来写相关的业务

我们现在使用setTimeOut来模拟数据改变

一个非常简单的业务&＃xff0c;这里边我们花费了大量的劳动力去写了原始数据改变了给ui重新赋值&＃xff0c;ui如果能改变数据&＃xff0c;当ui触发数据改变时候&＃xff0c;我们也要同样的去改变原始数据。写了很多与业务无关的代码。能不能我只管写原始数据的结构&＃xff0c;然后撒手直接丢给ui&＃xff0c;你们改变数据你们自己改我不管&＃xff0c;如果能实现真的是解放了大量的劳动力&＃xff0c;我们可以不用加班&＃xff0c;我们可以花更多时间去过happy time等等。。。。

就在这个时候聪明的程序员去开发了一套mvvm机制&＃xff0c;使得我们可以免除大量的劳动力去做真正该做的事&＃xff0c;那么mvvm是怎么实现的呢&＃xff0c;我们现在手动实现自己的mvvm。

先理一下思路&＃xff0c;当原始数据变化的要去通知ui&＃xff0c;那么这个突破口就是原始数据我们先把数据加工吧。

现实现每个对象当他子数据改变的时候去通知&＃xff0c;那么动手实现。

这一步还算简单&＃xff0c;我们首先内部定了新的bindingObj&＃xff0c;给这个bindingObj浅拷贝原始obj&＃xff0c;然后给原始obj设定set跟get&＃xff0c;set的时候给bindingObj设定值然后去通知&＃xff0c;get时读取bindingObj的数据。

这还不够我们继续完善&＃xff0c;我们发现代码里handleChange时候调用callback的接口,我们现在去写外部可以传入callback的地方&＃xff0c;跟强制触发change地方。

最终代码是这样上面例子中&＃xff0c;我们使用了浅拷贝而不是深拷贝&＃xff0c;因为我觉得深拷贝耗费性能。

如果有改动的话可以浅拷贝传参或者改完数据调用setChange就可以了&＃xff0c;还有就是添加新的字段的时候也要调用setChange就可以了。

接下来我们改写上边ui跟数据交互的例子。

你会发现controller这边代码大幅减少&＃xff0c;还有setTimeOut里边逻辑简洁不少&＃xff0c;不过这时候你会发现这不就是吧controller里边的代码移到view1里边了吗&＃xff0c;你骗人哪里少些代码了。

因为是这样现在我们的h1跟input 还没有重新封装他们现在让我们封装一下吧。

大功告成了。现在我们把每个ui元素都封装成了组件&＃xff0c;导致view可以统一处理了&＃xff0c;你会说现在是有改动就更新全部数据&＃xff0c;当然你如果愿意完全可以在回调里传参数&＃xff0c;来更新确定的字段&＃xff0c;当然你会发现我没改动一次数据这个view就要更新是不是太费性能了&＃xff0c;我们现在改变一下view

改动代码后view在60帧的速度更新数据&＃xff0c;当他发现数据变了就会更新view否则就不会更新&＃xff0c;现在你是不是终于懂了为什么react或者vue数据改变为什么不会实时更新而是异步更新了吧。