从最近几天开始，我一直在为我的新 Web 应用程序搜索最佳架构，该应用程序将使用 C# 在 ASP.Net 中开发。到目前为止，我只找到并研究以下 3
下面是我的问题：
1) 据我了解 3 层架构和 MVP，我可以说 MVP 和 3 层是一回事吗？如果不是，那么两者之间有什么区别？（注意：我只发现 MVC 和 MVP 或 MVC 和 3 Tier Archi 之间的区别，但没有人解决 MVP 和 3 Tier Archi 之间的区别）
2）我只发现了以上三个架构选项，还有其他可用的选项吗？（注意：这里我只想要 Web 应用程序整体架构的选项，如上面 3 所示）
从软件架构的角度来看；我们使用术语是因为术语意味着什么。当您使用“3-tier”之类的术语时，您应该在符合其预期和理解含义的地方使用它。仅仅凭借具有某种形式的三个离散组件，各种事物都可以被视为“三层”。但是，如果你用这个词来描述 MVP，你会误导其他人。为什么不简单地说“MVP”？
3-Tier 一般是指三个物理层。维基百科在这里有一篇很棒的文章。
使用相关图表：
MVP 和 MVC 都不排除使用这三个物理层。事实上，简单地将您的应用程序创建为“MVC”应用程序（或“MVP”）并不能真正阐明太多。例如，它可以是服务器端的 MVC（如在 ASP.NET MVC 中），也可以是带有 Javascript 的客户端的 MVC，或者两者兼而有之！
至于您关于架构选项的问题；比赛场地相当开阔。您所做的选择通常取决于您在收集应用程序要求时应该收集的许多因素。
通常，您必须在可扩展性和复杂性之间进行权衡。然而，许多新技术使这种权衡变得微不足道——我建议任何开始一个新项目的人认真考虑它们（一些在下面讨论）。
几乎总是最好在物理上拥有一个专用的数据层（SQL、Mongo、Azure、Amazon，随你选）和一个专用的、可扩展的逻辑层（现在通常在 .NET 领域作为 WCF 服务实现）。
大多数情况下，人们会加入他们的网站和逻辑层……但这并不一定是这样。有时，有一个专门用于 Web 服务的物理层是有意义的，只有您的网站层才能访问。同样，这一切都取决于情况。
就逻辑层而言（在您的逻辑层内），几乎总是最好有某种数据访问层 (DAL)、代码内模型（无论是手动实现，还是通过 LINQ-to-Entities 之类的东西实现），以及专用的业务逻辑层。
如今，人们似乎越来越多地回归到经典的 HTML 和 Javascript（在 JQuery、Prototype、DOJO 等的帮助下）并使用 REST/JSON 与 Web 服务聊天，以便在客户端上检索和显示数据边。在这种情况下，您可以在客户端拥有一个成熟的应用程序，在您的后端拥有另一个成熟的应用程序......每个都有自己的上述逻辑层的实现。
选项是敞开的。
我对事情的看法：
3 层与 MVP/MVC 不同。
许多人将“模型”解释为一个非常广泛的概念，其中可能包含许多行为（包括领域逻辑）。我不。模型是视图需要自己呈现的。有时它可能有行为，但再一次，只针对与视图渲染相关的行为。
使用 MVP，您可以在 View 和 Presenter 之间进行 1-1 映射。尽管从概念上讲，您实际上可以拥有更多，但结果可能不会那样。演示者只关心其他层和视图之间的中介。
对于 MVC，控制器处理的视图很可能不止 1 个，因为它与流有关。
所以 MVC/MVP 可以一起使用并且是前端相关的并且是 n 层架构的一部分。
希望这是有道理的。
您将在诸如此类的答案中看到什么是 MVP 和 MVC，它们有什么区别？MVC 和 MVP 正在解决与 UI 有关的代码结构。他们解决了以下问题：
MVC 和 MVP 都没有详细介绍模型内部（或下方）的内容。在某些系统中，模型相对简单，只是数据库顶部的一层薄薄的皮肤，在其他系统中，那里有大量的逻辑，例如与 SAP 和 CIC 等企业系统的集成。
在传统意义上，三层架构（或更一般的 n 层架构）在模型中添加了额外的结构。
这篇维基百科文章讨论了 MVC v n 层架构。我认为在本文中用 MVP 代替 MVC 是合理的。
至于您的应用程序架构：我的看法是，现代应用程序倾向于在浏览器中呈现丰富的 UI，使用由某个服务器上的模型提供的简单 REST 服务，然后在模型中使用一些任意复杂的东西。我想您可以将其视为 n 层架构。有趣的是，当您在浏览器中构建 Javascript（JQuery、Dojo 或其他）时，您会发现设计模式出现了，而 MVC 模式实际上可以纯粹出现在表示层中。