Here is another thought (not mine - 'scuse the blunt language!) on "DAO design pattern isn't" from the thread: http://www.theserverside.com/news/thread.tss?thread_id=25695#120732
<snip/>
Well, in my book it's OK to put business logic in your persistent beans. It's not OK to put data access code in them. That is, beans should not know how to store and retrieve themselves from persisten storage. That's the realm of DAOs, or whatever you want to call them.
But let me just repeat what I wrote before:
In the end, it depends on how much complex your use case is.
Or, in other words, "do the simplest thing that might possibly work" (Kent Beck) and refactor it to something more general if and when the need arises. If you have simple needs, use the simplest solution.
If you have complex needs, use the simplest solution that is compatible with your needs. For instance, if you need to distribute your data access, logic and presentation tiers across different machines for scalability, your best bet would probably be to use EJBs, which would hide most of the complexity inherent in such a scenario.
At the other end of the spectrum, your needs might be satisfied by a transparent, low overhead, persistence mechanism like Prevayler (http://prevayler.org). After all, not every application needs an SQL database.
Ugo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
