我应该将业务对象与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 Binding目的）。

     

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

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

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

  

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

     

如果以某种方式执行此操作似乎比书本更自然，请在做出任何决定之前考虑why you should和why should you not！