Great explanations, thanks guys :)
Pete (aka lad4bear)
On 20/08/05, Barney Boisvert <[EMAIL PROTECTED]> wrote:
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]
----------------------------------------------------------
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]
