Ben,
Well, let's think about it a moment.
A bean gives you the ability to get and set individual properties. What
properties do you need to set() when displaying a page detailing a
publication? I'm not saying anything universal here, but in this particular
case, does the ability to get and set particular properties help us to get
the job done. Probably not. A gateway does it best, and can do it very
efficiently.
Now here's where composition can come into play and be very useful to
efficiently display pages. Let's say we use a Factory to instantiate the
gateways we need for display. Instead of instantiating our gateways every
time we display a page which would be a little inefficient, and who knows,
you might need multiple gateways to display a page, let's create a factory
as a singleton when our application starts up, instantiate it into
application scope, and in it's init() method, instantiate every gateway
we'll ever need to display pages, and keep them in the variables scope
within Factory.
What you get then is a set of instantiated gateways composed into Factory,
hanging out in memory, instantly available to the application.
(this code sample assumes all CFC's are in one directory, which allows you
to use the returntype without a specifying a path)
<cfcomponent displayname="GatewayFactory">
<cffunction name="init" access="public" returntype="GatewayFactory"
output="no">
<cfargument name="dsn" required="Yes" type="string" />
<cfset variables.dsn = arguments.dsn />
<cfset setPublicationGateway(variables.dsn) />
.... (add any other gateways here) ...
<cfreturn this />
</cffunction>
<cffunction name="setPublicationGateway" returntype="void" access="private"
output="no">
<cfargument name="dsn" required="Yes" type="string" />
<cfset variables.PublicationGateway =
createObject('component','PublicationGateway').init(arguments.dsn) />
</cffunction>
<cffunction name="getPublicationGateway" returntype="PublicationGateway"
access="private" output="no">
<cfreturn variables.PublicationGateway />
</cffunction>
.....
</cfcomponent>
Now all of your gateways are instantiated and held in memory - which can
improve performance considerably.
So to display that page, you'd call
application.gatewayFactory.getPublicationGateway().findPublication(someId)
and not
publicationBean.getPublicationGateway().findPublication(someId)
We're using composition to implement an architecture that helps us get the
job done and do it well. But it's from an *implementation* perspective, not
a *conceptual* perspective. You won't find a GatewayFactory in your
conceptual model.
*****
When editing a publication, being able to instantiate your PublicationBean,
set() the initial values, get() them to populate your form, set() them again
when the form is submitted, get() them to validate each that need to be
validated, perhaps selectively, perhaps each in different ways, and then
depending on how the validation goes, either pass the bean to your DAO and
get() the values again to persist them, or get() the values to populate the
form again with your error message ... is all very useful. All those getters
and setters really help to get the job done. The Bean encapsulates the data
for you, so you can work with it. In this case, practically, from the
implementation perspective, a bean is very useful when editing.
Now, there ARE cases when you might be editing a composed entity all in one
go. Here's an example. I'm often building sites in multiple languages. Pages
can have properties which are universal, like it's location in the
navigational hierarchy or it's template, but they also have properties which
are language specific: title, meta tag, navigational label. So what i do in
this case is instantiate an array of language specific PageLanguage beans
inside a Page bean, and the code for the form loops through the array of
PageLanguage beans and generates the fields on the fly and populates them.
The difference here is that it's all edited in one form, so to implement it,
composing those PageLanguage beans into the Page bean helps me to
encapsulate the data necessary for that, validate it, and persist it.
So yes, it's definitely possible that you'll need to compose a bean or
several beans within another when editing an entity, but i'd use it only if
the capability that a bean gives you, all the gets() and sets(), the
encapsulated data, helps you to get your job done.
If you try and implement a model that follows a conceptual perspective,
it'll most likely wind up to be much more complicated than necessary.
"Let's see ... a Publication has a Category and a Category has Publications
and a Publication has an Author or actually an array of Authors ... gee, how
do i build that? Do i need a separate object called Authors to contain the
array of Authors composed into Publication composed into Category? Or are
Categories composed into Publication, because a Publication has a Category?
Or maybe it's both? How do i do THAT? And what about Department? Departments
have Publications and Authors, but sometimes Authors are in multiple
Departments ..."
You take a few steps down that path and you don't know where to draw the
line.
Somebody comes along and says "Just use a gateway and in the find() method,
use a join to get the category and author data" and it seems too simple.
Like they are probably cheating. ;) They aren't. They are just looking at
the model from an implementation perspective and doing what makes sense.
Don't worry. There will be plenty of opportunity to use the power of OO once
you get into it a little deeper. At least that's what i'm finding.
Nando.getToWork(Now('ummm ... can have a coffee first?'))
PS ... i know, i know, Now() doesn't take any arguments, but i argue with it
anyway! ... ;o)
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Behalf Of Ben Nadel
>Sent: Wednesday, December 14, 2005 9:42 PM
>To: [email protected]
>Subject: RE: [CFCDev] Object relations, getting, setting, and validation
>Oh My!
>
>
>Nando,
>
>Thanks. That is all very clear. The only part I don't quite follow is the
>display page. If I have a page that displays the details for a single
>publication, you favor gateway over a bean simply because there is no
>editing taking place?
>
>I just figured a bean would be great when dealing with any page that
>requires editing/viewing/deleting ONE of an item.
>
>Thanks for all the advices.
>
>......................
>Ben Nadel
>Web Developer
>Nylon Technology
>6 West 14th Street
>New York, NY 10011
>212.691.1134
>212.691.3477 fax
>www.nylontechnology.com
>
>"Vote for Pedro"
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>Of Nando
>Sent: Wednesday, December 14, 2005 3:15 PM
>To: [email protected]
>Subject: RE: [CFCDev] Object relations, getting, setting, and validation Oh
>My!
>
>Ben,
>
>If you're just display data on a detail page, all you probably need is a
>gateway. A bean is useful when you're editing data, but if all
>your doing is
>displaying data, a gateway works just fine.
>
>So i'm saying that you can use just a single gateway method, say
>publicationGateway.findPublication(). And within that method, you use the
>necessary joins to fetch the author and category stuff.
>
>When you're editing the publication, you probably don't need to compose the
>author and category stuff into the publication bean. Again, if all you're
>doing is displaying a dropdown list of categories for a user to
>choose from,
>a gateway method works fine. Your publication might have a property
>"category" or "categoryID", but unless you have a specific need
>for the user
>to edit categories within publications, you probably don't need a bean
>composed within another bean, or even to compose a gateway within
>Publication.
>
>In other words, if you have a form for editing categories, you're probably
>doing that separately. Imagine a link to a section of your app - Edit
>Categories. Click on the link, and a list of categories appears (via
>CategoryGateway). Click on a category, and a form loads (via CategoryBean).
>
>In those moments, there is no need for a Publication bean, even tho'
>Publications have Categories and Categories have Publications.
>
>So what i'm saying is that when implementing your model, only use
>composition when you really need it.
>
>Of course, you CAN instantiate a Category, instantiate an array of
>Publication objects within Category, instantiate an array of Author objects
>within Publication, and call category.getPublication().getAuthor() when you
>are editing a particular author, but unless you have a very
>practical reason
>for doing so (sometimes that happens!), it's clearer and simplier just to
>instantiate a single Author bean when editing an author, even if from a
>conceptual level a Publication always has one or more Authors.
>
>I'm trying to say something with the above examples that may not be exactly
>what you were planning to do, of course. Just demonstrating how the
>conceptual perspective can be very different from what you actually
>implement, and suggesting that you can / should keep the implementation as
>simple and transparent as possible.
>
>
>Nando.getSomeSleep('buona serata')
>
>
>
>----------------------------------------------------------
>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]
