请教大家一个软件设计中UI分离的问题

bidongliang

之前看过一些设计方面的书，很多都强调UI与数据模型的分离。但在实际工作中却遇到了些想不明白的地方，请大家指教。
具体问题是：

1.  所谓分离是否暗示在数据模型代码中不应该引用任何控件（比如：Button, TextBox等）？
2.  分离应该是逻辑的命名空间分离还是物理的模块分离？
3.  或者我对分离的理解是错的？

另外，如果.NET中有很多类似下面的用法：

1. 
   
2. class Person{
   
3.    
   
4.     [UIEditor(Type="TextBox")]
   
5.     public string Name{ ... }
   
6. 
   
7.     [UIEditor(Type="Calendar")]
   
8.     public DateTime Birthday{ ... }
   
9. }
   

复制代码

具体的代码可能有出入，我要表达的意思是它在模型的定义中标记了如果在界面中展示，这样好吗？

bruceteen

这是C/C++论坛，不是.net论坛

nketc

找 三月二七 问

bidongliang

回复 2# bruceteen


我只是举个例子而已，设计问题和语言没有关系吧。如果大家觉得不舒服我可以写成C++代码。

1. class Person{
   
2. public:
   
3.     Property<string> GetName();
   
4.     Property<time_t> GetBirthday();
   
5. };
   
6. 
   
7. template <typename T>
   
8. class Property{
   
9. public:
   
10.     T GetValue();
    
11.     string UIEditorType();
    
12. };

复制代码

bruceteen

回复 4# bidongliang


    你这属于 数据模型 和 UI 的接口类型，当然两者都会有。
不过，一般而言可以不使用接口，直接在 UI 中获得数据显示数据，但UI不参与数据的计算

hgrany

有D,V两个对象. D代表数据和处理,V代表显示.
所谓分离,就是D不关心V怎么显示,只要显示就好,V也不在乎是什么数据,只要给V满足条件的数据就行.
再往大了说,就是: D可以任何搭配任何可能的V来显示数据,只要V满足某约束(接口). V对D的要求也一样.
对于你的问题
1. 是的. 不应该出现任何控件.
2. 理论上两个都分离.

狗蛋

这是实现，不是设计。

准确点说，这是“绑定数据与界面呈现“的实现代码，和整体设计无关。

bidongliang

回复 6# hgrany

也就是说所谓的分离指的是实现而不是接口，数据和显示二者互相知道对方的接口是没有问题的，是这样吗？

如果是这样，那么另外针对第一个问题，是否可以通过定义IButton, ITextBox接口来做到分离？

狗蛋

bidongliang 发表于 2012-01-30 15:34
回复 6# hgrany

也就是说所谓的分离指的是实现而不是接口，数据和显示二者互相知道对方的接口是没有问题 ...

1、知道接口就等于没分离。

2、数据和界面分离，指的是总体设计上，两者完全无关；至于具体实现，当然还得在某个点重新“粘连”起来——但那就是另一回事了。



举例来说，网络游戏，玩家打怪是一个数据包；服务器告诉玩家怪被打死了是另一个数据包……以此类推。

游戏逻辑完全就在这一个个包的产生、传输和处理上，至于界面显示什么，管它呢。


再如，excel可处理csv文件，我们就把csv当作一个简化版的excel文件讨论。

csv文件是逗号分割的一系列数据，我们可以把这种被逗号分隔开的最小元素叫做一个cell；cell可以有数据类型，可以利用行列来给它们编号——我们可以简单的认为，它其实就是一个二维数组。

然后，我们需要一些算法，从中标记并提取一个/多个区域，然后可以对这些区域进行一些操作——诸如求和、求平均值等等。



很显然，根本不需要实际去玩一个游戏，只靠数据包一样打怪；也根本不需要真的打开一个excel用鼠标指指戳戳，直接用数组访问一样可以玩转excel数据——甚至这些都可以比通过笨拙的图形界面做的更多、更快（传说中的外挂、宏是也）。




有了数据及其上的操作定义之后，再通过某个机制“粘连” UI 和数据，就是最终的软件了。

比如，你可以把csv通过数据库访问接口去和某个程序粘连，然后操作它里面的数据（那张大二维表）；也可以通过excel工具软件操作这个二维表（excel也不过是在内部做了“粘连”其UI到csv格式的工作而已）；或者，wps、libreoffice等等，都可以操纵csv——假设数据库访问接口、excel、wps、libreoffice都是你写的。

很显然，这是一个极其灵活的设计，因为你只需定义/实现/优化二维表上的一些算法——一些矩阵、关系数据库等方面的、很“硬”的理论指导下的、基本的并/交/差之类的算法——就可以提供过去、现在、将来可能的一切功能。
至于如何唤起这些功能、如何让用户很方便的找到和使用这些功能，就是UI组的事情了。

反过来说，如果你一开始就考虑一个excel式的界面，点这里做这个点那里做那个……那么这就不是数据、逻辑与UI分离，就只能等着被不断变更的需求给累死吧。


当然，这里只是个很粗略的大致轮廓，而且用到了某种通用的文档格式。实践中，你可以类似的抽象你的数据和程序逻辑，在任意细节层次实现自己的数据分离与绑定机制。

至于所谓的IButton之类，那只是某个特定“粘连层”的实现机制罢了，而且还只是简单的单个或简单的一组数据元素和界面元素之间的粘连/绑定机制而已。
换句话说，它和业务逻辑之间，连一毛钱关系都没有。

bidongliang

回复 9# 狗蛋


你说的内容是否可以总结为“数据和界面要分离，这样有很多好处。”，这我完全同意，也是我在问题的一开始就表明了的。

我的问题在于你说的“某个特定粘连层的实现”。详细说来是如下几点：

1.  表现在代码上的实现是否应该像设计那样分离。
2.  如果应该分离，那么像.net或java那样可以在模型代码中直接使用标记是否就是不种不好的实现方式。