Thanks all - great discussion! Someday I'll have some time to tackle Pure MVC. Cairngorm is cool, but gave me headaches and seemed way too complicated and bloated to use.
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 Matt Gitchell Sent: Tuesday, August 04, 2009 12:08 PM To: Flash Coders List Subject: Re: [Flashcoders] MVC and Event Architecture This is about how I'm doing things at present. If something only affects one 'branch' of the MVC model (mostly View), then I handle it with events, for the most part. If it engages two, then I move to a Command (Controller).I've been working a lot in PureMVC lately, and while it seems like a pain when you're first getting into it (event handlers dispatch notifications which then are dealt with by notificationhandlers, which then hit your public methods in view components), I've found that the amount of enforcement it provides as far as loose coupling etc. is well worth it. It certainly makes changing things later less of a big deal, and it's not all that heavy. On Tue, Aug 4, 2009 at 8:39 AM, Piers Cowburn <[email protected]> wrote: > I'll sometimes use callbacks in small, enclosed parts of a system, which > are coupled by their nature and are never going to have their component > classes used individually in other systems. As a general rule though, this > is the only time that I use them. > > WRT the event / notification question, I usually find a place for both. I > tend to use events if the information is going 'up' the heirachy, and > notifications if it's going 'across'. To put it more clearly, I use events > for smaller 'happenings', and notifications for larger, system wide > 'happenings'. Hope that makes sense! > > Piers > > > > On 4 Aug 2009, at 16:27, Merrill, Jason wrote: > > 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 >> > > > _______________________________________________ > 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
