原文出处：http://www.cnblogs.com/zhouyinhui/archive/2008/01/17/1042740.html

1，旧的模式已经不再适用

首先看看如果我们将旧的（.net3.o之前）模式直接引入到WPF中将是如何工作的。无论采用什么样的沟通方式，我们需要Developer和UI Designer之间对软件的功能达成共识，然后我们可以得到当前界面的大体Layout，OK，这个被验证和确定以后，UI Designer会细化他的工作，提出一些她的一些新观念，软件UI风格，然后细化出一张张的效果图（利用PhotoShop，PowerPoint等等)。接下来，Developer所要做的事情是："照葫芦画瓢"，照着UI Designer的效果图，再Blend中将其模拟出来，以便形成可供程序使用的XAML。我们可以将这个过程称之为Translate（将效果图（PNG，Jpg）翻译成XAML）。

这所带来的问题：

(1)UI Designer的大部分"产出"的丢失，我们知道UI Designer除了告诉我们UI应该是怎样来展现以外，其设计过程中的大部分作品被抛弃掉了（比如设计了很长时间才做得很漂亮得一个按钮图片），这是由于其产出不能直接用到我们的Project中（我们要得是XAML而不是PNG,Jpg）。到最后UI Designer那边好像仅仅给我们提供了很多idea，而没有实质性的东西输出给我们以便用于我们的的Project.

(2)Developer这边"费力不讨好"。所谓"费力"指的是就大多数Developer而言本身就不擅长绘图（即便您有Blend这类傻瓜式的工具），所以你很难得再Blend中将美工那边提供的图形完全模拟出来，所以，Designer那边有意见了，您将人家美丽的艺术品转化得一团糟糕了。即便某某很牛，模拟出来了。仍然"不讨好"，因为这是重复劳动，Developer再Blend中做得这部分工作事实上美工再Photoshop（或其它）中已经做过一次了。

一个可能得疑问是：为什么不让UI Designer们再Expression Blend或Expression Design中工作呢？先说在Expression Blend中工作，除了培训成本（我想这个培训成本应该是相当高的）以外，就大多数UI Design团队而言面临的最严重的问题是：他们没有软件开发的观念和知识，无法将他们融和到开发流程中来，如果他们负责Blend这块的话，他们的一举一动将直接影响软件的性能和功能。比如他们不会按照Developer的观念来合理组织资源，他们不会考虑XAML代码对性能的影响，没有模块话的观念，不会顾忌软件的可维护性，稳定性。他们只会关心"这样的界面简直太漂亮太好用啦"。那么结果可想而知。再说Expression Design，事实上这是可行的，如果老板愿意出这部分培训费用和培训时间以及UI Designer乐于使用新工具的话。

2，新的模式有那些？

新的模式有好几种，这取决于团队中成员的技能和职责，但我比较推荐的有两种。

(1)集成模式

从WPF角度看，团队中除了UI Designer和Developer以外，我们再引入一个新的角色Integrator。首先看看他们各自的职责：UI Designer的职责保持不变，但我们稍稍改变一下她的"输出"，其除了输出各种idea，布局图，效果图等等之外，其还将为我们输出其它所有的图形（比如一个漂亮的按钮），但是以XAML的形式（这会用到一些插件或小工具，你可以在这里找到http://www.cnblogs.com/zhouyinhui/archive/2007/12/08/987928.html）。请注意，其输出的是一些松散的XAML零部件，仅仅描述了图形，没有Style，Template，Trigger，Resource等概念。这样UI Designer既不会改变惯有的工作方式，又可以专注与图形和用户体验。而Developer的职责也保持不变，其专注于后台逻辑，但放弃对界面的所有权，其是C＃（或其它）的拥有者。而Integrator将致力于他们两者之间的结合，其负责将从UI Designer那里得到的松散的XAML按照软件开发者的观念在Blend中组合成真正的项目中的零部件，比如其将负责Template，Style，Animation以及界面的模块化，资源的组织，考虑其可维护性，稳定性，对性能的影响等等，其是XAML与Blend的拥有者。

这有一些明显的好处：

(i) 没让成员做不擅长的事。在旧模式中，让Developer在Blend中绘制出艺术品或者让UI Designer按照开发者的观念来管理Blend端显然是强人所难，并且这也会分散他们的精力甚至带来抱怨。但目前的模式将这些负担转移出去了。

(ii) 避免了重复劳动。旧模式中，Developer来"翻译"UI Designer的成果的劳动是重复和痛苦的。而当前模式中图形的XAML直接来自于UI Designer。我们需要做的仅仅是整合。

(iii) 避免了实际"翻译"出来的UI与设计时的UI的不一致。两者差距有多大完全取决于Developer的"翻译"能力，但往往效果时不理想的，以至于UI Designer觉得自己的艺术品被扭曲了。

(iv) 有人专注于Blend端，那么软件的表现层端质量将更高，更容易维护。

(2)收割模式

从WPF角度来看，这个模式中只有两个角色: UI Designer与Developer。这个模式对UI Designer的要求较高，其需要能熟练使用Blend来创造一些成品供Developer"收割"。比如我们需要一个漂亮的按钮，那么UI Desinger直接输出给我们该按钮的Style。其甚至可以输出其它更复杂的东西，比如UserControl（不可能是CustomControl，因为他们不会写程序逻辑，除非和Developer合作）。他们的工作是在解决方案中的某个辅助项目中完成了，而负责软件的真正表现的Blend端由Developer来负责，因为这里需要考虑很多软件开发的东西。

该模式同样拥有集成模式的各种好处并且与集成模式相比，UI Designer更加融入到了项目开发过程中，但对UI Designer的要求较高。

其它一些建议：合理地整合Blend端，如果发现XAML文件过大就模块化。保持UI项目始终能用Blend打开，否则将导致团队中某些角色出局或工作起来很麻烦。别让界面和逻辑耦合在一起，如果发现逻辑对界面元素引用过多，那么可能在Binding，Trigger，Resource等方面做得不够好。另外，相比之下，我更推荐第一种模式，我在这种模式下工作了不短时间，Integrator是我的职责之一。