Hey Winston,
Not sure what client your working with currently, but feel free to email me directly on glav @ aspalliance.com if you'd like to discuss it further. Happy to help where possible. - Glav From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Winston Pang Sent: Thursday, 25 March 2010 11:17 PM To: ozDotNet Subject: Re: ASP.NET MVP Interesting, well at least, I'm on the right track, and I'm not exactly going insane :). Btw, Paul, I read a document at work, from the current client I'm working on, and it so happens you reviewed it too, I assume you wrote about the MVP section on it? Back on topic, I'm still struggling a bit to see how using an IoC container fits into the context of testing, I mean, I mock my view's, and my model's in some cases, but I require the real presenter anyway, since that's what I'm verifying against, so where does IoC fit in with testing and in conjunction with MVP per se? Cheers, Winston On Thu, Mar 25, 2010 at 11:06 PM, Paul Glavich <subscripti...@theglavs.com> wrote: 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
