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