从最近几天开始，我一直在为我的新 Web 应用程序寻找最佳架构，该应用程序将使用 C# 在 ASP.Net 中开发。到目前为止，我只发现并研究了以下3个
现在我的问题如下：
1) 据我了解 3 层架构和 MVP 我可以说 MVP 和 3 层是 一样的东西？如果不是，那么两者之间有什么区别？ （注：我只找到 MVC 和 MVP 或 MVC 和 3 Tier Archi 之间的区别，但没有人解决差异 MVP 和 3 Tier Archi 之间）
2）我只发现以上三种架构选项，还有其他选项吗 也可用吗？ （注：这里我只想要网络整体架构的选项 应用程序，如上面3）
从软件架构的角度来看；我们使用术语是因为术语具有某种含义。当您使用“3 层”之类的术语时，您应该在符合其预期和理解含义的地方使用它。仅仅凭借具有某种类型的三个离散组件，各种事物都可以被视为“三层”。但是，如果您使用这个术语来描述 MVP，您就会误导他人。为什么不直接说“MVP”呢？
3 层通常指三个物理层。维基百科上有一篇很棒的文章.
并附有相关图：
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 服务聊天，以在客户端检索和显示数据边。在这种情况下，您可以在客户端拥有一个成熟的应用程序，在后端拥有另一个成熟的应用程序......每个应用程序都有自己上面描述的逻辑层的实现。
选项是敞开的。
