是什么让我们的界面层和逻辑层变得复杂

为什么想写这篇blog？

写这篇blog的目的在于发现存在的问题，然后想办法来解决问题。在现实工作中，最让我们头疼的事情是我们觉得我们做的事情很复杂，但是一时也说不清楚到底复杂在什么地方。就算是我们不断的学习设计模式，如果你不知道你的问题所在，那你就无法保证你所选择的设计模式能够帮你有效的解决你的问题。其结果是你的问题没有得到解决，反而变得更加复杂。

所以我希望看了这篇blog的朋友，能够说说你遇到的问题，并且谈谈这个问题出在哪里。谢谢大家的支持。

这些天在做一个模块，在这个模块中包含有一个逻辑比较复杂的窗体，它让我之前的经验都失效了。面对这个窗体，我开始迷茫。就是一个简单的界面层和逻辑层，它们会有这么复杂吗？



的确，如果抛开这个窗体，而专门看在C/S模式，数据应该只有三种版本。数据的显示版本，数据的缓存缓存和数据在数据库中（或是其它外部存储）的版本 。编写这些代码的目的，从某种意义上说，就是保持这三个版本数据之间的一致性。按理说，明白了这一点，C/S模式下的窗体代码设计没有什么复杂的。但是我也不知道问题出在哪里，最后这个窗体做出来的代码看上去很复杂，或许我是在找一种比较体面的设计模式。总之，我觉得这个问题值得我研究一下。

在界面的处理逻辑中，我们要将数据从数据库读出来，将其保存到一个缓存数据中，然后再由缓存，将数据写入到界面表示控件。这是最理想的方式，但是问题往往没有那么简单。



经常的情况是：我们将类型数据读入到一个下拉列表框中，然后选择下拉列表框中的数据，使界面上的其他数据显示产生联动。这让界面数据开始变得复杂起来。其实质是当下拉列表中的数据选择发生变化之后，系统根据下拉列表中被选中的数据A，到数据库（或其它外部存储）中去寻找数据B，然后将B存储到缓存中，再由缓存将数据显示到界面上，得到数据C，就是说A决定C。



当然还有比这个更加头疼的情况，并且这样的情况会有很多。例如下面这个窗体



对于这个窗体的处理，我们一般的做法是，将职员类型数据读入到下拉列表框中，当选择一个职员类型之后会出发选择事件，在这个事件中，读取属于该职员类型的职员数据，并将数据存储在职员列表中。然后点击添加按钮(>>)，将职员数据插入到“被选择职员表”中，并且从“职员表”中删除该职员信息。实际上这也是复杂界面数据处理中的最简单的一种假设，即，在操作界面中，要有一个控件保存临时选择的数据。

那么根据我们最开始提到的数据的三个版本，这里实际上就出现了第四个版本。第一个版本是界面显示数据的版本，第二个版本是该界面显示数据对应的缓存版本，第三个版本是该数据对应于数据库中的版本，而第四个版本是该数据对应于界面上临时保存选择数据的版本。对应于上面的例子，就是“被选中职员表”列表中对应数据的版本。

抛开其它技术细节来说，就是处理这几个版本数据之间的一致性，也是一个很复杂的工作。

但是如果仔细想想，如果只是保持数据版本在物理上的一致性，那还很好说，早在com时代就有了的数据绑定可以很完美的解决这个问题。在上面的例子中，我们除了在维持数据物理上的一致性外，还在维持逻辑上的一致性。物理上的一致性的维护工作体现在保证缓存数据与显示数据之间的一致性；而逻辑上的一致性维护工作体现在保证“职员表”与"被选中职员表"之间的一致性，这是代码中的软肋。这样的细节在系统中的其它地方还有很多，它们的出现让看似简单的界面层与逻辑层变得复杂。

还想补充的是，缓存数据和界面数据之间还存在逻辑上的转换。这样的例子如：当缓存数据中某个值为false时，该数据在界面上的显示为蓝色。

写到这里可以做一个小小的总结：
窗体中数据的版本越多，界面层和逻辑层之间的数据处理就越复杂。

另外一个让界面层和逻辑层变得复杂的因素是数据传递的不确定性。
传递数据的方式，我稍微归纳了一下（但不限于）：
1.值接赋值
2.数据绑定
3.通过事件传递
4.通过代理传递
5.通过虚函数
在很多时候，上面的这几种方式都是有效的，并且可能是同时在工作。

这篇blog限于本人的能力和经验，阐述的内容不够严谨，范围也存在局限性，请各位高手指教。