Another approach is a load() method on a bean that takes a struct. That decouples it from being a controller concern as while the controller might pass in a specific struct (probably the form, url or some combination thereof), there are other use cases for loading a bean from a struct.
I've heard the "base classes shouldn't be used for sharing implementation code" before and while I understand the sentiment much as I generally agree with favor composition over inheritance, there are valid use cases for base classes providing standard, shared implementations. A business object (product, user, page, article, etc) very clearly IS A business object and a product DAO IS A DAO (and so on). I've found that having base DAO, service and business object classes (and a base controller) has worked extremely well for me. There are plenty of cases where overuse of inheritance or over reliance on base classes providing implementations (as opposed to composing objects which implement shared functionality) is a problem, but there is a reason why inheritance is overused - it is very powerful and useful. I think it's important not to give up on inheritance entirely (or limit yourself completely to abstract base classes). There are use cases, and for a lot of the repeated patterns I see in web applications it's actually a pretty powerful approach and one that has yet to give me any maintainability issues yet in the applications I've been developing. As always, your mileage may vary. Best Wishes, Peter On Jul 15, 2008, at 5:41 PM, Sean Corfield wrote: > > On Thu, Jul 10, 2008 at 7:32 AM, Brian Kotek <[EMAIL PROTECTED]> > wrote: >>> In the first example we're saying "Hey, take this form and populate >>> yourself with these values". >> >> Yes I would say that it is. There's no reason ask another object (the >> OrderService) to populate the Order object when you can just tell >> the Order >> object to populate itself. > > Just to clarify, since I think I was the one advocating using a > service here (I've certainly advocated it in discussions with folks > this last week or so)... > > If the populate() method is generic - it iterates over the collection > and calls matching setters - then it is not specific to a bean and > rather than have an artificial base class to contain such common code > (inheritance should not generally be used for sharing implementation > details), it is easier to put that common non-type-specific code in a > service. One copy of the code. > > Mach-II and Model-Glue take this approach by making such a method > available as part of the framework since it's a common task. > > Also, since this operation tends to happen when populating beans from > forms primarily, it feels "wrong" to me to have this in a bean - I'd > be more comfortable with it being in the controller layer somewhere > (again, as Mach-II and Model-Glue have it). > > Of course, there's no black and white "right" or "wrong" ways here and > there are tradeoffs in both approaches. > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
