如何设计可在不同应用程序框架中使用的数据模型？

Question

我有一个基于MVVM设计和数据绑定的WPF GUI应用程序。现在，我想在Windows服务，控制台UI应用程序或WinForms应用程序中重用核心代码（即数据模型）。

这样的设计合理吗？如果是，那有什么陷阱？ 或者我应该创建一个独立的数据模型，并通过包装器接口WPF？

更新

对不起，我应该更精确。让我澄清一下：我不怀疑模块性问题=）我的担忧归结为让我当前的DataModel实现INotifyPropertyChanged，使用DispatcherTimers等等 - 所有非GUI但仍然是WPF的东西。模型的业务逻辑基于它。

这个（非GUI WPF）设计是否可以在上述情况下重复使用，或者我应该进一步抽象，直到根本不需要引用WPF？

Answer 1

是的，这是完全可以接受的，大部分时间都是可取的！

构建MVVM应用程序时，它应至少包含3个正式层：

• 演示文稿 WPF，UI，xaml，行为。所有这些东西。 不可重复使用
• 应用程序支持应用程序规则的视图模型和结构。所有这些东西。 不打算重复使用
• 基础数据库访问，业务对象。领域特定的算法。 理想情况下，这个位应该可以在任何地方重复使用

基础层是聪明位。这是你的应用三明治中的肉。对于完全不了解UI技术而言，这是非常有意义的。 WPF，winforms，ASP。它甚至不需要UI。

编辑问题更新：

删除对WPF的所有引用很难，因为有时您需要在视图模型上使用CollectionViewSource来对结果进行分组/过滤。这是一个WPF类。

将你所关注的分离视为“只是不引用wpf”是非常诱人的，这有助于但它可以使生活变得困难。相反，请尝试遵守您所投入的行为类型。如果您发现自己在视图模型上编写“聪明”（域）代码，请将其作为业务对象方法或扩展转移到基础层。同样，如果您发现自己经常实施IValueConverter，也许您应该更好地使用视图模型。

有一件事是肯定的，你的基础层永远不应该引用WPF。

Answer 2

这样的设计很合理！您可以为所有.NET技术创建可移植的C＃库，包括WPF，WinRT，ASP MVC等，它们可以包含您的模型。显然，无论如何你都需要将这些可移植模型包装到一个视图模型中，但IPropertyChanged是以所有XAML风格实现的。