Re: [CFCDev] Difference between "bean" and "object"?

[Peter J. Farrell]

Seth Johnson (KW) wrote: Peter: thanks for the in-depth reply! No problem... Here's example of how I use a bean/LTO: form/user input --> set values to bean --> pass in error handling object to validate() --> validate bean and return errorHandler --> logic... --> if no errors, myBean.getLTO --> pass LTO to DAO If a "bean" us already a lightweight object, offering only a few getters and setters, is there really a compelling reason to generate a LTO for passing to the DAO, instead of just passing the bean itself? Documentation is one reason for me, however I'll link to this J2EE Pattern doc: http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html Another reason was to standardize the type of object my DAO uses (either to popular during a read or passed to update/create). Quoting from the Transfer Object Link: Typically, applications have a greater frequency of read transactions than update transactions. The client requires the data from the business tier for presentation, display, and other read-only types of processing. The client updates the data in the business tier much less frequently than it reads the data If you are doing a ton of reads without the need to "inject" the data into the form - the LTO is lightweight and reduces the number of calls to methods.  So it comes down to invoking a fewer number of calls on getters (accessors)... Example of use with bean: First Name: #myBean.getFirstName()# Last name: #myBean.getLastName()# Example of use with LTO: First Name: #myBean.firstName# Last name: #myBean.lastName# Since the LTO uses the "this" scope, you're accessing it just like you would a struct.  I do want to say I've not made up my mind if this is best or easiest solution...however, this was the choice for the project I'm currently on and until it's over -- my mind is still open on the subject.  I don't pretend that I know a lot ... Quoting from the Transfer Object Link: The number of calls made by the client to the enterprise bean impacts network performance. Chattier applications-those with increased traffic between client and server tiers-often degrade network performance. Network performance -- sending a huge bean vs. a LTO around your application....etc.  Maybe I think about performance here, but I don't think using it is spending time on optimization because it's just architecture. Quoting from the Transfer Object Link: It is a design choice as to whether the Transfer Object's attributes are private and accessed via getters and setters, or all the attributes are made public. Some people have said I'm "breaking encapsulation" because the LTO uses the "this" scope -- thus why I say "loosely encapsulate" (it's up to the developer not to mess with it -- just like it's their job not to mess with struct if directed).  However, I'm quoting the line because in the end "it depends" on the developer. My beans now almost all "loosely" typed (strings) while my LTOs are "strongly" typed (string, date, numeric). So what happens when SomeComponent.cfc wants to use the data from SomeBean? Does SomeComponent need to determine the data type of the return value before using it? Isn't the primary benefit of a strongly typed design the AVOIDANCE of data type ambiguity? (I'm not attacking you, just trying to understand) nope....just using the type attribute for documentation in the LTO (assuming that your application assumes all data from a database is assumed valid as I always validate before trying to persist data in a database). Do you ever create strongly typed objects to represent fully formed, validated beans? For example, using CustomerBean.cfc to handle the data validation then using Customer.cfc to hold a valid object with strongly typed return values? This is not really possible if you populating your bean from a form (especially HTML) because all data from a form is just strings.  I assume that if you create an LTO - the data used has been validated -- so "strongly" typing the LTO shouldn't be a problem (unless you have a problem with your validation schema). check out Rooibos Generator That's one of the tools that prompted my question :) (Side question: your blog entry on Sept 14 mentions releasing the source code... Are you still planning to do that? I'm building my own CFC generator to add some features specific to my organization, I'd much rather extend Rooibos than start from scratch). Well, the plan might have changed - I'm planning a couple of things for Rooibos.  Going from XHTML/_javascript_ to pure CF and a real application for a couple of reasons. User accounts Per user xml configurations of code formatting/styling etc. Creation of DAOs, beans, LTOs, gateways by reading create table SQL dumps (no need to have access to the database...just the structure of the table) - or just use a template (the current way) Basic boilerplate validation schemas Breaking this all up by project Maybe the possibility of having company accounts with users Since there is lot here...I was thinking of keeping it free for the basic features or like $25 for the whole year for everything.  I've not nailed anything down yet - but that is the plan so far (subject to change! ;-) Best, .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 cfcdev@cfczone.org 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/cfcdev@cfczone.org