2012-09-15 00:18：瞅着要不要发？！求指导，欢迎斧正。以下是原文。
下面的文字是关于界面和数据的，是在做了项目之中之后的心得体会。求指导，欢迎斧正。
刚开始接触界面编程的时候，还不能意识到界面和数据的概念。所以代码的思路纯粹是跟着感觉走的，和搭积木一样。这时候，我更倾向于按照习惯——按事物的功能分类，把界面和数据代码放到同一个地方，这样让我对界面和数据（当时还没有清晰的概念）有满意的控制优越感。正是初学者，一开始都动手做自己YY的小软件，数据和界面的问题并不是很突出。这时候做到界面元素和业务逻辑的结合显然意义不大——后来发现句话说的有点早。
原因是往后我又YY了下，想升级下上次小软件的功能。可是越到后来越是发现升级很困难。于是不得不丢弃这个软件的升级。所有的业务逻辑被封装在界面代码里头，对数据的掌控就不那么随心所欲了——这句话也太早了。因为这样界面元素和数据之间得到更新或者同步方便很多，界面可以直接获取，而不是跨越其他的对象。
注意，所谓的界面元素和业务逻辑的分离并不是界面和数据井水不犯河水，既然是可视化的编程那么界面和数据就可定会有交互。就比如编辑框你可能需要在显示编辑框的时候希望它能够显示数据，这里就存在交互了。
但要做到界面数据和后台数据的同步就不是那么直观了。例如，需要实现界面数据和后台数据的同步等，这时候如果业务逻辑仍被死死捆绑在界面内的话，界面和数据就真真正正打死结，可能说的有点严重，但很可能会对工程作较大的修改。在MFC中，我是这么做的。界面和数据做适当的分离。首先一块界面/界面数据区，界面/数据捆绑器，数据区。
- 界面/界面数据区负责UI设计和界面数据的显示。
- 界面/数据捆绑器负责维护界面和业务逻辑之间的同步等等。
- 数据区则负责纯数据的管理。
在请教先生的时候，先生有建议把数据处理部分独立开来，这可以提高代码的复用。哈，最后的数据区正是为此独立出来的。
在界面元素相对单一，并且在不考虑升情况下，YY是很不错的选择，对程序员来说，愉悦身心。但反之，最好三思而后行。最后需要记下的是，界面永远是数据的奴仆。我认为，分析架构一个项目，数据先行！
本文完 2012-09-14