Re: [Flashcoders] MVC and Event Architecture
I would really suggest looking into it as it has streamlined a bunch of my previous workflow. I use PureMVC ( with the fabrication utility ) a lot at work and really enjoy it. As with any framework that you use, it might not fit every specific project need, but generally it's been great. As far as the conversation about commands, my experience ( in relation to PureMVC ) is that a command should send out a notification to the mediator ( the view ) to respond to. Then the mediator , which listens to this notification, acts upon it. This decouples your commands from your view and multiple views can respond to the same notification. On Tue, Aug 4, 2009 at 10:54 AM, Merrill, Jasonjason.merr...@bankofamerica.com wrote: 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: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] 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 m...@pierscowburn.com 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: flashcoders-boun...@chattyfig.figleaf.com [mailto: flashcoders-boun...@chattyfig.figleaf.com] 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
[Flashcoders] MVC and Event Architecture
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, 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 Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
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 Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC and Event Architecture
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: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] 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 Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC and Event Architecture
On Tue, Aug 4, 2009 at 4:24 PM, Dave Wattsdwa...@figleaf.com wrote: 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. This is really the key. If you don't do this, you're baking dependencies into your application. And also potentially compilation dependencies, if, for example, you later decide to split your app into modules then you'd have to include the target of the method call across both the relevant modules (or do something with interfaces instead). Ian ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC and Event Architecture
That said, for small systems I still sometimes use callbacks. Me too, but I feel dirty afterward. Well, nobody likes to feel dirty when they code... thanks Dave ! 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: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Dave Watts Sent: Tuesday, August 04, 2009 11:24 AM To: Flash Coders List Subject: Re: [Flashcoders] MVC and Event Architecture 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. This is really the key. If you don't do this, you're baking dependencies into your application. That said, for small systems I still sometimes use callbacks. Me too, but I feel dirty afterward. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC and Event Architecture
Ah, good point Ian. 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: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Ian Thomas Sent: Tuesday, August 04, 2009 11:30 AM To: Flash Coders List Subject: Re: [Flashcoders] MVC and Event Architecture On Tue, Aug 4, 2009 at 4:24 PM, Dave Wattsdwa...@figleaf.com wrote: 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. This is really the key. If you don't do this, you're baking dependencies into your application. And also potentially compilation dependencies, if, for example, you later decide to split your app into modules then you'd have to include the target of the method call across both the relevant modules (or do something with interfaces instead). Ian ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC and Event Architecture
It depends which type of framework you're talking about, because in PureMVC the controller is the commands. The commands only exist temporarliy, and so you can't 'listen to events from the controller', if that makes sense. So in PureMVC you have the commands directly call public methods in the view classes (or I do anyway!). Piers On 4 Aug 2009, at 16:36, Merrill, Jason wrote: So, if you want the Controller to alter the View (say, tell it to animate), you don't have the controller call a public method of the view - you have the controller dispatch an event and some other class (say, a command class) tells the view to animate? Or do you have the view listen to the controller for the event directly and then react? 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 Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] MVC and Event Architecture
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: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com ] 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 Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
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 m...@pierscowburn.com 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: flashcoders-boun...@chattyfig.figleaf.com [mailto: flashcoders-boun...@chattyfig.figleaf.com] 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 Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
RE: [Flashcoders] MVC and Event Architecture
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: flashcoders-boun...@chattyfig.figleaf.com [mailto:flashcoders-boun...@chattyfig.figleaf.com] 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 m...@pierscowburn.com 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: flashcoders-boun...@chattyfig.figleaf.com [mailto: flashcoders-boun...@chattyfig.figleaf.com] 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
