.NET控件Designer架构设计
总体结构
Designer总体上由三大部分组成:View,ViewModel和Model,这个结构借鉴了流行的MVVM模式。这三部分的职责分工是：
View
负责把ViewModel以图形的方式展现出来，它主要在处理画法。View适合用xaml来表达，对于某些复杂的layout，仍然会需要写一些code,但这些code不涉及业务逻辑。和MVVM的区别是，我们只是在简单输入的情况下，采用了Behavior模式，对于复杂的输入，由于判断用户的意图需要参考许多其它信息，可能要用到很多Service,或者查阅很多的状态信息，这些代码写在View端不合适，我们就直接把事件发给了ViewModel,由ViewModel去处理。View和平台相关，不同平台（WPF、SL,WP7）的xaml可能不同，代码也不同。
ViewModel
主要负责逻辑的处理，接收Event和Command，判断用户意图，改变数据，并反馈给View。ViewModel既有数据，又能响应事件，而且是一棵树，所以它本质上就是一个view,只不过是一个抽象的View,它把琐碎的画法丢给了真正的View,只关心那些和逻辑有关的数据。ViewModel和View有一定的对应关系，但它的结点比View要少得多，因此比直接在View上进行逻辑处理要简单得多。由于ViewModel的数据和操作都是针对抽象的概念进行的，因此它和平台无关。为了方便对ViewModel中的逻辑操作进行管理，我们引入了Service和Feature的概念，Service是向其它模块提供支持的内部模块，是系统的基础，所有的Service构成了系统的骨架。Feature是实现系统外部功能的模块，Feature之间没有依赖关系，它们只依赖于Service。系统中的Service不多，而且只关注最重要的逻辑，代码量不大，所以Service都是经过精心设计和良好的测试，具有很强的稳定性。feature是系统的皮肉，它直接暴露给用户，关注很多细节，代码量大，容易变化，由于feature和feature之间没有依赖性，所以这种变化不会对其它模块造成影响，利于渐进式的开发。
Model
是数据，按照业界大师的说法，Model是纯粹的数据。但我很怀疑这个说法，如果Model是纯粹的数据，那它就没有存在的必要，因为ViewModel上也有数据，何必要把数据存两份呢，同步起来还挺麻烦。我的理解是，Model上是有逻辑的，只是这些逻辑是属于另一个领域的范围了。比如Designer的Model,就是Runtime的control,这些Control是有逻辑的，但它们的逻辑已经和Designtime没有任何关系。ViewModel和Model的关系是，ViewModel操纵Model,但同时要监测Model的变化，和Model同步。如果我们清楚除了ViewModel外，不会有其它的模块去修改Model(这种情况对于一些简单的Designer是正常的)，那么ViewModel和Model的关系可以更简单一些，只有ViewModel改变Model,上图中ViewModel和Model之间的箭头就只需要保留左边那一个（图中的箭头表示数据传递）。
从上面的介绍，我们可以看出，View和Model在DesignTime下都是比较简单的，复杂度主要在ViewModel,我们需要进一步对它阐述。
ViewModel层的结构
我们前面提到，Designer主体结构分成三大部分：View,ViewModel,Model,这里的概念是一个宏观概念，代表它所在的那一层里的所有结构。我们现在讨论ViewModel这一层，它里面除了一个ViewModel树，还有一些Service和许多的Feature。我们知道，图形软件的功能，不外乎就是处理用户的鼠标键盘输入，然后改变数据，最后以可视化的方式反馈给用户，因此，我们只要分析清楚我们的软件是如何来应对这样一个输入输出过程就可以了。
我们看上图，红色虚线内的结构都是在处理输入，红色虚线外的部分在处理输出（展现），可见对于Designer,输入非常复杂，输出比较简单。我们先分析简单的输出：ViewModel时刻监视着Model的变化，一旦发现Model发生了变化，就改变自己的Property以同步，注意这里的Model不一定实现了INotifyPropertyChanged接口，因此这种同步可能不能借用绑定。但ViewModel一定是DependencyObject,或者实现了INotifyPropertyChanged接口，所以当ViewModel的属性变化后，View通过绑定会让展现和数据保持一致，输出过程就完成了。
对于输入，我们需要针对不同的情况进行考虑，基本上，我们可以把输入分成两大类：简单输入和复杂输入。
什么是简单输入？
就是整个输入处理过程很简单，牵涉的模块很少，Command有明确的接受对象。常见的Adorner上的行为，大部分都是如此。举一个具体的例子，有一个Button,当它被选中的时候，会出现一个Adorner,上面有一个Slider,调整这个Slider,Button的透明度会随着变化。要处理这个Slider对Model的改变，最简单的做法就是把Slider双向绑定到对应的Adorner ViewModel的某个属性，即使不能用双向绑定，也可以通过Behavior模式调用对应ViewModel的Command。整个过程只涉及到一个Adorner View,一个Adorner ViewModel和一个Button Control,和系统的其它部分没有什么关系，这类输入行为用双向绑定或者Behavior模式处理最合适。
什么是复杂输入呢？
就是整个输入处理过程涉及到的模块比较多，受很多系统状态的影响，输入没有明确的接收对象，充满了变化。这类行为在Designer中也很多。举一个Multirow Template Designer的例子，一个CellView上收到一个MouseLeftButtonDown事件，View应该怎么处理呢？它会调用ViewModel的什么Command呢？CellView需要先判断用户的意图，但这个判断比较有难度。用户有可能是想选中这个Cell,如果是这样需要执行Selection Command,但是如果这个时候Designer处于Tab Order模式，那就不允许选择，可能是用户想改变Tab order的值。也有可能是用户刚才选择了一个ToolboxItem,现在是想创建一个Cell，还有可能是用户想移动Cell，要进行这些判断，必须要借助其它Service和查询系统中某些状态，如果判断出来是选择，还得检查这个时候的键盘状态，检查目前是否支持扩展选择，在扩展选择模式下，按Control键和Shift键的行为不一样。我们还得检查当前Cell是否已经被选中，如果已经被选中，就需要反选，这需要我们查询Selection Service。如果我们发现Cell是可以移动的，那么MouseLeftButtonDown的处理又得注意了，如果Cell没有被选择，要先选中Cell,如果Cell已经被选中了，不能立即反选，要看用户是否后续有移动的操作，反选必须放到MouseLeftButtonUp中进行。还要考虑到，今后可能需要增加新的Feature,比如增加一个移动画布的功能，用户先在Toolbar上单击了一个手型Icon的Command,然后再在CellView上单击了一下，这个时候以前的判断都无效，因为用户现在是要移动整个画布，那么我们很可能得去修改以前的CellView的Code。总之，View在处理某些事件的时候，需要知道的东西太多，只靠ViewModel提供的Property远远不够，ViewModel层必须把整个结构（所有的Service和各种状态）完全暴露给View层，这样显然不符合我们模块划分的思路。因此，对于这类复杂输入，我们让View什么都不处理，而是把事件转发给ViewModel层去处理。
除了某些事件处理很复杂，某些Command的处理也比较麻烦，比如菜单上的cut,copy,paste,delete等，这些Command没有明确的接收对象，最终由谁来处理需要根据系统当时的各种状态决定。为了解决这类Command,我们必须设计一个Command的路由机制，让那些关心这个Command的feature能够按照一定的优先级来处理这个Command.
为了处理上述的复杂输入，我们学习wpf designer,设计了一个比较复杂的机制。我们设计了一个叫Tool的类,它有一个Task集合，按照一定的优先级把Command交给每个Task处理。Task从哪儿来呢？Task属于Feature，当一个Feature认为它需要监听某些Command时，它会把自己的Task添加到Tool的Tasks中。事实上Task并没有直接处理Command，Task内部有一个CommandBinding集合,它负责处理Command。Task的Commandbinding在执行代码时，修改ViewModel的属性，或者执行一个ViewModel的Command。
对于View层转发给ViewModel层的Event,在处理中会被先翻译成Command,然后按照前面的Command流程处理。在这个过程中，需要经历下面两个步骤：
第一步
View接到鼠标键盘事件后，会调用InputService的一个函数PerformInput，把事件转发给InputService。InputService会对这个事件进行预处理，然后再转发出去。预处理解决两个问题：1.把针对View的事件，转换成针对ViewModel的事件。因为ViewModel就是一个抽象的View,如果把事件转换成了针对ViewModel的事件（就是把事件的参数Sender转换成对应的ViewModel,EventArgs转变成适合于ViewModel的EventArgs）,我们就可以按照以前熟悉的windows事件处理思路来处理ViewModel的事件，把View彻底屏蔽掉。2.添加或改变一些事件，以方便后续的处理。Designer有一些频率特别高的操作，比如Drag,系统的默认事件比较弱，或者没有对应的事件，如果我们在这儿进行一些强化，后面的处理就会减少很多麻烦。
第二步
InputService对事件进行完预处理后，会把事件交给Tool。Tool不但可以对Command派发，还能对Event进行派发，因为Task中除了有CommandBinding,还有InputBinding,InputBinding用于处理事件。事件被处理完后，会生成一个Command,这个过程就是把事件翻译成Command的过程。翻译成的Command,会发给Tool处理，绕这个圈是为了和前面的Command处理流程保持一致。
在和大家的讨论中，觉得输入处理的流程太复杂，尤其是我开始的时候，为了减少ViewModel层的信息入口，不建议View去直接改变ViewModel，所有事件都转发给ViewModel层来处理。大家发现，如果那样做，即使做一个很简单的输入，都要绕很大一个圈子，非常麻烦。因此，对于简单的输入处理，我们认为应该用双向绑定或者Behavior模式，直接修改ViewModel，只对于那种比较复杂的输入，才把事件转发给ViewModel。这样一来，这个图变得似乎更复杂了,但我经过仔细考虑，觉得不能删减，因为Designer有些输入处理的流程确实非常复杂，过于简单的结构会导致后面写feature的时候需要考虑更多的问题。
另外说一下Tool,大家不大适应这个结构。因为按照我们以前的思路，即使事件交给ViewModel层处理，经过预处理后，InputService也应该直接把事件派发给对应的ViewModel,即使要路由，也可以学Wpf的路由机制，那样大家都比较熟悉。但我认为，那样的设计会让大量的逻辑写到ViewModel中，和ViewModel绑得比较死，这样会有两个大的缺点：
复杂输入处理
逻辑往往跨越多个ViewModel，本来是一个完整的逻辑，不得不分片写在不同的ViewModel中，依靠全局变量或者Service来协调。比如我们在Winform Designer中，就设计了一个DragService，用得非常频繁，原因就是在Drag中，不同的View需要协作来完成一些任务，它们只能通过DragService来协调。但现在这种机制下，就不需要DragService了。
对原有的行为进行修改很困难
一个典型场景就是，在某种状态下，需要禁止掉某些原有的行为。在Winform Designer下，我们只能有两种处理方式:一，修改原来的Code,增加判断条件，这种方式很容易搞出来新的Bug。二，在原来的View上盖上一个透明的View，把事件劫持掉，这种方式属于比较变态的方式，系统中如果用多了，会让后面的人很难理解原有的设计。微软的Winform Designer在处于这种情况时有一个经典的变态处理，它需要放一个Runtime的Control在Designer上，但不想让它的行为在Designer中起作用，或者在某些情况下有选择的让它起作用，它用了hook技术，劫持windows消息，如果有需要，可以选择性的放过去一些消息。Visual Studio中这类东西用得比较多，导致即使你按正常的方式放一个Control在Visual sdudio中，它有时工作也不正常，因为它的某些消息被hook劫持掉了。wpf中提供了Preview message,在某些情况下能够简化这类问题的处理，但我相信它的灵活性还是远远不如Tool这种把消息集中起来处理的方式，因为这种机制把逻辑彻底从ViewModel中剥离出来了，谈不上需要改变哪一个ViewModel的行为，因为ViewModel没有控制行为的代码，所有行为都属于外面的Feature,只要Feature发生变化，对应的ViewModel的“行为”自然就发生变化。
当然，Tool这种把所有消息集中处理的方式也有缺点，就是模块间的干扰非常严重，就相当于编程语言中的全局变量，方便了使用，但带来了干扰。因此我们推荐复杂的输入用这种方式，简单的输入用Behavior模式，直接修改ViewModel，或者通过DelegateCommand,把View的事件直接转发给ViewModel处理,绕过这个机制。但是，我们一定要意识到，绕过这个机制会带来的问题，就是后面要改变原有的行为是不行的，因为消息的传输过程中没有留下改变的控制点，只能去修改原有的View和ViewModel的代码。在designer中，这类简单输入方式主要应该用于Adorner,因为Adorner一般都是临时使用一下，输入简单，即使后面发现需要改变它的行为，不得已可以换一个AdornerModel和AdornerView,也不会对系统造成多大影响。但如果你要把Multirow Template designer中SectionViewModel和SectionView，或者CellViewModel和CellView换了，那影响就大了去了。所以我们今后在选择哪种输入处理方式时，一定要充分考虑到后面变化的需要。
View和ViewModel的对应关系
讨论中大家觉得View和ViewModel的对应关系比较复杂，所以这儿单独花一节来谈谈它们的关系。举一个大家熟悉的MultiRow的例子，现在假设有一个SectionViewModel,它的Chilren中有两个Cell,分别是CellViewModel1和CellViewModel2,现在我们看这个ViewModel Tree如何展现，事件如何传递，HitTest是如何实现的。
先看一下我们会怎样来设计View,为了便于用Xaml表达，我们一般会用UserControl来表达View,虽然CustomControl也能用Xaml,但它的xaml一般要写到Resource中，所以我们一般不用。我们现在有两个类：SectionViewModel和CellViewModel,因此，对应的我们会设计两个UserControl,分别叫做SectionView和CellView。这儿我要说明的是，由于CellView很简单，做产品的时候也许不会单独为它用一个UserControl,而是在Section的Xaml里直接表达了，甚至MultiRow的整个Template都用一个UserControl描述。在这里为了方便阐述概念，我们把两个View看成是两个独立的UserControl。
怎样来设计SectionView呢？我们会在UserControl中放一个ItemsControl,把它的ItemsSource邦定到datacontext的Chilren属性上，然后把ItemsPanel设置成Canvas,在ItemTemplate中指定用CellView来展现CellViewModel,当然，我们也可以用隐式DataTemplate来表达。
CellView呢？我们就在UserControl中放一个Border,把Border的Background绑定到DataContext的Background就可以了。
当外部某个对象把SectionView加载到VisualTree上时，它会负责把SectionView的DataContext指向SectionViewModel(这个对象很可能也是一个DataTemplate),通过绑定，所有的CellViewModel都会有对应的CellView,最后的VisualTree会如图中所示。
我们看到，VisualTree的Visual结点明显多于ViewModel的结点，那么它们的对应关系是如何的呢？有两条原则：