关于MVP和MVVM存在一些混淆。
关于MVP和MVVM存在一些混淆。
关于MVP和MVVM的一些困惑\n在提问之前，我已经阅读了很多关于MVP和MVVM的文章。（例如：http://martinfowler.com/eaaDev/uiArchs.html）\n但是在开始开发富客户端应用程序时，我仍然对这两种模式有些困惑。\n
- \n
- MVP和MVVM中的Model是什么意思？
\n
\n例如，一个富客户端应用程序将同时使用本地数据库和远程服务。\n在业务层中，有两种类型的对象！\n从本地数据库中读取的域对象。\n用于保持持久连接的会话对象（例如：异步观看在线用户）\n域对象是Model，没错，但是我是否需要一个特殊的模型层来管理在线用户（或聊天消息），然后再映射到ViewModel？还是直接将这些数据设置到ViewModel中？（映射是多余的吗？因为一个ViewModel可以有多个视图，ViewModel与Model非常相似）\n
- \n
- 在MVVM中，ViewModel可以持久化到数据库吗？
\n
\n例如，想象一个聊天应用程序，即使在离线环境中打开应用程序，您仍然应该能够在聊天窗口中看到最近的消息。\n但是这些最近的消息在ViewModel中，我们应该将ViewModel持久化到数据库吗？（它们是完全属于Model还是ViewModel？）\n
- \n
- MVP比MVVM更好吗？
\n
\n在MVP中，只有一个“模型层”，所以我可以在这个模型层中管理和存储域对象和会话对象。所有视图特殊状态都在视图中，不会被持久化。Presenter将控制视图状态，并在模型和视图之间同步数据。\n在MVVM中，有两个“模型层”（模型和ViewModel），视图状态和模型的副本存储在ViewModel中。那么模型的副本是多余的吗？\n
- \n
- Presenter或ViewModel应该能够查看用于特殊外部服务的数据传输对象（DTO）吗？
\n
\n还是将外部服务调用放在独立的模型层中？\n非常感谢 🙂
一些关于MVP和MVVM的困惑
MVP（Model-View-Presenter）和MVVM（Model-View-ViewModel）是两种常见的软件架构模式，用于帮助组织和管理代码的结构。然而，有些人对这两种模式之间的区别和如何正确使用它们感到困惑。以下是一些关于MVP和MVVM的问题以及解决方法的讨论。
1) "Model"是一个抽象的概念。对我来说，Model是完成工作所需的任何内容。例如，在MVP中，Presenter可能依赖于其视图和两个服务。在这里，这两个服务代表了Model。在另一种情况下，它可能是一个单一的存储库或仅仅是一个数据库连接。
2) ViewModel不应该被持久化。ViewModel将通过Model与可持久化的内容进行交互。
3) 关于这个问题，请参考我在Stack Overflow上的回答。这不是一个哪个更好的问题，而是一个选择合适工具的问题。
4) 我认为Presenter/ViewModel可以与领域对象一起工作。我倾向于使用原始类型来保护视图不了解领域对象，但这只是一种偏好。
这些是一些关于MVP和MVVM的问题和解决方法的讨论。在这些讨论中，某些情况下了Model的抽象概念，ViewModel不应该被持久化，以及Presenter/ViewModel是否可以与领域对象一起工作等问题。在讨论中，还提到了选择适合工作的工具的重要性，并强调了ViewModel在自动化测试中的重要性。
MVP和MVVM是用于组织和管理代码结构的两种常见模式，每种模式都有其自己的特点和适用场景。通过深入理解这些模式的原理和使用方法，可以更好地应用它们来开发高质量的软件。
有一些关于MVP和MVVM的困惑
在所有这些情况下，我不认为这些MV *模式的任何一个字母都是层。把它们更多地视为分离的关注点。
要很好地执行任何MV *模式，我建议在你的Model和ViewModel之间进行映射。主要是因为Model的关注点是在业务领域的上下文中表示该实体，而ViewModel的关注点是在视图上显示/转换一个或多个Model的相关信息。如果你将它们视为一对一的关系，或者你遇到任何试图直接在视图中使用Model的人，他们都是错误的。特别是如果Model是通过类似ORM（EF / NHibernate）从数据库派生的。在最糟糕的情况下，人们不使用映射，而是在视图中使用他们的ORM生成的实体（即使他们试图通过使用代码优先来欺骗自己）。理想情况下，这些层应该能够独立地进行更改。
回答你的问题：
- 在这两种情况下，Model都是领域模型，它由表示业务领域中的概念的实体、值对象和服务组成。
- 这听起来有点像CQRS，其中在共享视图上的ViewModel可以被缓存。但一般情况下，你不会持久化ViewModels。
- 它们是围绕着类似主题构建的不同模式，它们各自都有自己的优点和缺点。但本质上，所有MV *模式都试图将视图、模型、业务规则和UI路由分离开来。一个现实世界的例子是，如果你为一个有开发人员和文案撰写人员的公司工作，那么文案撰写人员可以在不干扰开发人员的情况下工作在UI文件上，反之亦然。
- 就我个人而言，我将与外部Web服务的交互放在基础设施层的自己项目中（使用洋葱架构）
有关MVP和MVVM的一些困惑
MVP（Model-View-Presenter）和MVVM（Model-View-ViewModel）是两种常见的设计模式，用于帮助开发人员组织和管理应用程序的代码。然而，对于这两种模式的定义和用法，有一些常见的困惑。
一些困惑的原因是MVC最初将模型定义为“存在于计算机中的数字模型”，而不是“人类用户的心智模型”。因此，这是一个非常模糊的概念，可以涵盖几乎任何你想要的现实，尽管自那时以来出现的无数MV*实现引入了更有见解的定义。关于MVC/P中的模型是否应该是域对象还是仅仅是对用户所呈现内容的反映，一直存在着传统的争论。而MVVM对此问题给出了明确的答案。
MVVM的出现是为了将业务模型（M）与UI屏幕的数据和行为（VM）分开，这是MVP中没有明确说明的区别。在MVVM中，并没有两个模型的副本，因为M和VM并不总是具有相同的数据，也从不具有相同的行为。例如，一个UserCredentials Model对象将包含Login和Password字段，而相应的UserCredentialsViewModel可能包含一个额外的ConfirmPassword字段和一个VerifyPasswordMatchesConfirm()方法，因为这是显示给用户的内容。另一个主要区别是MVVM中存在基于事件的数据绑定，而在MVP中不存在。一个结果是你经常会看到MVVM模式在客户端使用，因为这里有技术允许这种绑定（如Javascript、WPF），而MVP主要用于服务器端（主要是ASP.NET）。MVP并不比MVVM更好，它们只是适用于不同的生态系统。
Presenter和ViewModel都是UI对象。如果你将DTO（Data Transfer Object）传递给它们，它们可能能够看到远程服务调用的DTO，但它们不应该调用远程服务，因为调用远程服务不是表示对象的责任。你应该在单独的基础设施服务中完成这个任务。
关于第4点的讨论中提到，如果ViewModel能够看到远程服务调用的DTO，它将直接在ViewModel中存储这些DTO。这意味着：（1）ViewModel将DTO转换为ViewModel的类型；（2）这些数据不会被持久化（因为ViewModel只是一个临时内存结构，这并不好）。我认为，我们应该在单独的模型层服务中完成这个任务，而不是在基础设施服务中，因为基础设施服务通常是无状态的。
然后，我们将进行两个绑定：（1）将“模型层服务的数据”（例如：在线用户列表）绑定到ViewModel；（2）将ViewModel绑定到视图。这样做对吗？
我认为它应该在基础设施服务中，因为调用远程API需要了解协议、远程地址等低级技术细节。此外，你不需要在这里保持状态。有状态意味着你在同一客户端的两次调用之间记住一些东西。
绑定是指一种特殊的技术，当数据源发生变化时自动更新某些东西。通常情况下，你不会将服务绑定到视图模型，你只需将服务返回的一些数据传递给视图模型，通过VM的构造函数或其他方法。
在讨论中还提到“有状态”的问题，有状态的服务会保持长时间的连接，并从远程服务器接收事件（如UserJoin和UserLeave，它们是DTOs）。当我收到一个UserJoinEvent时，我会将UserJoinEvent对象转换为User实体对象，并将User对象存储在一个集合（List
如果屏幕显示一个用户列表，ViewModel将包含一个UserViewModel的列表，而不是User的列表。模型（无论是什么）拥有User的集合。
让我们在聊天中继续这个讨论。