[trim]
>
> For me, the service layer served the HTML/Mach-II client as
> well as the Flash client. It was the Flash facade. It
> seemed to me to provide the most code reuse and reduce maintenance.
Well lets assume you have multiple Mach-II applications with their own individual set of listeners. Each listener talks to shared managers. In this light, whats happening is you're processing instructions per listener and asking various managers to carry out their own lifecycles.
What I'm trying to illustrate is your Listener in a typical Mach-II is infact your "Flash Fa�ade" if you will. The view informs a listener of its intention, the intention delegates instructions to sub-children and so on.
Now in a flash client situation you don't have access to Mach-II framework, so you could create "flash listeners" aka FlashFacade to take those key events, process it and delegate it to various managers for their own life cycles. At no point does Flash know about Managers, and it shouldn't as one could argue these are subject to change locations throught development cycle.. If were to happen all you would need to do is update your listeners/facades (or better yet interface it out).
I dislike allowing any occasionally connected client from knowing how the model is peiced together, I'd rather have facades in front of them who take their intentions and flow it through as that in way is giving control back to coldfusion vs simply exposing each manager openly (remotely for that matter). It also makes sure that Managers are treated nicely and are cared for in a proper manner - reducing rogue flashies from invoking methods that could be harmful (ie deleteAll() via Manager will simply assume you know what you're doing and carry it out deleting various sub-objects etc.. Where as via fa�ade it could go "well, are you sure let me check to see if you have permissions etc".. Now this could also be classified as a service instead of fa�ade as a fa�ade realistically is something that gives you a nice interface into complex underlying objects. A service does this but can also take onboard its own set of logic (well that's what I assume anyway..can you tell I'm unsure of that statement now heheheh).
> I'm still not quite clear why you want to create another CFC
> just for flash. Even if you do have some "Flash only"
> functionality, those methods could still be in the service
> layer object, Flash calls it and Mach-II doesn't.
A flash only one is setup for a specific flash client, this may be due to it having specific security requirements or conditions it has to meet before enabling the two to marry well.. In that the flash only cfc should be regarded as part of your view (even though its server side) it just translate a stateful view into cfmx and from there it gets to play in the model that's all. You could have one cfc for both Flash & SOAP that carries out all top level requests (ie BankFacade = BankFacade.deposit(), BankFacade.generateMonthlyReports(), BankFacade.NotifyPoliceOfRoberry() etc.. All have their own individual "services/managers" but the end client doesn't know all it knows is to ask BankFacade...
Its kind of like McDonalds, you the customer never ask anyone but the Cashier for your order, they could delegate to each individual services and managers (chipManager, burgerManager, drinkManager, POSService etc)
Scott.
http://www.mossyblog.com
