我可以说 MVP = 3 Tier Archi 吗? [英] Can i say that MVP = 3 Tier Archi?

问题描述

从最近几天开始，我一直在为我的新 Web 应用程序寻找最佳架构，该应用程序将使用 C# 在 ASP.Net 中开发.到目前为止，我只找到并研究了以下3

From last few days i have been searching the optimal architecture for my new web application, which would be devloped in ASP.Net using C#. Until now, i only find and study following 3

• 三层架构(注:由层我的意思是逻辑层)
• 模型视图控制器 (MVC)
• 模型视图演示者 (MVP)

下面是我的问题:

1) 据我了解 3 Tier Architecture 和 MVP 我可以说 MVP 和 3 Tier 是同样的事情?如果不是，那么两者之间有什么区别?(注:我只发现MVC 和 MVP 或 MVC 和 3 Tier Archi 之间的区别，但没有人解决差异MVP 和 3 Tier Archi 之间)

1) As far as i understand 3 Tier Architecture and MVP can I say that MVP and 3 Tier are the same thing? If not, then what is the difference bewtween both? (Note: I only find the difference between MVC and MVP or MVC and 3 Tier Archi but no one adress the diff between MVP and 3 Tier Archi)

2) 我只发现了以上三个架构选项，还有其他选项吗也可用?(注意:这里我只想要网络整体架构的选项应用程序，如上面 3)

2) I only discover above three architectural options, is there any other options available too? (Note: Here i want only the options for overall architecture of web application,like above 3)

推荐答案

从软件架构的角度；我们使用术语是因为术语意味着什么.当您使用诸如3-tier"之类的术语时，您应该在符合其预期和理解含义的地方使用它.仅仅凭借具有某种类型的三个离散组件，各种事物都可以被视为三层".但是，如果您使用该术语来描述 MVP，您会误导其他人.为什么不简单地说MVP"?

From a software architecture perspective; we use terms because terms mean something. When you use a term like "3-tier", you should use it where it fits it's intended and understood meaning. All sorts of things could be deemed "3-tier" simply by virtue of having three discrete components of some sort. But, if you used that term to describe MVP, you'd be misleading the other person. Why not simply say "MVP"?

3-Tier 一般是指三个物理层.维基百科在这里有一篇很棒的文章.

3-Tier generally refers to three physical tiers. And Wikipedia has a great article on it here.

与相关图表:

MVP 和 MVC 都不排除使用这三个物理层.事实上，简单地将您的应用程序创造为MVC"应用程序(或MVP")并没有真正澄清太多.例如，它可以是服务器端的 MVC(如在 ASP.NET MVC 中)，也可以是带有 Javascript 的客户端 MVC，或者两者兼而有之！

Neither MVP nor MVC exclude using these three physical tiers. In fact, simply coining your application as an "MVC" application (or "MVP") doesn't really clarify much anymore. For example, it could be MVC on the server side (as in ASP.NET MVC) or it could be MVC on the client side with Javascript, or both!

至于您关于架构选项的问题；比赛场地非常开阔.您所做的选择通常取决于您在收集应用程序要求时应该收集的许多因素.

As far as your question about architectural options; the playing field is pretty wide-open. The choices you make typically depend on a number of factors which you should be collecting while you collect your application requirements.

很多时候，您必须在可扩展性和复杂性之间做出权衡.然而，许多新技术正在使这种权衡可以忽略不计 - 我建议任何开始新项目的人认真考虑它们(下面讨论了一些).

Often times you must make a trade off between Scalability and Complexity. However, a number of new technologies are making this trade off negligible - and I'd advise anyone starting a new project to consider them seriously (some discussed below).

最好在物理上拥有一个专用的数据层(SQL、Mongo、Azure、Amazon，任您选择)和一个​​专用的、可扩展的逻辑层(现在通常作为 .NET 中的 WCF 服务实现)).

It's almost always best to have, physically, a dedicated data tier (SQL, Mongo, Azure, Amazon, take your pick), and a dedicated, scalable, logic tier (usually implemented these days as WCF services in .NET land).

大多数时候人们会加入他们的网站和逻辑层……但事实并非如此.有时，为只能由您的网站层访问的 Web 服务专门设置一个物理层是有意义的.同样，这一切都取决于情况.

Most times people join their website and logic tiers... but this doesn't have to be the case. Sometimes it makes sense to have a physical tier exclusively for web services which are only accessible by your web site tier. Again, it's all situation-dependent.

就逻辑层而言(在您的逻辑层内)，拥有某种数据访问层 (DAL)、代码内模型(无论是手动实现还是通过诸如 LINQ-to-Entities 之类的东西)几乎总是最好的)，以及专用的业务逻辑层.

As far as logical layers go (within your logic tier) it's almost always best to have some sort of data access layer (DAL), an in-code model (whether implemented manually, or through something like LINQ-to-Entities), and a dedicated business logic layer.

现在越来越多的人似乎回归经典的 HTML 和 Javascript(借助 JQuery、Prototype、DOJO 等)并使用 REST/JSON 与网络服务聊天以检索和显示数据在客户端.在这种情况下，您可以在客户端拥有一个成熟的应用程序，在您的后端拥有另一个成熟的应用程序……每个应用程序都有自己上面描述的逻辑层的实现.

More and more these days people seem to be falling back to classic HTML and Javascript (with the help of things like JQuery, Prototype, DOJO, etc.) and using REST/JSON to chat with web services for retrieving and displaying data on the client side. In this scenario you can have a full-blown application on the client side, and another full-blown application in your back end... each with their own implementations of the logical layers I described above.

选项是开放的.

这篇关于我可以说 MVP = 3 Tier Archi 吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！