Hi
Stephen,
You've
actually asked a few different questions. I'll try to answer the ones I can and
leave the rest to someone with more experience with
factories.
When a
request comes in, typically you want a controller to handle the request. The
controller will re-scope all of the input variables (FORM and URL variables) and
will then call the appropriate service layer method(s) passing the input
variables if appropriate. A lot of people use a framework like Model Glue for
doing this as you can then just define your controller using XML and can use
conventions that will be understood by many other CF'ers if you need them to get
up to speed with your code.
If for
some reason you don't want to use a framework, you need to decide (as per Joes
recent post) whether to use a front controller or a page controller. In a page
controller, if you go to whatever.cfm that has a controller coded into it that
is different from if you go to whatever_else.cfm. In a front controller, there
is a single file (often called index.cfm) that handles all of your page requests
(you can hide this behind a URL rewriter if you don't want the "ugly" URL
variables).
In a
front controller, you might pass event=search.process (if it was part of a form
you'd pass this in form scope). You can then do anything from a simple case
statement on up to tell your script what service methods to call and then what
view to display. If your application is non trivial, it is best to break out the
different controllers into cfc's which are called by the index.cfm. The above
might call /com/controllers/search.cfc and use the process() method, for
instance. Typically you'll get your controller to return some kind of struct
containing everything from the name of the view to include and the data to
display on that view. Something in the order of:
<cfset Local.Data =
"">
<cfinclude template="#Local.Data.View#.cfm">
There
is obviously quite a bit of checking and introspection and error handling you
need to put into this to make it work when people pass malformed event names,
when the view file doesn't exist, when you need to cflocation to another page
after completing an action, etc. It isn't rocket science, but it does take a
while which is why so many people use frameworks for non-trivial
applications.
As for
the creation piece, it depends on the complexity of your application and how
often elements of it change. If you have a stable production application with a
small number of entities, you can just loop through a list of them and
initialize all of the service layers on application start (during testing, you'd
probably want to do this in request scope just to make debugging quicker
and easier). Again, with a stable production application with a small number of
entities you may also want to initialize the Gateways and DAOs
upfront.
The
bean in something different. The purpose of the bean is to hold a specific set
of object data. The services, gateways and DAO's are the infrastructure
required for the application to run and they should either be initialized
upfront or as required if you have a more sophisticated setup (ask a question
about factories and you'll find out more on this piece). The bean will only be
initialized when your controller calls a method that is supposed to return or
operate on the object.
At the
risk of providing POO advice (Pseudo Object Oriented - see review of podcast at
http://www.fusionauthority.com/Reviews/4625-The-ColdFusion-Podcast-Roundup-Thursday-June-8-2006.htm),
you may also want to look at why you're using a bean at all. There are an also
lot of use cases where a simple service layer and recordsets can provide a less
OO but more appropriate solution. Typically, one of the main arguments for a
bean is that it allows for easy extension of getters and setters for object
properties without breaking any calling code. This is true, but unless you're
going to do all of your editing and display by iterating through collections of
beans (which can be a little slow - especially when you're just
displaying large recordsets) they you're going to have to replicate your bean
getter and setter logic in the service layer or the gateway anyway, and as the
pramgamtic programmers say, when programming, Don't Repeat
Yourself.
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----Hi,
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Adams
Sent: Monday, June 12, 2006 7:46 AM
To: cfcdev
Subject: [CFCDev] accessing the service layer through a CFM
I recently listened to the ColdFusion weekly podcast Safari Edition (episode 1.10) and I really learnt a lot about using design patterns to create CFC's. One question that I do have is, in the podcast they spoke about a service layer, now I know what the service layer should do after looking through the example code they provided, but I was wondering how you access this service layer through the cfm page.
At the moment I'm building a small search form, in which the user either enters a ID number or part of a name, then I have the page reload and create the service layer with which I can access all the methods and functionality I have created in my DAO.
One thing I did notice in their example code was I can't seem to see where they initialise the Bean CFC. In the service cfc the DAO cfc is created, but I thought that the Bean cfc would be created as part of the service layer initialisation, in the service cfc init method?
Do you create the service layer, create the DAO object and the Bean object, then populate the bean all within initialising the service layer cfc?
Thanks
Stephen
----------------------------------------------------------
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).
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).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
