You generally get the presenter out of the container so that it can have IT'S dependencies handled. The Presenter should really only be about defining behaviour for the View. Anything else should be delegated elsewhere (such as into a service that gets injected into the presenter). Then when you are testing you can mock out these services, instantiate the presenter and pretend to be the View (as a surrogate for being the user) and ensure that it does the right stuff.
On Thu, Mar 25, 2010 at 8:16 PM, Winston Pang <[email protected]> wrote: > 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 <[email protected] > > 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:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Winston Pang >> *Sent:* Thursday, 25 March 2010 10:39 AM >> *To:* [email protected] >> *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 >> > > -- Michael M. Minutillo Indiscriminate Information Sponge Blog: http://wolfbyte-net.blogspot.com
