我在尝试了解一些 MVP 内容时感到很有趣，因为它与用户控件有关。我正在使用.NET WinForms(或类似的东西)和监督 Controller 模式(好吧，我想我是:)。
用户控件本身是 MVP 应用程序的一部分(它是 View 并具有关联的演示器等)。 Presenter 总是首先启动，它启动 Model，然后启动 View。 View 构建其 UI，其中一部分将用于 NEW UC，即 View。
现在(表单)Presenter 需要了解 UC Presenter，但我认为它不知道 View 是如何组成的。例如，表单 Presenter 不知道也不应该知道 UC 是表单的 Controls 集合的一部分。
此外，设计体验不应该改变； IOW View (表单)的开发人员应该能够从工具箱中选择用户控件并将其放在表单上。
那么，回答我的问题。首先，我的上述假设正确吗？是不是有点被误导了？弄乱？你在想什么？
其次，让表单 View 调用 UC View，表单 Presenter 调用 UC Presenter，并有某种机制告诉 UC View 它的 Presenter 是什么，是否正确(足够？)？这打破了我的“演示者优先”规则，但我不知道还能怎么做。
任何其他想法、建议、评论都乐意接受。
-- 恩瓦马特
最佳答案
演示者应被视为表示层中的“自治状态”。这意味着它负责确保模型状态的 View 呈现是同步的。我提出这个问题的原因是因为 MVP 的“模式”经常迷失在事物应该如何分离的教条观点中。这似乎是 Martin Fowler 决定尝试 clarify the terminology around the MVP 的原因之一。模式。
我最喜欢的 MVP 风格是 passive view ，所以我的回答就是基于此。
我经常使用被动 View 模式来实现复合用户控件和表单。本质上有 3 种不同的配置:
- 层次结构中所有用户控件的一个演示者。使用界面展平 View 。
- 复合树中的每个用户控件都有一个演示者。每个父演示者负责实例化和初始化其子演示者。用户控件是在设计时创建的，并且能够在没有演示者的情况下运行(没有演示行为)
- 复合树中的每个用户控件都有一个演示者。所有演示者都通过更高级别的 Controller 类松散耦合。 Controller 类负责构建演示者、连接它们并协调它们的事件。
虽然这对我来说是最后的解决方案(因为它的复杂性)，但我认为最后一个选项就是您正在寻找的解决方案。
关于winforms - MVP 和 UserControls 以及调用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/429500/