我应该将业务对象与 WPF 中的 UI 分开吗？

Question

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

Answer 1

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成为源代码兼容）。

Answer 2

我想我从不同的角度看待它。我尝试尽可能多地保留UI，因此我可以使用我需要的任何UI演示文稿（即web，WPF，WinForms）。表示层中的业务逻辑越多，如果您迁移到不同的UI，就可能需要稍后重写。

Answer 3

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

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

Answer 4

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

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

Answer 5

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

以下是我的经历样本：

  

我和WPF一起工作过一段时间   一个相对较小的项目，在哪里   业务层已经定义，   我们只需要创建一个用户   接口。当然，界面   已定义了自己的规则和对象   它正在使用，因为   该应用程序的定义只是为了   用户体验我们选择创建自己的用户体验   特定对象，主要是通过扩展    DependencyObject （主要用于 Data   绑定目的）。

     

有些人可能会说这不好   使用依赖项对象，因为它们   不可序列化（实际上是他们   是 - 到XAML），他们带来了   对WPF的依赖（    System.Windows 名称空间），以及一些   其他论点。也，    DependencyObjects 支持其他   选项，例如附加属性   和依赖属性。其他   可能想用例如    INotifyPropertyChanged   有道理，其他人可能会说   所有这些模式都不属于   除UI之外的其他层。   （如果你想了解更多信息   一些好的WPF 数据绑定   MSDN库中的文章，   包括最佳实践   性能和用户界面）

微软选择将一些好东西添加到 System.Windows 命名空间，而不是例如 System.ComponentModel ，这有点不好在我看来，它们可能更有用（通过将所有这些重要模式提供给WPF而不是.NET Framework）。

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

  

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

     

如果以某种方式比书本更自然地做到这一点，那么在做出任何决定之前，请考虑为什么你应该和为什么你不能！