I'm fairly certain my professor will ask me why I chose to use MVC for my web application.
Truth be told, I'm new to MVC. I read about it, I'm building a blog application using it, I think it's very logical to approach a problem this way.
But why? O_O I draw a blank. How is better suited than say, building an N-tier application?
Well, basically: separation of concerns on the usage level, not the physical level.
Quoting PoEAA on MVC
MVC splits user interface interaction into three distinct roles.
With MVC , you are separating presentation (V, C) from the domain logic (M) and you also separate UI behavior (C) from UI display (V). This is much more maintainable than intermingling all three concerns into one and it also fosters reuse and testing. It allows you to better tackle complexity.
This is nothing that just applies to Web Applications. It is suitable for any applications with domain logic and a UI. With that said, I wouldn't say MVC is the best-suited pattern for a web app though. If all you wanna do is put, say, a Contact Form on the web, then an all-in-one-page script would be sufficient. If you only got a bunch of static pages, MVC is overkill too. So like with any patterns, it depends on the problem you want to solve.
As for the n-tier, the "classic" MVC did not foresee it's use on the Web. With the presentation of the UI happening in the browser and the controller on a remote server, MVC on the web is always also a Multi-Tier architecture, hence the difference between usecase and physical in the beginning. MVC is just not concerned where it happens.
Also see: