这个是我们的组织结构维护视图，本来是一个很简单的树控件，但就Domain而言，一个人只有看到长相如此的东西，才会理解它是一个组织结构图（尽管M就是树）
但是，V里边的代码，不过如此：
真正的代码，被放到M里边了。
如果从这个案例分析，就会看到至少三个人都参与了：
１. 产品经理，他要求不要搞一个树控件，要做一个和平时纸上印刷的一样的组织结构图
２. UI设计，开始设想了一个方案
３. 但最后实现它的，是程序员。
这也是我为什么最后兼任产品经理、UI设计、程序员的原因。
如果分开三个人，还能实现，但必须有相同的价值观，不要各干各的。
问： 13:30:54
不要各干各的 指的是什么？
陈勇-咨询-北京(139107533) 13:30:55
其实，我们有一个纯Html版本的组织结构图，后来封装到C#里边了。
各干各的，就是程序员说：“哪，你看这是数据读取接口，你自己画你那个组织结构图去吧”
我们有3个地方用到组织结构图，都是这三行代码搞定。如果各干个的，就需要把大约200行Html重新拷贝三遍。
但由于程序帮助封装了ViewModel和View的Helper，一切就这么简单了。
回到问题本身，UI设计怎么敏捷？
陈勇-咨询-北京(139107533) 13:34:03
首先，应该有一个人作为打通跨职能部门的纽带，应该是产品经理。
他综合提出对UI的最终设想，基于的是，用户如何与产品交互，才能最好地完成业务（这个好，不完全是方便、美观这些，而是直接和业务切合）
其次，UI和程序应该是跨职能的，或至少处于一个跨职能团队中，不要分到两个部门或团队里边，这样大家才会集体思考最佳做法（比如前面程序帮助UI封装Html为Helper）。
以我三位一体的体会，很难想象如果有三个思想不统一的人做这件事情，最后结果是什么。
问： 13:37:51
达成共识
陈勇-咨询-北京(139107533) 13:38:48
是的。
要把UI长到客户的心里边，而不是展示在眼前而已。
我们现在还有几个页面不太满意，感觉看到以后，还要思考一下：这是什么……这样的UI，就有问题。
看到后应该是：哇塞居然可以这样！
或者：你看，就是我上次说的那样
有一次在之前的公司去做售前讲解方案，对方老总就一个劲地捅旁边另外一位，指着屏幕窃窃私语。我就知道那个单子成了。
陈勇-咨询-北京(139107533) 13:46:30
总之，用户看不到M，看不到D，看不到C，只能感受到V
另外一位QQ成员： 13:50:47
勇哥，你说的客户感受V，能否说的具体点。是不是说除了用户体验，还要业务体现出来，让客户觉得咦~~这就是我所要的。对吧。
陈勇-咨询-北京(139107533) 13:51:50
是的，V不要只图做得漂亮、方便，要理解用户来这里干什么，他看到这些，是否真的知道自己应该干什么了。
另外一位QQ成员： 13:52:05
明白了，谢谢~~
（问题讨论结束了，下面是关于MVCD中D的来历，一般只说MVC）
陈勇-咨询-北京(139107533) 13:53:38
MVC说法比较多，D是我自己说的，因为我发现D比较独立。
我把数据的读写和缓存都归结为D。
另外一位QQ成员： 13:55:44
由M到D，我理解就是数据持久化到数据库
陈勇-咨询-北京(139107533) 13:56:30
外加应用缓存吧，
比如火星人里边，史诗故事-用户故事-增强-缺陷……这些，有父子关系，表面上看，是属于Model的行为。
但我们发现，部门-团队-小组，产品线-产品-版本-Release……也有父子关系
所以，后来“父子关系”，被从Model的层面，挪到Data的层面
所以，我们的部门/产品/用户故事……（一共7种）东西，是存储在一张数据库表里边的，因为他们被从D的层面抽象过了（注：被抽象成为了“有父子关系的数据）。
但是，这种存储会造成性能恶化，所以，又做了应用缓存，把他们拆开。
从父子关系看，他们是iheritable-item
从数据的差异看，他们是udcable（user-defined-column-able可定义字段的)我们用这两个类来管理他们。
这些都是和M没什么关系的，用D来维护更好。
本文转自火星人陈勇 51CTO博客，原文链接:http://blog.51cto.com/cheny/1102146
