Ok thanks Paul, yeah, I know about the concept of loose coupling, I was just wondering how strict people generally follow event-driven loose coupling design when using MVC - so it seems you're saying, for small MVC projects, callbacks are OK, but for large projects, they should really be 100% event driven-loosely coupled. Gotcha - thanks!
Jason Merrill Bank of America Global Learning Shared Services Solutions Development Monthly meetings on the Adobe Flash platform for rich media experiences - join the Bank of America Flash Platform Community -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Andrews Sent: Tuesday, August 04, 2009 11:19 AM To: Flash Coders List Subject: Re: [Flashcoders] MVC and Event Architecture Merrill, Jason wrote: > I know there is probably no definite right or wrong answer here, and it > depends on the type of project, but I'm curious to get your opinion, if > you're experienced with the MVC pattern (not frameworks per se that use MVC, > I know about, say, Commands in Cairngorm and have checked into the Pure MVC > architecture with its use of Notifications [though I only partially > understand the Façade - I do something similar I think in a class I call > "MVC"]- just interested in your opinions of raw MVC development). > > My question is, in practice, when programming with the MVC design pattern, I > know the Model is usually completely decoupled from outside classes, but do > you usually completely decouple all other classes like views and controllers > as well, in favor of dispatching events? Therefore communication between MVC > classes are triggered completely by events (seems logical, but its also a > heck of a lot of event handling) or do you have some coupling going on (i.e. > the controller calls a method in the view telling it to change). Or do you > follow what some frameworks do and use Command classes with lots of event > handling going on? > > Trying to find a good mix, I can see advantages and disadvantages both ways. > I'm doing a lot of event dispatching, but it seems a bit like overkill in > some cases and harder to manage than just calling public methods. Interested > in how you handle it when you use MVC pattern(s). Thanks, > The real point is that to call public methods, you have to know about the object whose method you want to call and you need to know about the method itself. When you broadcast an event, you don't need to know whose listening, your just indicating that something meaningful has happenned and perhaps also passing data that is meaningful. Because of this you can build standalone components that don't need to know everything about the world that surrounds them, so they can be reused and also other people can look at them and understand how the system fits together via the event system. That said, for small systems I still sometimes use callbacks.. Paul > > Jason Merrill > > Bank of America Global Learning > Shared Services Solutions Development > > Monthly meetings on the Adobe Flash platform for rich media experiences - > join the Bank of America Flash Platform Community > > > > _______________________________________________ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders _______________________________________________ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
