2

WPF 的面向视图模型的处理方式使得仅在 UI 中使用业务对象非常诱人。你见过这方面的问题吗？为什么或为什么不这样做？

4

5 回答 5

6

Microsoft 产品团队的指导（例如 Blend 团队正在使用的）是 Model-View-ViewModel 架构，它是流行的 MVC 模式的一种变体。一个好的起点是http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx。WPF 博士也有关于这个主题的好文章。

本质上，他们提倡创建一个 ViewModel 层，该层使用绑定友好的业务对象，例如 ObservableCollection 等。

此外，如果您最终可能会迁移到 Silverlight 2，您可能希望将业务对象保留在 UI 层之外，以便您可以更换 UI 技术（直到 WPF 和 Silverlight 成为源代码兼容）。

于 2008-11-03T17:48:05.293 回答
2

我想我从不同的角度看待它。我尽量远离 UI，这样我就可以使用我需要的任何 UI 演示文稿（即 web、WPF、WinForms）。表示层中的业务逻辑越多，如果您迁移到不同的 UI，您以后可能需要重写的越多。

于 2008-11-03T17:13:17.393 回答
2

在 UI 中拥有业务对象不是问题，只要您所做的只是查看它们。换句话说，如果你想改变一个的属性，或者删除一个，或者创建一个新的，你应该发送一个消息给控制器、演示者，或者其他的东西；然后结果应该在视图中更新。

您不应该做的是使用ToString对象的方法（或对象上的任何其他方法或属性）来影响它们在视图中的显示方式。您应该使用DataTemplates 来表示对象的视图。如果您需要更复杂的表示，可以使用 anIValueConverter将对象更改为其可视表示。

于 2008-11-03T17:47:27.667 回答
1

我不是 WPF 大师，我不能确定，但​​分离 M、V 和 C 的通常原因是，您可以独立于视图测试控制器，反之亦然。

当然，没有什么能阻止你，但如果它是独立的，它应该更易于测试（即单元测试）。MVP 模式，通常是 MS 提倡的模式，更适合拥有更多控制权的演示者（即您的 WPF 表单），这也很好......

于 2008-11-03T17:10:44.387 回答
1

根据您的应用程序体系结构或您计划重用组件和对象的方式，您可以选择与用户界面（在本例中为 WPF）有一定程度的独立性。

以下是我的经验示例：

我在一个相对较小的项目中使用过 WPF，其中已经定义了业务层，我们只需要创建一个用户界面。当然，接口已经定义了它自己的规则和它正在使用的对象，并且因为应用程序是为 UX 定义的，所以我们选择创建我们自己的特定对象，主要是通过扩展 DependencyObject（主要是为了Data Binding目的）。

有些人可能会争辩说，使用依赖对象是不好的，因为它们不是可序列化的（实际上它们对于 XAML 是可序列化的），它们为 WPF（ System.Windows命名空间）带来了依赖关系，以及其他一些参数。此外，还 DependencyObjects支持其他选项，例如附加属性 和依赖属性。例如 INotifyPropertyChanged，如果有意义，其他人可能会喜欢使用，其他人可能会说所有这些模式不属于 UI 之外的其他层。（如果您想了解更多信息，可以在 MSDN 库中找到一些优秀的 WPF数据绑定文章，包括性能和用户界面的最佳实践）

微软选择将一些好东西添加到System.Windows命名空间，而不是例如，System.ComponentModel在我认为它们可能更有用的地方（通过提供所有这些重要的模式，不仅为 WPF，而且为.NET 框架）。

当然，这只是开始，我们中的许多人都知道事情最终会朝着正确的方向发展。（有跑题的风险：以 silverlight 2.0 框架为例。这是一个匆忙发布的版本，WPF 模型中的一些对象丢失了，一些对象不在其自然位置。）

最后，一切都取决于您、您的编程风格、您的架构决策以及您对技术的了解。

如果以某种方式做这件事似乎比书本上的更自然，那么在做出任何决定之前，请三思why you should而后行why should you not！

于 2008-11-03T18:45:30.967 回答