在MVC中重用WPF ViewModels是否可行？

Question

我们有一个用WPF / WCF编写的富客户端应用程序，并打算在ASP.net中创建一个配套网站（如果可能的话，使用MVC）。

我被要求弄清楚我们当前的代码库有多少，我们可以重用（由一个单独的团队） - 而且我对ASP.net几乎没有经验。

我们将重用我们的域模型，但是在分离ViewModel的WPF特定部分并重用MVC中与WPF无关的部分方面有什么意义吗？它甚至遵循相同的范例吗？我们专门使用RelayCommands进行命令，因此很容易将所包含的方法包装在特定于ASP.net的内容中......但是UI特定的东西如何 - 例如ASP.net使用INotifyPropertyChanged - 或者它如何处理UI更新？

Answer 1

对我来说这没有任何意义。您的模型应包含所有重要的业务逻辑代码，并且应该是最具可重用性的点。您的视图模型应仅包含表示逻辑，并且由于这对于桌面和Web应用程序来说是如此不同，因此重用这些模型没有意义。

MVC不会对UI更新使用任何绑定机制，因为Web应用程序本质上是无状态的。实际上，您最有可能最终使用MVC应用程序的视图模型，但在MVC中，这些操作用作简单的数据传输对象（DTO），用于向视图提供数据以呈现每个HTTP请求。呈现视图后，您需要返回服务器以更新视图模型并重新呈现视图。

或者，您当然可以使用脚本更新UI客户端。 Knockout.js是一个很好的JS库，用于客户端视图模型/视图绑定。

Answer 2

我无法直接回答您的具体问题，因为它很大程度上取决于您的应用程序以及您现有的视图模型的编写方式，但您提出的问题很有趣。

一方面，视图模型包含非常少的视图特定代码的逻辑是重用的诱人论据。另一方面，视图模型非常清楚地满足了视图的需求，并期望它满足不同视图的需求可能会有问题。

最后我们可以给出的是指导方针。你当然不希望在整个地方使用ifdef或ifs的单片视图模型。您可以将常用功能重构为基类 - 这是面向对象的方式 - 但如果没有良好的单元测试，它肯定会破坏您已经运行的代码中的某些内容。但是，这样做并不意味着拥有令人反感的剪切和粘贴代码，这些代码几乎是相同的，并且可能会分散而造成维护噩梦。

也许一种实用的方法是假设您需要一个全新的视图模型，但要检查您现有的视图模型，您可以在开始之前将其下载到模型中，从而使视图模型尽可能小可能。然后在某些时候，也许在您获得原型工作之后，您可以尝试合并以查看它是否实用以及出现了什么问题。如果它可以工作，请在继续实施时考虑这些问题，然后根据您的需要规划这两个任务。