3层架构中的MVVM WPF应用程序

Question

我目前正在使用MVVM设计模式处理Enterprise WPF LOB桌面应用程序。我在开发机器中的当前解决方案结构如下：

• 主项目 - 包含所有视图（XAML）
的WPF应用程序
• 查看模型 - 包含备份主项目中的视图的所有视图模型
• BLL - 业务逻辑层
• DAL - 数据访问层 - 连接到MS-SQL服务器并调用存储过程
• 模型 - 包含所有业务实体

我目前没有使用WCF，因为除了自己服务器中的数据库之外，此时所有内容都驻留在同一台机器上。但是，将来我们计划将代码库分成3层。

我遇到的问题是，一位同事坚持认为我们应该在3个独立的服务器/机器中将我们的应用程序拆分如下：

1. 演示文稿层 - 用户计算机中的客户端WPF应用程序（查看）。这可能也是一个Web客户端应用程序
2. 逻辑层服务器 - 视图模型+模型+业务逻辑层+数据访问层
3. 数据层服务器 - 数据库服务器

我无法想象视图模型与视图分开（不同的服务器），他声称这应该是可行的。

编辑：我的同事声称，在服务器端使用View模型可以简化任何未来的部署，并使其更易于维护，因为更改只会在服务器端进行。但是，我使用ClickOnce部署了.NET应用程序，这并不是什么大不了的事。

从I have read您可以在包含View和ViewModel的用户计算机上安装WPF客户端应用程序，然后通过像WCF这样的通信层公开较低层的服务。

This answer in another posts states the following:“在MVVM中，UI层分为两层：负责应用逻辑的ViewModel和仅在演示中负责的View。” 基于此，我的基本问题是，View和ViewModel UI层是否可以驻留在不同的层（服务器）中？如果是这样，那是推荐的吗？怎么可以实现呢？

谢谢！

Answer 1

View Model，根据需要调用它，最后是计算机内存中Object的实例。就像任何其他实例化的类一样。其目的是连接View和Model，访问各种BL方法等。

即使将View Model的实例从某个服务器传递到客户端是可行的（假设您在服务器上对其进行二进制序列化并在另一端对其进行反序列化） - 其他创造巨大的开销（无论是在网络上还是在CPU上），我都看不出它会如何让事情变得更容易，相反我想理解如何这会让事情变得更糟糕更易于维护。

View和View Model都应该在客户端。 e.g。

Presentation Tier - The client WPF application (View + View Models)
Logic Tier server - Model + Business Logic Layer + Data Access Layer
Data Tier server - The database server

鉴于这个分离，他是正确的，BL或DAL中的更改不需要创建客户端的新版本（只要你不破坏任何接口，不要'改变模型等。）

Answer 2

让我们从明显的开始：

1. ViewModels不在服务器上。它们的作用是使来自多个服务/模型的数据可用于视图，并提供视图和数据之间的链接。没有人这样做，没有人会认为这是个好主意。如初。
2. 您的数据层可以在您希望生活的任何地方生活，而且干预最少。

在哪里讨论的是，您的业务逻辑层有多少/几乎被提升为WCF层，以及客户端计算机上将保留多少。这就是讨论的内容。

如果您的同事坚持认为视图模型应该在服务器上，请让他/她对其进行原型设计。这应该是非常有趣的。