设计模式下表达式 Blend 中的样本数据以及运行应用程序时的实时数据
我有一项服务返回可观察的人员集合，该集合将用于在我的 Silverlight 应用程序的列表框中显示人员姓名。
在设计列表框时，设计者使用了示例数据。但是，当 xaml 到达处理视图模型和返回要显示的可观察人员集合的服务的开发人员时，需要进行一些更改。例如删除与示例数据的所有绑定，插入可观察的收藏者属性。
所以我的问题是：-
- 有没有一种方法可以在设计模式下显示示例数据并在运行时显示服务数据？
- 有没有办法让它在设计模式下返回服务数据？
- 使用 Expression Blend 的设计者是否需要知道可观察集合 {persons} 的哪些属性将绑定到列表框？
我想以 MVVM 友好的方式执行此操作{不使用 MVVM Light 工具包}。
感谢您抽出时间...
I have a service that returns an observable collection of persons that will be used to display the person name in a list box in my Silverlight application.
While designing the list box, the designer used sample data. However, when the xaml reaches the developer working on the view model and the service that returns an observable collection of persons to be displayed, there are some changes that need to be done.. like remove all bindings to the sample data, plug in the observable collection persons properties.
So my questions are:-
- Is there a way to do this in a way where in design mode it shows the sample data and when it runs it shows the service data?
- Is there a way for it to return service data while in design mode itself?
- Does the designer using Expression Blend need to know what properties of the observable collection {persons} will be bound to the list box?
I would want to do this in an MVVM friendly manner {without using MVVM Light toolkit}.
Thanks for your time...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有很多很好的例子：
http://blogs.msdn.com/b/avip/archive/2010/12/06/the-simplest-way-to-do-design- time-viewmodels-with-mvvm-and-blend.aspx
http://karlshifflett.wordpress.com/2009/10/28/ddesigninstance-ddesigndata-in-visual-studio-2010-beta2/
非常简单。如果您需要的话，Google 上有很多其他资源
根据评论进行编辑
2。有没有办法让它在设计模式下返回服务数据？
可能有，但我还没有看到。在我看来，出于多种原因，您可能不想这样做。
出现这可能会变得相当
如果你需要赚很多钱会令人沮丧
的小变化。
可用这将使你
如果他们曾经这样做过，那就更没有生产力了
下去。
控制改变现状
临时显示。在
最少使用样本数据系统
您可以更改值来测试
不同场景无需
更改服务数据。
3.使用 Expression Blend 的设计人员是否需要知道可观察集合 {persons} 的哪些属性将绑定到列表框？
设计人员/开发人员工作流程是一个棘手的工作流程。显然，每个项目都会有所不同，但在刚刚完成一个设计繁重的 wpf 项目后，我可以告诉您，我们的设计师希望尽可能少地使用 Blend。
对我们有用的工作流程是让开发人员（我们有一个在视图/视图模型级别工作的前端团队和构建模型和服务层的后端团队）尽可能地构建视图。这意味着构建布局、组合控件、添加大部分设计并连接绑定。然后，我们请了一位具有使用 Blend 经验的设计师（数量不多）深入研究并调整设计，使其完全符合他们的要求。
这样，它们与工作的主要部分几乎没有什么关系，我们可以保持干净和有组织的视图（很少有设计师有经验这样做）。设计人员实际上不必了解有关领域对象的任何信息。一旦我们弄清楚了它是如何运作的，一切都进展顺利。在我看来，让设计师自己构建视图将是一场噩梦……而且他们也不会喜欢这样的事情。
Loads of good examples out there:
http://blogs.msdn.com/b/avip/archive/2010/12/06/the-simplest-way-to-do-design-time-viewmodels-with-mvvm-and-blend.aspx
http://karlshifflett.wordpress.com/2009/10/28/ddesigninstance-ddesigndata-in-visual-studio-2010-beta2/
It's very simple. Lots of other resources on google if you need them
Edit based on comment
2. Is there a way for it to return service data while in design mode itself?
Possibly but I've not seen it. In my mind you probably wouldn't want to do this for many reasons.
shows up which could get quite
frustrating if you need to make a lot
of small changes.
available which is going to make you
even more unproductive if they ever
go down.
control over changing what is
displayed on an ad-hoc basis. At
least using the sample data system
you can change values to test
different scenarios without having to
get services data changed.
3. Does the designer using Expression Blend need to know what properties of the observable collection {persons} will be bound to the list box?
The designer/developer workflow is a tricky one. Obviously each project will be different, but having just finished a design heavy wpf project I can tell you that our designers want as little to do with Blend as possible.
The workflow that has worked for us, is for the developers (we have a front end team that work at the view/viewmodel level and backend team that build up the model and service layer) to build up the views as best they can. That means building the layout, composing the controls, adding most of the design and hooking up the bindings. We then had a designer who had experience in using Blend (there aren't many) delve in and tweak the designs to get them exactly as they wanted.
This way they had very little to do with the main brunt of the work and we could keep clean and organised views (something few designers would have the experience to do). The designers didn't really have to know anything about domain objects. It all worked very well once we'd worked out how it was going to work. Having the designers build up the views themselves would have been a nightmare in my opinion... and not something they'd have enjoyed either.