我最近一直在使用 Silverlight 和 Ria 服务编写基于 Web 的应用程序。我已经意识到将 Expression Blend Sketchflow 的使用纳入我的开发周期的能力，作为一种在使用敏捷方法时生成快速原型向客户展示的方式。我发现很难使用sketchflow，因为它背后的想法似乎根本不符合编写silverlight 应用程序的想法。本质上我想说的是，为了让我在sketchflow中为客户制作一个快速原型，我需要做一些编程来实际展示潜在应用程序的真实功能——但不是草图流的全部要点是跳过编程阶段并“设计”应用程序以提供给客户......我'
场景：数据驱动的应用程序需要一些数据网格来显示关系数据。如果我直接对它进行编程，那很好，花花公子，而且不需要很长时间。但是，如果我使用sketchflow，我将无法显示相同数量的功能（无需进行一些编码）-赶上我的漂移！！？
欢迎提出意见和意见/建议......
We use SketchFlow and have had a great response from management. Two things that come to mind are that SketchFlow is obviously better than a Word document since the customers can see an application in action. From the other side of things you make the point that it does require some programming, and that's true. The reason it's better than doing a prototype in Silverlight (and this might sound strange) is that the prototype comes out squiggly and comic looking. It looks nothing like a real application. Far too often in my experience management has seen a working prototype and somehow got the opinion that "the code is already 50% done, i've seen it!" As a dev you may know that prototype code is garbage and should be thrown away but management doesn't know that. I can think of a number of production applications I've worked on that are still running prototype code because management saw it and decided to rush the project along, SketchFlow helps to alleviate that while giving you the expressive power of a running application.
您不能将 Sketchflow 中的原型视为“应用程序”。将其视为通过简单导航连接的一系列故事板。如果您发现自己在 sketchflow 中编写代码隐藏，那么您可能正在努力使其像应用程序一样工作。
您必须将草图流视为一个简单状态机的表示，其中每个屏幕都是一个状态。我认为程序员的诱惑是潜入“如何”而不是说“什么”。每个屏幕都代表要做什么以及它应该看起来如何，但它不应该描述如何完成的设计/架构。如果您需要替换屏幕上的一组控件并用不同的控件替换它们，请不要对其进行编程，制作一个新屏幕！
例如，我想创建一个草图流原型，它的菜单系统类似于 Zune 软件中的主菜单（菜单中的菜单）。我花了一天的时间旋转我的轮子，试图用状态和动画对组件屏幕进行编程，以显示或隐藏子菜单。第二天，我想到为主菜单中的每个项目创建一个单独的组件屏幕，现在我有 3 个组件屏幕，除了简单的导航之外不包含任何编程。
就关系数据而言，我认为在模型中应该有合理数量的“挥手”。要求草图流模型具有显示“真实”数据的严格数据网格，感觉就像您在与您的听众交谈，好像他们没有足够的想象力来理解意图。但那是我的2美分...