My 2c:
Beans Beans Beans, the magical fruit, the more you instantiate the more you want to give the boot.
I've been following threads like this since the word Bean & CFC were coupled, and in truth i've been finding the process long winded at best, and still have yet to see some valid uses for a bean in a cfmx model, other then making room for solving penitential virtual problems that may occur.
I've been thinking that when you're working in the Model realm, you kind of want to trade in currencies, in that if i give you objectX you give me collectionObjectY back or if i give you objectX partially populated, you give it back to me fully populated and valid.
Barney hit the TO's on the nose, in that they typically are used to spit stuff out of the model into the world of "view". In Flex world we typically trade in Value Objects, which are pretty much the TO's but without methods at all. ... structs.. The value objects just brings syntax sensitivity to the table, and makes sure that argumentL in the chain is an integer not a string etc.
So when talking about Beans, BO's and TO's? In my view, there really only needs to be two. Business Object and TO. I can't see a candidate for Beans in CFMX, to me they always sound like a Business Object where by it not only validates data but also acts as DataProvider clones (getItemAt()) etc..
As for memory? realistically, if the in/out routines typically pack/unpack in certain situations, how it get stored internally is a level of tweak/error no?
I've even gone down the path of keeping things simple when turning towards DAO's/DG's in that, I trade in structs/TO/VO's (whatever blows your hair back) whereby i feed in an object, it does a CRUD routine and returns the same object back to the caller, its then the callers job to make sure the Models rules abide... again via one BO...
The only time I'd opt for another layer in terms of beans is if the BO starts getting pretty long winded, but that's OK as if i trade in VO's around the shop, i can keep it pretty lite in terms of memory, then if i need to at various points validate data, i can instantiate, initialize with VO, validate, and return out...kind of filtering back?
Maybe the scope of CFMX projects I work on are too small or not as complex but yeah... using Beans, BO's and TO's for the sake of them existing seems an awful waste.
On 8/30/05, Patrick McElhaney <[EMAIL PROTECTED]> wrote:
On 8/29/05, Brian Kotek <[EMAIL PROTECTED]> wrote:
> If the question is only asked internally then there's no problem. The
> issue I was driving at is when you need to communicate with other
> people. If my definition of transfer object is different from your
> definition of transfer object, then at best we have to stop to get our
> definitions in line, and at worst we will think we're talking about
> the same thing when in reality we aren't.
My definition of "transfer object" is "Data Transfer Object," on page
401 of Martin Fowler's Patterns of Enterprise Architecture. It's a
popular book often referenced on this list.
I know a "business object" when I see one, but don't know of any good
defintions. I think the concept of "business object" is too abstract
to be classified as a pattern, anyway.
A "bean" used to be a JavaBean, as defined by Sun. It wasn't a
pattern. It was a set of conventions. Then they created Enterprise
JavaBeans, which I understand don't have much in common with
JavaBeans. I don't what "bean" means outside of Java.
As I've said before, when you mention a pattern name in front of a
large group (like this list) you should always tie it to a formal
definiton that's accessible to everyone in the group. (Exception: I
think we can assume that GoF book is the authoritative source for all
of the patterns it describes.)
Patrick
--
Patrick McElhaney
704.560.9117
http://pmcelhaney.weblogs.us
----------------------------------------------------------
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]
--
Regards,
Scott Barnes
http://www.mossyblog.com ----------------------------------------------------------
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]
