正确的Model-View -_____设计
我一直在阅读有关Model View Controller，Model View Presenter，Model View ViewModel等的内容，通常，基本概念似乎很容易理解：将漂亮的视觉效果和科学胆量保持彼此独立和无知，例如可能。设计巧克力中没有添加逻辑花生酱；酷，我喜欢。 问题是我对于第三部分还是有点模糊，不是模型或视图。每个人似乎都有自己的主意，如何称呼它，应该做什么，什么是正确的，什么是明显的错误……而且我很想弄清楚什么时候Presenter成为ViewModel，什么时候应该让View成为现实。不要这样做，因为那是主持人的工作，并且- 我在乱逛 而不是请别人解释它们之间的区别-因为已经一次又一次地做到了（我知道；我读了不计其数的文章）-我很好奇听到我自己拼凑的模型很少有程序员。 就是说，您会将此设计归类为什么？也许更重要的是，您是否对此有明显的印象？当然，如果这确实是可靠的设计，我很想听到我做的很好，但是我宁愿得到可靠的建议而不是赞美。 注意：我将使用“桥梁”作为Model-View-？的神秘第三部分。避免对其“应该”有任何潜意识的建议。 模型 是对数据的授权。 从网桥接收有关请求的更改的信息。 包含并执行关于数据如何与其他数据相关的所有逻辑。 数据更改时通知网桥（对于网桥表示感兴趣的数据）。文字编辑：允许外部订户（对其一无所知）监视其状态或计算结果。 对视图的知识为零。 视图 与为用户提供查看和操纵数据的方式有关。 从网桥接收有关数据更新的信息。 包含并执行有关如何向用户呈现数据和控件的所有逻辑。 当用户执行了（可能）影响模型的操作时，通知Bridge。 通知Bridge感兴趣的信息。 对模型的知识为零。 桥 是模型和视图之间的协调者和翻译者。 对在模型和视图之间传递的信息进行适当的格式更改。 保留有关“谁需要知道什么”的信息。 具有模型和视图的知识。 补充说明 在更复杂的程序中，通常会有多个模型。在这种情况下，网桥通常承担在多个模型之间进行协调/转换的工作，因此成为应将原型/ API /设计模型构建到哪个模型的权限。（例如，如果构建纸牌游戏程序，并且您要构建备用的甲板改组模型，则应使用Bridge来确定与Bridge正确通信所需的功能。） 在只有一个视图和模型的小型简单程序中，网桥通常会“假定”任一侧都有哪些功能。但是，随着程序变得越来越复杂，建议视图和模型向Bridge报告其功能，这样可以避免效率低下和错误的假设。 我认为这几乎涵盖了它。无论如何，我欢迎您对我倾向于使用的设计有任何疑问，并且我也鼓励您提出任何建议。 和往常一样，感谢您的宝贵时间。