【发布时间】：2020-09-19 05:19:32
【问题描述】：
我想知道这个。我现在已经有一段时间感兴趣和玩了——尽管我承认也有点沮丧，因为这里的一些最有见识的帖子很难理解，因为它们涉及到很多我不熟悉的额外行话时间，即像这样的：
How should a model be structured in MVC?
在描述它时，尽管这可能更多是因为我的编码背景更多地是在桌面和移动领域而不是互联网/网络领域（但最好将类似的信息性帖子“翻译”为该上下文甚至更好，只是更概念化和更详细地解释了所有概念，例如“域对象”等，因为 MVC 是一种非常广泛适用的模式）-“模型-视图-控制器”或 MVC 模式布置一个软件，我现在理解如下：
- 该软件由三个“层”组成。最高层是模型层，或“业务逻辑”层。这是制作程序应该制作的东西的所有“坚果和齿轮”（例如，在电脑游戏中，这是所有游戏逻辑的所在）发生的地方。另外两层是数据层和UI层；实际上，它们负责将模型层转换为系统输出，分别转换为永久存储和计算机的用户界面外围设备（例如屏幕、键盘/鼠标/触摸板等）。
- 模型层分为四部分：领域对象，包含实际的业务逻辑，数据映射器，抽象对持久存储（可能是数据库）的访问，例如 Android 的 Room Persistence Library [SQL wrapper]，或者说，桌面/服务器空间中的文件系统），repositories 保存数据映射器并提供类似“库”的接口例如，您可以在其中通过键（例如“findSomething()”方法）以及作为模型层与 UI 和数据层之间的接口的 services 查找并获取域对象。
- UI 层分为 View 和 Controller 组件，其中 View 组件接管模型层数据向用户的呈现，并Controller 组件接管模型层数据的mutation；也就是说，它们向模型层中的服务发送具有副作用的命令。正是从这一点，以及模型层的存在，整个模式的名称就产生了。
我的问题涉及与现代 GUI 系统相关的模式的最后一部分 - 包括移动设备和桌面设备，例如Android（因为没有钱，我对 Apple 的经验为零）。特别是，在我看来，实现这一目标的一种合乎逻辑的方式（如果我的那部分是正确的 - 正如我所说，这些帖子往往很难理解，因为它们不仅涉及所有这些专业术语，而且还涉及我的解释尝试在网上寻找它们同样不透明）是建议视图应该与负责显示模型状态的 GUI 小部件相关联，而控制器应该与用户将与之交互以导致事情发生的那些小部件相关联（其中在大多数情况下意味着必须在模型层发生某些事情。
不过，问题在于，在现代 GUI 系统中，这似乎很难安排，因为它们混合了这些东西 - 一个更令人震惊的例子是，比如说，文档编辑器的主要小部件，它融合了编辑和显示职责到 GUI 的单个元素中，因此它必须同时更改和显示模型层中保存的文档（大概）。此外，可以显示哪些 controller 小部件又取决于模型层的状态，因为某些功能在某些状态下可能可用也可能不可用，我们可能希望 UI 反映这一点，这看起来像视图（演示）功能。 （根据给定功能是否可访问或在给定模型状态下是否有意义，请考虑按钮是否变灰。）
如果使用预制的小部件系统（几乎所有 GUI 系统都提供），那么当视图（访问）和控制器（变异）强调的关注点尽可能分开时，最佳实践是什么？为您呈现如此融合的界面？最后，诸如包含这些经常混合的小部件的窗口之类的东西的创建到底去哪里了？是在视图、控制器或 UI 系统的其他部分中，在 MVC 类别架构之外？
或者我在这里错过了更多的东西，因为我之前提到的关于发现现有材料相当难以理解的内容似乎很可能？
（我还要补充一点，如果有的话，将相关的 MVVM 模式 [模型-视图-视图模型] 拟合到现代 GUI 系统似乎更容易，因为它们不会进行访问/变异拆分；但是似乎组织模式的选择不应该取决于您打算定位的特定 UI 框架，因为这违背了目的。事实上，Android 似乎非常暗示它通过提供称为 ViewModel 的东西“想要”一个 MVVM 模式除了它的片段和活动之外，这将是 MVVM 的视图，它们不受加入元素与突变元素的这种相同分离的约束。尽管如此，对我来说，访问/突变拆分似乎是合乎逻辑的，我要问的只是如何在这些系统中实现它。）
【问题讨论】：
标签： user-interface model-view-controller mobile desktop-application software-design