漫谈界面和数据

下面的文字是关于界面和数据的,是在做了项目之中之后的心得体会。求指导,欢迎斧正。

刚开始接触界面编程的时候,还不能意识到界面和数据的概念。所以代码的思路纯粹是跟着感觉走的,和搭积木一样。这时候,我更倾向于按照习惯——按事物的功能分类,把界面和数据代码放到同一个地方,这样让我对界面和数据(当时还没有清晰的概念)有满意的控制优越感。正是初学者,一开始都动手做自己YY的小软件,数据和界面的问题并不是很突出。这时候做到界面元素和业务逻辑的结合显然意义不大——后来发现句话说的有点早。

原因是往后我又YY了下,想升级下上次小软件的功能。可是越到后来越是发现升级很困难。于是不得不丢弃这个软件的升级。所有的业务逻辑被封装在界面代码里头,对数据的掌控就不那么随心所欲了——这句话也太早了。因为这样界面元素和数据之间得到更新或者同步方便很多,界面可以直接获取,而不是跨越其他的对象。

注意,所谓的界面元素和业务逻辑的分离并不是界面和数据井水不犯河水,既然是可视化的编程那么界面和数据就可定会有交互。就比如编辑框你可能需要在显示编辑框的时候希望它能够显示数据,这里就存在交互了。

但要做到界面数据和后台数据的同步就不是那么直观了。例如,需要实现界面数据和后台数据的同步等,这时候如果业务逻辑仍被死死捆绑在界面内的话,界面和数据就真真正正打死结,可能说的有点严重,但很可能会对工程作较大的修改。在MFC中,我是这么做的。界面和数据做适当的分离。首先一块界面/界面数据区,界面/数据捆绑器,数据区。

  1. 界面/界面数据区负责UI设计和界面数据的显示。

  2. 界面/数据捆绑器负责维护界面和业务逻辑之间的同步等等。

  3. 数据区则负责纯数据的管理。

在请教先生的时候,先生有建议把数据处理部分独立开来,这可以提高代码的复用。哈,最后的数据区正是为此独立出来的。 在界面元素相对单一,并且在不考虑升情况下,YY是很不错的选择,对程序员来说,愉悦身心。但反之,最好三思而后行。最后需要记下的是,界面永远是数据的奴仆。我认为,分析架构一个项目,数据先行!

本文完 2012-09-14

捣乱小子 http://www.daoluan.net/blog/

14 September 2012

disqus 可能被墙~