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.
The issue of dependencies when initiating a new view model can be handled with IOC.
public class MyCustomViewModel{
private readonly IShoppingCartWebService _cartService;
private readonly ITimeService _timeService;
public ProductDTO ProductDTO { get; set; }
public ProductDetailsViewModel(IShoppingCartWebService cartService, ITimeService timeService){
_cartService = cartService;
_timeService = timeService;
}
}
When setting up the container...
Container.Register<IShoppingCartWebService,ShoppingCartWebSerivce>().As.Singleton();
Container.Register<ITimeService,TimeService>().As.Singleton();
Container.Register<ProductDetailsViewModel>();
When you need your view model:
var viewmodel = Container.Resolve<ProductDetailsViewModel>();
viewmodel.ProductDTO = myProductDTO;
When utilizing a framework such as caliburn micro there is often some form of IOC container already present.
SomeCompositionView view = new SomeCompositionView();
ISomeCompositionViewModel viewModel = IoC.Get<ISomeCompositionViewModel>();
ViewModelBinder.Bind(viewModel, view, null);
Best Answer
Seems fine to me. ViewModel defines an interface it requires View to implement. But you should only use this when you can't use data binding properly. Eg. you want view to do some action that is not tied to data the view presents.
Why I think this is fine is: The major point of MVVM (or MVP for that matter) is to remove direct dependency between View and ViewModel in either direction. In MVVM, this is mostly achieved by heavy use of reflection in data binding. But sometimes that is not enough, because you cannot easily invoke some action on View from ViewModel. To do that, you create abstraction that represents this action so ViewModel can call this abstracion and View realizes this abstraction. This way, there is still no direct dependence between View and ViewModel, but you can overcome the limitation of data binding.