Yep, they're called by the controller. Services (and maybe gateways, depending on your architecture) are the only piece of the model that the controller is aware of. In other words, they hide the entire application behind the API they expose, so UI's don't need to care how the app works aside from that API. Very powerful, because it lets you restructure your application (switch from inline SQL to DAOs, for example) without affecting the UI at all.
I haven't worked with Model-Glue enough to say for sure, but there's three approaches that I see. One is to load your service objects using the config bean loader mechanism, and then the services will do whatever they need to make the backend work. That's simple, easy to use with MG, and leverages what the framework has to offer. However, it also couples your services (which are the model), to the UI framework. I.e. you can't (at least not easily) reuse the same services if you need to expose some web services or something, becuase the web services aren't going to be using MG, and therefore won't be able to do the config bean stuff. The second is to initialize your service objects in Application.cfc or Application.cfm (depending on which CF version you're running). That makes the services UI neutral (they just exist in the application scope for any CF code to access), but makes you do the initialization and configuring of the services manually, rather than using the simple and elegant mechanism that MG provides for free. That goes for both the initial instantiation, and the referencing of the services from inside MG. Finally, the third would be a combination, where you load your services manually in Application.cf(c|m), and then write config bean wrappers for them that you can load with MG's built-in mechanisms, and woud act as adapters to make the non-MG services appear as native MG config beans to the MG app itself, without sacrificing the ability to use the services with non-MG UIs as well. I'm not going to make a recommendation, but hopefully someone more familiar with MG will. With Fusebox (both 3 and 4), I take the middle route, and have <cfset user = application.userservice.getUserById(userId) /> style code throughout my Fusebox app. cheers, barneyb On 8/19/05, Peter Hardy <[EMAIL PROTECTED]> wrote: > Then ask I shall :) How do service objects fit in with the MVC pattern (more > specifically Model-Glue). From what you've said thus far, I'm guessing that > it's called by the Controller but call that a not-so-educated guess. > > Thanks for all your help by the way. > > Cheers, Pete (aka lad4bear) > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
