I tend to take a varied approach.
If the app is of low-medium complexity, I use a direct approach by constructing the presenter in the view itself manually, passing the view instance to the presenter as part of the constructor. Its direct and low in complexity. Construction overhead is trivial. I pass events onto the presenter by simply calling methods of that presenter. If requirements are more complex, such as many dependencies within the presenter, perhaps the need to communicate between presenters and a higher degree of loose coupling, then events on the view with the presenter subscribing to view events is a good way to go. More indirect and a little more work but very workable. Indirection and loose coupling is good, but I try and measure the degree required and benefits, rather than a cover all approach to every single solution as it may introduce extra complexity or dev effort just for the sake of it. Much like webformsmvp, when using events, there is a temptation to write framework code to auto subscribe, using techniques such as reflection to achieve this. There are computational/perf issues which you'd need to consider when going this approach. Testability wise, both are equal. - Glav From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Winston Pang Sent: Thursday, 25 March 2010 10:39 AM To: ozdotnet@ozdotnet.com Subject: ASP.NET MVP Alright guys, So at work, we're looking to use MVP in our project. Can't use any frameworks, so webformsmvp is out of the question. The pattern seems trivial enough, but there seems to be a variety of implementations. One thing I can't pick from is: 1) Add events on the View interface and have the view raise these events that the Presenter has subscribed to, ticks for looser coupling, but I'm not sure what the ramifications are for testing, would it mean when I mock my view, I'd have to raise these events on the view. 2) Have the underlying operations exposed on the Presenter, and have the View invoke the operations, but more coupling, but it means when I'm testing I could just invoke the operations on the presenter and test the results on the View. What's everyones approach on this? Cheers, Winston
