我们在这里的Java商店工作，我们的Web应用程序使用MVP架构模式的实现。我们的经理来自.NET世界，他接触过MVVM设计模式。我们的经理主张改变我们的MVP实现，包括演示者应该通过观察者设计模式与传统的MVVM分离（或松散地耦合，取决于你的解释）其观点。我更倾向于认为Presenter和View共同努力实现共同的目标，因此应该加以耦合。
支持这一变化的论点之一是能够对演示者进行单元测试。如果演示者只将观点视为观察者，那么论证就是这样，那么它们可以更容易地进行单元测试。但主持人强烈反对他们的观点并不一定难以测试。如果View使用Humble View范例，则可以对其进行模拟。最后，可测试性应该是良好设计的症状，而不是设计的驱动因素。
我的经理用来支持分层视图和演示者的另一个论点是MVVM的假设成熟度。因此，我们应该遵循MVVM的教导并适应其MVP的实现。如果我错了，请纠正我，但MVVM强加了（人工）视图和演示者的分层，以便在控件中实现数据绑定。
你能帮我们看看这里的灯吗？我们为什么要使用解耦模型并为此付出代价？我没有看到好处。 Occam的剃刀说我需要使用去耦的参数，测试似乎不是其中之一。澄清：我真正想要的是这个问题的论点可以为平衡提供平衡，有利于主持人不了解其观点并在以太中发射事件或支持通过更直接的耦合了解其视图的演示者，例如简陋的视图界面或直接与班级。请注意，演示者可以轻松地为多个视图提供松散和紧密耦合。不同之处在于演示者与之交谈的界面：松散耦合，演示者与听众类（或事件总线代表）对话，而紧密耦合，演示者与视图界面对话。
答案 0 :(得分：3)
<强>更新
看起来TS不会询问是否将interface而不是class传递给presenter，但是presenter是否正在与view进行通信通过另一层（让我们调用observable）。它只是尝试反映MVVM中用于视图管理的WPF模式。如果是这种情况，那么我之前的所有论据都是无效的。
就我个人而言，我认为这种做法很糟糕，并没有带来许多好处而不是利弊。以下是我想提到的几点：
Humble view已足够可维护性
如TS所述，简陋的观点已经足以创建可测试的类，并且模块化足以分离关注/责任。你可以看到我的回答的修改说明，卑微的观点已经可以维持。
增加了复杂性和学习曲线
除非您的方法得到内置分布式库（如WPF）的支持，否则您将无法学习该方法。这并不常见，新的开发人员会发现很难学习你的设计。
它降低了代码可发现性
我对WPF的经验是，如果在文件夹结构中没有适当的协议，你会发现很难发现演示者（因为它会引用可观察的）。 WPF有一些关于文件夹结构的指南（称为约定），因此理解WPF的新开发人员会理解它。
难以调试
如果错误地声明了绑定（收听点），您将很难找到错误。大多数时候，错误会给你错误的异常。即使在WPF中，新手也很难调试。
更难以确保属性更新和无限循环的更多风险
在开发WPF期间，我发现很难确保视图和演示者（viewmodel）之间的属性更新。听取Knockout和WPF等变化的MVVM设计具有更高的无限循环发生风险（改变道具A更新道具B更新道具A等等）。
您已经通过了编译器验证
我不喜欢WPF / MVVM是编译器无法帮助验证您的绑定。这意味着null reference和data type error只能在运行时级别处理。
无法实现网络应用。
可观察图层可能在桌面应用甚至移动应用等事件驱动的应用中非常有用。然而，在基于Request -> Response构建的Web应用程序中，它只是一个无用的抽象层。我还发现了可以在Web和应用程序架构中使用的任何演示者逻辑。如果它仍然是重复的，为什么不让它更简单？此外，Humble View方法可能在网络架构中使用（不完美，但可以）。
无论如何你都需要BLL
无论您构建什么体系结构，您仍然只能处理PL级别的代码。您仍然需要在另一层中使用BLL，以确保无论UI是什么（Web /桌面），都可以重用业务逻辑。
好处只是另一层分离
我不知道你想在java中接近什么。但是在WPF中，我发现修改视图更容易，更安全（不破坏viewmodel / presenter）。
<强>要点：
MVP使用observable，您违反了KISS / YAGNI。如果您不使用分布式库，则也会违反Reinvent the Wheel。唯一的好处是支持DRY（管理数据绑定），但由于它不能用于Web结构，因此不值得。
答案 1 :(得分：2)
您和/或您的经理可能会混淆依赖方向和耦合紧张。
MVVM和（被动视图）MVP之间的本质区别在于前者，由于绑定和命令，ViewModel基本上不了解View。依赖从View到ViewModel。在Passive View MVP中，它采用另一种方式 - Presenter指向View，填充其数据并监听其事件。
它不需要紧密耦合 - 您可以将Presenter耦合到View的抽象，它可以通过测试上下文中的模拟体现。这是松耦合。
话虽如此，我同意你的观点，两种模式（MVVM和被动/谦卑视图）大致同样可以测试。此外，MVVM在.Net环境中基本上是有效的，您可以在其中利用绑定和命令，这使得该特定模式在Java生态系统中成为一种奇怪的调用。 Java世界中可能存在类似的方法，但它们不称为MVVM。