三层体系结构中的MVVM WPF应用

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

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

我目前没有使用WCF，因为此时所有东西都驻留在同一台机器上，除了在自己服务器上的数据库。然而，在未来，我们计划将代码库分成3层

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

表示层-用户计算机中的客户端WPF应用程序（视图）。这也可能是一个Web客户端应用程序

逻辑层服务器-视图模型+模型+业务逻辑层+数据访问层

数据层服务器-数据库服务器

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

编辑：我的同事声称，在服务器端使用视图模型将简化未来的部署，并使其更易于维护，因为更改只会在服务器端进行。然而，我已经使用ClickOnce部署了.NET应用程序，这并不是什么大问题

您可以在用户计算机上安装一个WPF客户端应用程序，该应用程序包含视图和视图模型，然后通过通信层（如WCF）在较低层公开服务

在MVVM中，UI层分为两层。ViewModel负责应用程序逻辑，View只负责演示文稿 基于此，我的基本问题是，视图和ViewModelUI层是否可以位于不同的层（服务器）中？如果是，是否建议这样做？如何才能做到这一点

---

谢谢

让我们从显而易见的事情开始：

ViewModels不在服务器上。它们的作用是使来自多个服务/模型的数据可供视图使用，并提供视图和数据之间的链接。没有人这样做，也没有人会认为这是个好主意。永远

您的数据层可以位于您希望它位于的任何位置，只需最少的干预

我们将讨论的是，有多少业务逻辑层被提升为WCF层，还有多少将保留在客户机上。这就是讨论的内容

---

如果您的同事坚持认为viewmodel应该在服务器上，请他/她制作原型。它应该是非常有趣的。

视图模型，不管你怎么称呼它，最后是一个保存在计算机内存中的

对象的实例。就像任何其他实例化的类一样。其目的是连接视图和模型，访问各种BL方法等

即使可以将视图模型的一个实例从某个服务器传递到客户机（假设您在服务器上对其进行二进制序列化，并在另一端对其进行反序列化）——除了会产生巨大的开销（在网络和CPU上），我也看不出它如何使事情变得更简单，相反，我想了解这将如何使事情更易于维护

视图和视图模型都应该位于客户端。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中所做的更改不需要创建新版本的客户端（只要不破坏任何接口，不更改模型等）
请注意：“视图模型”和“模型”是两个不同的东西。我肯定他没有坚持要把“视图模型”放在与视图不同的机器上。对不起，我更正了。是的，他坚持把视图模型放在另一台机器上，这是我很难想象的！毕竟我读过没有人提出过这样的建议。如果是这样的话，问问他是怎么想的。这是一个坏主意，它会使视图模型变得无用。告诉你的同事他疯了。听起来他把MVVM和三层服务器客户端架构搞混了，它们不是完全一样的东西。我同意“视图和视图模型都应该在客户端。”。