除了单元测试的好处之外，我听说的关于 MVP 模式的还有表示层的可重用性。因此，您将设计一个表示层并将其用于 WinForms（富）和 Web。
我目前正在.NET 中开发一个 Windows 窗体应用程序，将来可能会创建一个 Web UI。但是，当我设计表示层和 UI 层之间的交互时，我不确定这种可重用性的概念是否值得所有的麻烦。有时我觉得我正在为可能的 Web UI “简化”我的演示文稿，而专门为 Windows 窗体 UI 设计的演示文稿可能会更多。
那么，你们中有多少人正在从可重用的表示层中获益呢？这种可重用性的东西在现实世界中会出现吗？
MVC/MVP 的价值确实在于两种不同的分离。
表示层和模型之间的分离（无论您决定实现它们）是除了简单系统之外的任何东西的更重要的原则软件设计之一。如果您的应用程序中有任何业务逻辑或非可视化逻辑，您肯定会看到这种分离的好处。
表示层和控制器之间的分离对我来说似乎不太重要。在富客户端应用程序中，您很少会看到这种分离的好处。在 Web 前端，它更为常见（例如，ASP.NET aspx 和代码隐藏或 J2EE jspx 和 servlet）。
也许我没有完全掌握你解释 MVP 的方式，但我不会说其中一个好处是表示层的可重用性——相反，我会说主要好处是模型的可重用性. 这也是使用任何 n 层系统的主要好处之一。如果您想扩展和构建一种新型前端（例如，WinForms、WPF 等），您可以这样做，而无需尝试将所有逻辑从您刚刚构建的 Web 应用程序中分离出来。
我认为您可能误解了角色或演示者。
我认为演示者应该几乎与 UI 无关，即信息的显示方式。
演示者应该从 UI（无论是 web 还是 winform）获取任何输入，在控制器级别开始必要的处理，并保留输出。
UI 应该完全控制该返回的使用方式。
例子：
假设您正在从数据库中提取有关汽车的数据。
您可以将车辆识别号从 UI 传递给演示者，然后要求其返回数据。完成处理后，它将保存返回的数据：假设它具有品牌、型号、年份和最后注册日期。
从您的 UI 中，您应该能够随心所欲地显示它，这使得演示者可重用。您可以在 winform 上显示所有 4 项，但在移动设备的 Web UI 上，您可能只显示基本信息（品牌、型号和年份）。
我同意chills42 的观点——MVP 的目标不是让presenter 如此通用，以至于它可以与任何UI 技术一起使用。目标是使模型和（也许）控制器具有通用性，以便您可以使用所需的任何技术构建 UI。
同样，这可能是我误解了你，但数据绑定与你的问题并不特别相关（也就是说我没有看到联系）。目标是这样的：
您设计您的应用程序逻辑，也称为控制器（例如，当 Bob 提交发票时，系统执行 x、y 和 z，然后向 Bob 显示发票列表）。
您设计您的业务数据，也称为模型（例如，具有行项目列表的发票）。
现在，您想知道，用户界面到底在哪里？您拥有知道如何指导您的流程的东西，并且您拥有执行此操作所需的所有数据，因此您只需要一些东西来向您展示这一切的样子。这就是主持人进来的地方。
您设计了一个与您的控制器和模型交互的 .NET WinForms 应用程序。您制作了一个漂亮的表单，为您的用户提供了一种创建发票的方法。然后，你将所有数据传递给你的控制器，控制器使用它，使用模型处理它，然后告诉你下一步做什么。您的 WinForms 应用程序愉快地继续其愉快的（不知情的）方式并按照指示执行，接收下一个表单的数据并显示它。
然后，你的老板进来说：“嘿，Jiho Han，你的这个应用程序完全成功了。我需要你为我构建一个 ASP.NET 应用程序和一个批处理器来完成所有这些工作。
废话。他要你做什么？哦，没问题。你使用了 MVP。您需要做的就是构建一个 ASP.NET UI（当然，它遵循 Web 标准），它将充当您所有数据的漂亮面孔。没问题——三天——发货。
这就是MVP的好处。您不必重写所有应用程序逻辑；您不必编写大量查询来将数据转换为不同的格式；你不必真正做任何工作。我的意思是，制作 UI 很有趣，对吧？现在由您来决定您是否认为这值得花时间，但几乎在任何实际软件中，您都会对这些组件进行某种分离，无论是 MVP 还是像 n-tier 这样更企业化的东西。
我购买重用故事是因为它曾经对我有用，并且因为我不希望从一种类型的 UI 切换到完全不同的类型会很容易。
一般来说，在您的情况下，我希望必须对 Presenter 进行相当多的修改。没关系，这就是它的用途。它本质上是 UI 和域逻辑之间的适配器。并且由于它有助于将域逻辑排除在 UI 之外，这将使交换 UI 变得更加容易。
哦，顺便说一句，网络应用程序开始变得更加强大。您可能需要为 Web 改进您的 Presenter！
麦克风
我认为你对“愚蠢”的感觉是绝对正确的。
可重用性是项目可能消失的最深、最黑暗和最讨厌的老鼠洞之一，从大约 15 年的 OO 开发经验来看，在此期间，可重用性被吹捧为我们将获得的主要好处之一。
为重用而设计就像为性能而设计 - 它应该是一个背景指导原则，但在大多数情况下，预先过多关注会使您的开发过程陷入困境并导致您过度概括一切。
我通常的建议是首先实现最复杂、最灵活的 GUI，然后重构为更可重用的通用架构。根据项目的大小，在原型中执行此操作，并针对您正在评估的内容制定一些明确的目标。然后，您可以存档原型并保留它，同时将经验教训和一些代码带回主项目。
注意：如果您正在探索 GUI 架构，原型需要使用您打算使用的技术，并且深度和狭窄，而不是用于演示 GUI 外观和感觉的传统 GUI 原型。
MVC 设计提供的可重用性并不是同一个视图/呈现器可以将相同的模型/控制器呈现给不同的输出，而是可以在一个公共视图上呈现不同的模型/控制器集。
一个系统，随着它的成熟，可能需要几个视图：一个 Web 界面、一个桌面编辑器、一个自动化脚本 API 和几个不同的模型： 客户 A 的计费是按订单的，但客户 B 需要它每季度按客户部门。
埃德·阿尔托弗，
我对你所说的控制器有点困惑。
您设计您的应用程序逻辑，也称为控制器（例如，当 Bob 提交发票时，系统执行 x、y 和 z，然后向 Bob 显示发票列表）。
您设计您的业务数据，也称为模型（例如，具有行项目列表的发票）。
但是根据您的陈述，控制器似乎是包含应用程序逻辑（业务逻辑？）的东西，而您的模型只是数据持有者。
据我了解，P代表Presentation。P 关注表示逻辑——如何最好地向用户展示底层业务信息。实际的业务逻辑/规则将包含在模型层中。事实上，你所说的控制器也将是模型层的一部分——M。
无论如何，你关于“苛刻”老板的例子似乎是直接从教科书出来的——我们都知道这一点。这不是我要争论的。
同样，如果 P 用于演示，您的 WinForms 和 Web 可能有完全不同的流程来满足它们的演示需求。更不用说用于批处理应用程序的控制台之一，您甚至可能不需要 P 层。假设数据绑定技术按设计工作，数据绑定使 WinForms UI 层变得如此简单 - V。尝试比较数据绑定和非数据绑定应用程序的来源。在非数据绑定场景中，您必须自己管理更多移动部分。你有更多的控制权，但你仍然必须管理它。在我看来，数据绑定对我如何编写 P 很重要。
我不反对你可以让一个 P 层适用于所有类型的 UI，但我担心，在这样做的同时，你必须在所有 UI 的最小公分母上做出妥协。而且您可能会将更多的表示逻辑推入 UI 层——这反过来又使单元测试更加困难。
我希望这能澄清我最初的困境。恐怕我缺乏充分表达自己的能力...
发冷42，
我认为您可能误解了角色或演示者。
我相信我理解主持人的角色就好了。
我不怀疑您可以使演示者通用，以便它适用于任何 UI。我的问题是，这是否值得付出努力，同时失去了利用某个 UI 平台可以提供的优势的机会。
想想 WinForms 上的数据绑定。通过实现某些接口（IDataErrorInfo、INotifyPropertyChanged、IEditableObject等），您的演示者可以用更少的代码使 UI 更简单。有人可能会说，数据绑定不是一个优势——这无关紧要。许多这些界面对网络没有意义，尽管它可能不会伤害它。我可以为 WinForms 创建一个适配器以用于数据绑定。所以我还有一层。问题是，值得付出努力吗？
MVC 是一种很好的使用模式，即使您最终只将它用于一个前端。它可以帮助您设计具有干净分离部件的应用程序。这带来了几个好处。
它简化了零件的自动化测试，例如您可以直接调用模型，而无需 gui。
由于有清晰的分隔线，因此更容易重新设计应用程序的各个部分，而不会破坏其他代码（例如重新设计 GUI）。
拥有几个较小（并且尽可能独立）的部分，而不是一大堆杂乱无章的东西，这样更容易调试。
向新程序员介绍代码会更容易，因为他们一次可以探索一个逻辑部分。
一般来说，MVC 是一种很好的 OO 方式来设计应用程序，因为它为您提供了一种自然的方式来封装您的应用程序。
你在解释自己方面做得很好——不用担心。:)
注意不要将应用程序逻辑与业务逻辑混淆。应用程序逻辑有时被称为应用程序进程控制，这可能是一个更贴切的名称。这基本上是用户操作和系统响应。例如，步骤 1：用户登录，步骤 2：用户点击“创建新发票”，步骤 3：用户提交基本信息，步骤 4：用户添加行项目，步骤 5：用户将发票提交到发票数据库。
我在下面概述的步骤是适用于您为发票应用程序设计的任何 UI 的流程控制。另一方面，业务逻辑封装在您的模型中。P 是表示，是的，但不是表示逻辑。在大多数情况下，P 将引用面向客户端的内容（例如，ASPX、JSPX、Ruby on Rails 视图等）——它是严格的标记。换句话说，您的控制器为您的表示层提供了一些行为。
鉴于这些定义，您可能会看到，如果您正确创建了控制器和模型，它们将完全与 UI 无关。您不必迎合最低公分母，因为它们只是封装了您的流程逻辑和业务逻辑，允许您的表示层迎合您公开该逻辑的媒介（例如，Internet、控制台或桌面）应用程序）。
附带说明一下，有时控制器和模型实际上以其他一些抽象方式（如 Web 服务）公开，因此您可以拥有一堆 UI 或 Web 服务器来平衡一些传入流量，并且您仍然可以利用相同的后端.
希望这有所帮助？