To be clear, a Bean is an object with getters and setters for its properties. That's it. Anything that follows that convention is a Bean.
That said, the majority of the time when people say "Bean" they mean "Business Object", meaning an object that represents a single domain entity in their model. Since Services (aka Managers) are almost always stateless, these would very rarely be Beans. I think I may formulate a blog entry on these terms because it still seems like there is some confusion. I really think we need to settle the terms down because without a common set of definitions for these things, a big part of any discussion is just figuring out what people are actually talking about. Robert, yes, if your Bean is nothing but a collection of properties with no behavior (a "dumb Bean") then it may very well be adding nothing but overhead. You're gaining very little from using them. The point of OOP is that your objects have data *and behavior*, with behavior being the far more important aspect. Without behavior, a Bean is basically a slower version of a structure. I'm not sure how you're generating your code but you may want to reconsider. If you're just ending up with an isolated "silo" of data and related objects, you're probably not gaining much from this approach. So if you have a LineItemDAO, a LineItemBean, a LineItemService, and a LineItemGateway, all just to deal with a LineItem database table, and none of these have any behavior and do nothing but store properties and persist those properties into a database, you've basically got a ton of overhead that isn't buying you anything. All this really cuts to the heart of the issue that seems to be popping up more and more frequently, which is that basing a domain model on a database schema is almost always a bad idea. On Feb 13, 2008 8:33 AM, Tom Chiverton <[EMAIL PROTECTED]> wrote: > > Depends what you mean by 'bean'. > If by 'bean' you mean some sort of service/manager tier, that at some > stage or > level of abstraction is going to have logging or security applied to it, > yes, > you should create a bean, even if a lot of the methods just map directly > to > the underlying DAO. > It'll also help if/when the DAO interface changes (Reactor to Transfer, as > an > example). > > -- > Tom Chiverton > Helping to interactively exploit eigth-generation communities > on: http://thefalken.livejournal.com > > **************************************************** > > This email is sent for and on behalf of Halliwells LLP. > > Halliwells LLP is a limited liability partnership registered in England > and Wales under registered number OC307980 whose registered office address > is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. > A list of members is available for inspection at the registered office. Any > reference to a partner in relation to Halliwells LLP means a member of > Halliwells LLP. Regulated by The Solicitors Regulation Authority. > > CONFIDENTIALITY > > This email is intended only for the use of the addressee named above and > may be confidential or legally privileged. If you are not the addressee you > must not read it and must not use any information contained in nor copy it > nor inform any person other than Halliwells LLP or the addressee of its > existence or contents. If you have received this email in error please > delete it and notify Halliwells LLP IT Department on 0870 365 2500. > > For more information about Halliwells LLP visit www.halliwells.com. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
