I think that's actually a completely irrelevant issue. Whether or not it should will depend entirely on the circumstances, the application, the existing codebase if any, etc. The real question is this: What are the implications (if any) of having a bean that's able to persist itself and why would they matter? What impact could such a design decision have on my application or on my model?
Things like this: If a bean is to be self-persisting, then composition with other beans in the model can become incredibly complicated very quickly without something like Transfer or Reactor providing the sort of cacadeSave() functionality that Transfer implements. So having a bean save or load itself can become very complicated without a service, which can actually simplify a complex process while it makes your archictecture a bit more complicated. There's a lot more to say but I gotta run (I'm already way behind this morning), but there's nothing like a chance to pontificate first thing in the day! ;) I am liking this conversation... let's keep it going! Laterz, J On Dec 23, 2008, at 5:24 AM, Alan Livie wrote: > I suppose the question again pops up 'Should a bean know how to > persist itself or should this not be the bean's concern' but this > has been debated and debated and there's no right or wrong answers, > just opinions! > > I don't think its a problem having services with some intelligence, > ie doing some logging (forget AOP for now!), managing transactions, > persistence, notifying users when things happen etc. I guess this > can be called Application Logic. > > Its only when the Business Logic starts creeping into services (ie > something like calculatePay() ), you start getting into the 'anemic > domain model' issues and responsibilities living outside the > objects that should have them (ie the bean/business object) > > Alan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
