Can i say that MVP = 3 Tier Archi?

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

• Three Tier Architecture (Note: By Tier i mean logical layer)
• Model View Controller (MVC)
• Model View Presenter (MVP)

Now folling are my questions:

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 differ开发者_开发问答ence 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) 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)

---

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 generally refers to three physical tiers. And Wikipedia has a great article on it here.

With the associated diagram:

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).

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).

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.

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.

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.

Options are wide open.

---

My take on things:

3-tier is not the same as MVP/MVC.

Many folks interpret the "Model" as a very broad concept that could contain lots of behaviour (including domain logic). I don't. The model is what the view needs to render itself. Sometimes it may have behaviour but, once again, only for behaviour related to view rendering.

With MVP you have a 1-1 mapping between the View and the Presenter. Although conceptually you could have more in reality it probably won't turn out that way. The presenter is only concerned with mediating between other layers and the view.

With MVC there is in all probablity more than 1 view that the controller deals with since it is concerned with flow.

So MVC/MVP can be used together and are front-end related and are part of the n-tier architecture.

Hope that makes sense.

---

You will see in answers such as this What are MVP and MVC and what is the difference? That MVC and MVP are addressing the structure of the code concerned with UI. They address questions such as:

• Which component understands the user's actions?
• Which component decides what view to present next?
• What is the relationship between View and Model?

Neither MVC nor MVP go into details of what's inside (or beneath) the Model. In some systems the Model is comparatively simple, just a thin skin on top of a database, in other systems there's an awful lot of logic down there, for example integration with Enterprise systems such as SAP and CICs.

In its traditional meaning a 3-tier architecture (or more generally an n-tier architecture) puts additional structure inside the Model.

This wikipedia article discusses MVC v n-tier architectures. I think it's reasonable to substitute MVP for MVC in this article.

As to your application's architecture: my perception is that modern apps tend to have a rich UI presented in the browser, using simple REST services supplied by a Model on some server and then some arbitrarily complex stuff in the model. I guess you can see this as an n-tier architecture. The interesting thing is that as you structure your Javascript (JQuery, Dojo or whatever) in teh browser you find design patterns coming out, and an MVC pattern actually can emerge purely in the presentation tier.