MVC Frameworks – Using Alternative MVC Frameworks

I guess you're asking in the context of the Microsoft world?

It was my understanding that MVP was mainly employed for unit testing the controllers of the application. I think another term for the MVP pattern is Supervising Presenter.

The view in this case would be the ASP Page, which would have an instance of the Presenter, and any events in the page (click handler's for example) would delegate their work to the Presenter. The Presenter would have a reference to the View (although, through an IView interface that the Page would implement). The Presenter would then respond to actions from the View, do something, update the model and pass it back to the view or perform actions on the View via the interface.

This aids unit testing, because the Presenter (where any presentation logic should be) can have the view mocked out. Typically a Presenter would also have references to other services, which should rely on dependency injection (via constructor injection IMO) to also allow for the Presenter to be tested in isolation (a proper unit test).

The main reason I think to use MVP in ASP.NET WebForms is because the Page class is tied to the ASP.NET runtime, whereas because ASP.NET MVC has abstractions on things like the HttpRequest, and the controller and ActionResult classes can be tested in isolation, you don't need to employ MVP - it's unit testable by default.

So to answer (I think): I'd use MVP if I was using WebForms, to aid testability. Otherwise I'd use MVC.

Also check out the Web Client Software Factory, which offers a framework for a starter point for implementing the MVP pattern.

why an open source project can become successful if new-comer developer have no architectural/design document to read?

The assumption is invariably made that you know what you're doing and have a reasonably intimate understanding of what you're going (and expecting) to see.

If you look into the PHP code of the Symfony framework, for instance, you're expected to already know about dependency injection, events, the model/view/controller pattern, and so forth.

Likewise, if you dive into the C code of the linux kernel, the assumption is that you'll be realistically competent in modularity, signals, processes, threads and what not. You're also expected to have a knack to eat hexadecimal all day and excavate through core dumps with a giant shovel.

The maintainers won't go through the trouble of documenting the architecture because it's matter-of-factly stuff. On occasion, you'll find an outline of what lies where in the source tree. More typically though, the way the source tree is organized makes things self-explanatory.

In short, if you lack any of the skills that the maintainers will expect you know by the time you peek into their code, you're probably digging through stuff that is widely above your pay grade. Familiarize yourself with the concepts first - What is the MVC model? What is dependency injection? Etc. Then dive.