I've generally used the direct call approach as opposed to events. "Someone" has to know which concrete implementations to use for the view and the presenter and that someone does not need to speak in abstractions. In WebForms the view is made for you and it has to get a presenter somehow. If its creating the presenter directly then I see no harm in calling methods on the presenter directly.
I'd use events where I expect to have multiple things listening for them. In a View-Presenter pair I'd consider a 3rd party listening in to be very scary. I've worked on a Web Client Factory app and the events made life a real pain, especially since there was nothing stopping us from raising calling methods directly anyway. On Thu, Mar 25, 2010 at 9:25 AM, Winston Pang <[email protected]> wrote: > Michael, > > Cheers for the reply. > > Yeah, I've been looking around and I dug into the Web Client Factory from > MS as well, and they seem to be doing something different with a high > coupling between the view and the presenter, having the presenter injected > into the view through their IoC. > > I'm yet to understand how IoC is applied in this situation, IF I keep in > line with the design of having the presenter very independant? > > Right now, all I'm doing for my test is Mocking my view interface and model > interface and then instantiating the presenter and invoking the operations > on the presenter and testing the property results on the mocked view. In the > instance of exposing events from the view interface, I'm just mocking the > view interface and raising those events. > > In terms of IoC, the examples I've seen seem to be really pointless in my > situation, correct me if I'm wrong. It's setting up the container in a > custom HttpApplication, and having a abstract view class that queries the > container for the presenter. > > Sure, it will promote great flexibility for storing the references to the > concrete Presenter's in the config files, but, I don't understand how it's > going to help me in testing. > > Thanks again for sheding some light on this. > > > Cheers, > > > Winston > > > On Thu, Mar 25, 2010 at 11:51 AM, Michael Lyons <[email protected]>wrote: > >> Winston, >> >> >> >> We roll our own framework for each (think we have about 6 systems using >> the MVP pattern from memory). It’s quite a trivial operation. >> >> >> >> I highly recommend using events. Their pretty straight forward and if you >> do need to pass something around then create your own event arguments. >> >> >> >> Have you taken a look at Phil Haacks primer that he wrote? >> http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx >> >> The only thing that we don’t do according to Phil Haacks example is pass >> in our data services. We use IoC pattern for these using a Service Locator >> facade. >> >> >> >> I highly recommend picking up an IoC framework to help testability too. >> >> >> >> We use the following open source libraries to assist in our MVP >> development: >> >> · NUnit – testing >> >> · Moq – Mocking during testing >> >> · Autofac – Inversion of control >> >> >> >> I also highly recommend speaking to Damian Edwards as he is a big >> advocator of MVP (and is the co-creator of the framework you were talking >> about). >> >> >> >> Best regards, >> >> >> >> Michael Lyons >> >> >> >> *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
