从最近几天开始，我一直在为我的新 Web 应用程序寻找最佳架构，该应用程序将使用 C# 在 ASP.Net 中开发。到目前为止，我只找到并研究以下 3
下面是我的问题：
1) 据我了解 3 层架构和 MVP，我可以说 MVP 和 3 层是 同一件事情？如果不是，那么两者之间有什么区别？ （注：我只发现 MVC 和 MVP 或 MVC 和 3 Tier Archi 之间的区别，但没有人解决差异 在 MVP 和 3 层架构之间）
2) 我只发现了以上三个架构选项，还有其他选项吗 也可以吗？ （注意：这里我只想要 web 整体架构的选项 应用程序，如上述 3)
【问题讨论】：
标签： asp.net architecture mvp three-tier web-architecture
从软件架构的角度来看；我们使用术语是因为术语意味着什么。当您使用“3-tier”之类的术语时，您应该在符合其预期和理解含义的地方使用它。仅仅凭借具有某种形式的三个离散组件，各种事物都可以被视为“三层”。但是，如果你用这个词来描述 MVP，你会误导其他人。为什么不简单地说“MVP”？
3-Tier 一般是指三个物理层。 And Wikipedia has a great article on it here.
与关联图：
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 映射。尽管从概念上讲，您实际上可以拥有更多，但结果可能不会那样。 Presenter 只关心其他层和视图之间的中介。
对于 MVC，控制器处理的视图很可能不止 1 个，因为它与流有关。
所以 MVC/MVP 可以一起使用并且是前端相关的并且是 n 层架构的一部分。
希望这是有道理的。
【讨论】：
您将在What are MVP and MVC and what is the difference? 等答案中看到 MVC 和 MVP 正在解决与 UI 有关的代码结构。他们解决的问题如下：
MVC 和 MVP 都没有详细介绍模型内部（或下方）的内容。在某些系统中，模型相对简单，只是数据库顶部的一层薄薄的皮肤，在其他系统中，那里有大量的逻辑，例如与 SAP 和 CIC 等企业系统的集成。
在其传统含义中，3 层架构（或更一般的 n 层架构）在模型中添加了额外的结构。
wikipedia article 讨论 MVC v n 层架构。我认为在本文中用 MVP 代替 MVC 是合理的。
关于您的应用程序架构：我的看法是，现代应用程序倾向于在浏览器中呈现丰富的 UI，使用由某个服务器上的模型提供的简单 REST 服务，然后在模型中使用一些任意复杂的东西。我想您可以将其视为 n 层架构。有趣的是，当您在浏览器中构建 Javascript（JQuery、Dojo 或其他）时，您会发现设计模式出现了，而 MVC 模式实际上可以纯粹出现在表示层中。
【讨论】：