我应该让业务对象与WPF中的用户界面分开吗？

Question

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

Answer 1

微软产品团队的指导（例如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

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

当然，没有任何事情会阻止你，但是如果它是分开的，它应该有更多的可测试性（即单元测试）。 MVP模式，通常是MS推广的模式，更多地围绕主持人（即您的WPF表单），具有更多的控制权，而且这也很好......

Answer 3

我想我看到它在不同的光。我尝试尽可能地避免使用UI，因此我可以使用任何需要的UI呈现（即web，WPF，WinForms）。表示层中的业务逻辑越多，如果您迁移到不同的用户界面，则以后可能需要重写的内容越多。

Answer 4

只要你正在做的事情是查看他们这不是在UI中的业务对象的问题。换句话说，如果你想改变一个属性，或者删除一个属性，或者创建一个新属性，你应该发送一条消息给控制器，主持人或者其他任何要做的事情;然后应该在视图中更新结果。

什么你不应该做的是使用你的对象（或你的对象的任何其他方法或属性）的ToString方法来影响他们会如何出现在视图中。您应该使用DataTemplate s来表示您的对象的视图。如果您需要更复杂的表示形式，则可以使用IValueConverter将对象更改为其可视表示形式。

Answer 5

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

这里是我的经验样本：

我曾与WPF只是一点点工作，在 一个相对较小的项目，其中已经定义了 业务层， ，我们只需要创建一个用户界面。当然，接口 已定义它自己的规则和对象 ，它正在与工作，而且由于 应用大部分是通过扩展 DependencyObject（主要用于定义只是我们选择创建自己的 特定对象， UX Data Binding目的）。

有些人可能会说，这是不正常 使用依赖对象，因为它们 不是可序列化（实际上他们 是 - 对XAML），他们带来了 依赖于WPF（在 System.Windows命名空间），以及一些 其他论点。此外， DependencyObjects支持其他 选项，如attached properties 和dependency properties。其他 可能喜欢使用例如 INotifyPropertyChanged如果它 是有意义的，而其他人可能会说 所有这些模式不属于 其他层比UI。 （如果您想了解更多有 一些很好的WPF data binding articles在MSDN库， 包括 性能比较和用户界面的最佳实践）

这是一种糟糕的是微软选择添加一些的例如System.Windows命名空间的好处，而不是像System.ComponentModel那样，在我看来它们可能更有用（通过提供所有这些重要模式不仅适用于WPF，还适用于.NET框架）。

当然这只是一个开始，我们中的许多人都知道，事情将最终演变到正确的方向。 （具有脱离主题的风险：以Silverlight 2.0框架为例，这是一个匆忙释放，WPF模型中的一些对象丢失，有些不在其自然位置。）

在最终，一切都取决于你，你的编程风格，你的架构决定和你对这项技术的了解。

如果用某种方式做这件事比看书更自然，那么在做出任何决定之前，请考虑why you should和why should you not！