我应该在WPF中将业务对象与UI分开吗?

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

本质上,他们主张创建一个ViewModel层,该层使用绑定友好的业务对象,如ObservableCollection等。

此外,如果您最终可能会迁移到Silverlight 2,您可能希望将业务对象排除在UI层之外,这样您就可以交换UI技术(直到WPF和Silverlight变得兼容源代码)。

我想我是从另一个角度看待它的。我尽量避免使用UI,这样我就可以使用我需要的任何UI演示文稿(即web、WPF、WinForms)。表示层中的业务逻辑越多,如果您迁移到不同的UI,以后可能需要重写的内容就越多。

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

什么你 不应该 做就是使用 ToString 对象的方法(或对象上的任何其他方法或属性)来影响它们在视图中的显示方式。你应该使用 DataTemplate s表示对象的视图。如果你需要一个更复杂的表示,你可以使用 IValueConverter 将对象转换为其视觉表示。

我不是WPF大师,我不能确定,但通常将M、V和C分开的原因是,这样你就可以独立于视图测试控制器,反之亦然。

当然,没有什么能阻止你,但如果它是独立的,它应该更容易测试(即单元测试)。MVP模式通常是微软推广的模式,它更倾向于让演示者(即你的WPF表单)拥有更多的控制权,这也很好。...

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

以下是我的经验示例:

我只使用过WPF一点点 一个相对较小的项目,其中 业务层已经定义, 我们只需要创建一个用户 界面。当然,界面 已经定义了自己的规则和对象 它正在与之合作,因为 该应用程序仅为 我们选择创建自己的用户体验 特定对象,主要是通过扩展 DependencyObject (主要用于 Data Binding 目的)。

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

微软选择为微软增添一些好处,这有点糟糕 系统。窗户 命名空间,而不是例如 System.ComponentModel 在我看来,它们可能更有用(通过不仅为WPF而且为.NET Framework提供所有这些重要模式)。

当然,这只是开始,我们中的许多人都知道,事情最终会朝着正确的方向发展。(有偏离主题的风险:以silverlight 2.0框架为例。这是一个仓促的发布,WPF模型中的一些对象缺失,一些对象不在其自然位置。)

最后,一切都取决于你、你的编程风格、你的架构决策和你对技术的了解。

如果以某种方式做这件事似乎比照本宣科更自然,那就想想 why you should 和 why should you not 在做出任何决定之前!