Design patterns 要在MVP中查看的松散耦合演示者

我们在这里的一家Java商店工作，我们的web应用程序使用架构模式的实现。我们的经理来自.NET世界，在那里他接触到了设计模式。我们的经理提倡对MVP实现进行更改，包括演示者应通过观察者设计模式与视图分离（或松散耦合，取决于您的解释），这是MVVM的传统。我更倾向于认为，演讲者和视图一起工作，以实现一个共同的目标，因此应该结合起来

支持这一变化的论据之一是单元测试演示者的能力。如果演示者仅以观察者的身份查看视图，则可以更轻松地对其进行单元测试。但与他们的观点紧密结合的演讲者并不一定很难测试。如果视图使用范例，那么它可以被模仿。最后，可测试性应该是良好设计的标志，而不是设计的驱动因素

我的经理支持将视图和演示者分层的另一个论点是MVVM的成熟度。因此，我们应该遵循MVVM的教导，并适应其MVP的实现。如果我错了，请纠正我的错误，但是MVVM强制（人为地）对视图和演示者进行分层，以方便其在控件中的数据绑定

你能帮我们看看这里的灯吗？我们为什么要使用解耦模型并为此付出代价？我没有看到好处。Occam的razor说我需要参数来使用解耦，而测试似乎不是其中之一

---

---

澄清：我在这个问题上真正想要的是能够打破平衡的论点，有利于不知道自己观点的演讲者在以太中拍摄事件，或者有利于通过更直接的耦合知道自己观点的演讲者，像一个简陋的视图界面或直接到类。请注意，演示者可以轻松地使用松耦合和紧耦合提供多个视图。不同之处在于演示者与之对话的界面：松散耦合时，演示者与监听器类（或事件总线代表）对话，而紧密耦合时，演示者与视图界面对话。

更新：

看起来TS不会询问是否将

接口

而不是

类

传递给

演示者

，而是询问

演示者

是否通过另一层与

视图

通信（我们称之为observable）。它只是试图反映

WPF

中用于视图管理的

MVVM

模式。如果是这样的话，那么我之前所有的论点都是无效的

就我个人而言，我认为这种方法是不好的，不会带来很多好处而不是坏处。以下是我想提及的几点：

简陋的观点

已经足够维护了

正如TS所述，谦虚的观点已经足以创建可测试类，模块化足以分离关注点/责任。你可以看到我对答案的修改，即“谦虚观点”已经可以维护了

它增加了复杂性和学习曲线

除非您的方法得到内置分布式库（如WPF）的支持，否则您将注定要学习这种方法。这并不常见，新开发人员会发现很难学习您的设计

它降低了代码的可发现性

我对WPF的经验是，如果在文件夹结构上没有适当的协议，你将发现很难发现演示者（因为它将引用可观察的）。WPF对文件夹结构（称为约定）有一些指导原则，因此了解WPF的新开发人员将理解它

更难调试

如果绑定（侦听点）声明错误，您将很难找到错误。大多数时候，错误会给你错误的例外。即使在WPF中，新手也很难调试

更难确保财产更新，无限周期的风险更大

在开发WPF期间，我发现很难确保视图和演示者（viewmodel）之间的属性更新

MVVM

听取变更（如击倒和WPF）的设计具有更高的无限循环发生风险（A提案的变更更新了B提案，B提案更新了A提案等）

您通过了编译器验证

我不喜欢

WPF

/

MVVM

的地方是编译器无法帮助验证绑定。这意味着

空引用

和

数据类型错误

只能在运行时级别处理

它不可用于web应用程序

可观察层在事件驱动的应用程序（如桌面应用程序甚至移动应用程序）中可能很有用。然而，在基于

请求->响应的web应用程序中，它只是一个无用的抽象层。我还没有找到任何可以在web和应用程序体系结构中使用的演示者逻辑。如果它将被复制，为什么不使它更简单呢？此外，
谦虚的观点
方法可以在web架构中使用（虽然不完美，但可以）

你无论如何都需要BLL

无论构建什么体系结构，您仍然只处理

PL

级别的代码。您仍然需要在另一层中使用

BLL

，以确保无论UI是什么（web/桌面），业务逻辑都可以重用

好处只是另一层分离

我不知道你想用java做什么。然而，在WPF中，我发现修改视图更容易、更安全（就不破坏viewmodel/presenter而言）

摘要：

使用

MVP

使用

observable

，您违反了

KISS

/

YAGNI

。如果你有