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
