I feel as if I should respond as it was my message that Seth pointed
out. My response inline below....
Bill Rawlinson wrote:
Seth,
My experience on this list shows there to be very little difference
between how most people here define a bean and LTO with the exception
that the LTO stores its variables in the public "this" scope and the
bean stores it in the private "variables" scope.
Since we're mixing terms about lately on the list, I'd say there's not
much difference between a bean and a transfer object (TO). I coined the
term LTO (lightweight transfer object) because there wasn't anything
else good to describe it.
however, some people have defined beans to be a bit heavier in that
they also encapsulate the validation logic for it's properties whereas
a LTO doesn't provide anything but a structured method of passing
those properties around.
Bill's understanding of an LTO is right on - basically it's a documented
structure that is loosely encapsulated that can be easily passed around
disguised as an object. I say loosely encapsulated because it uses the
"this" scope which is publicly accessible (which also means they "could"
be overwritten). However LTOs provide better documentation versus a
regular structure and provide an exact implementation of what the
structure should be. I find that LTOs are good for team development
especially with team member that maybe don't understand how everything
fits together.
Here's example of how I use a bean/LTO:
form/user input --> set values to bean -->
pass in my error handling object into my validate() method in my bean -->
validate bean and return errorHandler -->
logic: if errorHandler.hasErrors() --> display form with errors
else if NOT errorHandler.hasErrors() -->
continue processing such as persist to database in this case -->
myBean.getLTO --> pass LTO to DAO to persists or update
Another example:
getUser by id --> pass userLTO to my UserDAO -->
read database --> return UserLTO back if user exists or throw exception
(which is caught my calling code and processed as desired) -->
user LTO as needed in calling code or populate a bean if needed
This is actually been an oft discussed topic on this list and the
answers that have come up have caused quite a bit of confusion at
times between the differences between the two object types.
Agreed!
Some people here create validation objects that they pass the bean
into along with a "logging" object that tracks the error messages
created during validation and in that case the bean is just a LTO with
getters/setters. Others include the validation logic in the bean.
I prefer to have the validation logic for the bean's data in the bean.
Again, Bill is right on. As you can see, I put my validation inside my
bean "most" of the time. Putting your validation inside your does tie
your validation scheme to the form/user input that uses that bean.
Since most of the time, this doesn't vary - I don't see much of a reason
to put my validation inside a validation object. Although another
argument can be made that your validation shouldn't vary on and for the
sake of maintenance -- keeping it with the bean is easier. So, I'll
steal my answer -- "It depends"...
Bill
On 11/15/05, Seth Johnson (KW) <[EMAIL PROTECTED]> wrote:
I'm currently preparing to create my first substantial OO/CFC based
application, so you guys will probably be seeing a lot of questions from
me in the near future :)
I was reading the list archives looking for form validation practices,
and I found this thread
(http://www.mail-archive.com/[email protected]/msg09518.html). In the
thread a number of people mention "beans", and that they often allow any
string value to be used in the bean's mutator methods, but they
reference a validator method before doing anything with the bean.
My beans now almost all "loosely" typed (strings) while my LTOs are
"strongly" typed (string, date, numeric).
What exactly is a "bean" in regards to CFCs? My (very limited)
understanding of JavaBeans is that they are simple classes that conform
to special naming conventions, and these conventions make it possible to
plug those beans into editors that know how to reference the beans.
While that depends again -- check out Rooibos Generator which is my
version of beans at http://rooibos.maestropublishing.com
So in "CFC land" is a bean just a simple object with getter/setter
methods, but no business logic? If this is true, how are they different
from lightweight transfer objects? In what situations do you use beans,
and when do you use heavyweight objects?
Thanks in advance,
Seth
HTH,
.Peter
--
Peter J. Farrell :: Maestro Publishing
http://blog.maestropublishing.com
Rooibos Generator - Version 2.1
Create boilerplate beans and transfer objects for ColdFusion for free!
http://rooibos.maestropublishing.com/
Member Team Mach-II
----------------------------------------------------------
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]
