Steve,

If I understand your question correctly, it seems that you want the POJO to know how to persist itself.  This certainly is one way to do it, however I would probably advise against it.  If I recall, one of Scott Ambler's books (The Object Primer, 2nd edition) detailed an architecture similar to this where the POJO implemented a Persistable interface (which had basic CRUD methods). 

One problem with this approach (among many others) is that since you have no business delegate/service layer/DAO, you don't have real extensible control over who can create/retrieve/update/delete the data (authentication and authorization).  For example, you may want to allow you web application to save Account POJOs, but not if they are instantitated from a CLI or Windows client.

I stuggled with this same question a while ago.  When you have time, here are some sites and articles worth reading that are related to DAOs and DTOs.  Some have a wider scope that what your looking for, but are still worth looking at.

Data Access Object (DAO) J2EE Pattern
        http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Transfer Object (DTO) J2EE Pattern
        http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

Pattern Problem
       http://forum.java.sun.com/thread.jspa?threadID=569418&tstart=225

General Design with BO's, DTO's and DAO's
        http://forum.java.sun.com/thread.jspa?threadID=582832&tstart=134

Using BeanUtils to avoid duplication between DTOs and BOs
        http://www.javaranch.com/newsletter/July2003/TouringTheCommonsPart1.html

DAO Generator
        http://titaniclinux.net/daogen/

DAO Examples
        http://daoexamples.sourceforge.net/

One big Service class or several small classes?
        http://www.theserverside.com/news/thread.tss?thread_id=23705

Custom-Grained Data Transfer Objects
        http://www.practicalsoftwarearchitect.com/articles/customgrained/customgrained.html

Dynamically generate DTOs with DynaBeans
        http://www.javaranch.com/newsletter/200404/Commons_Part3.html







On 7/21/05, Steve Webb <Steve.Webb@phones4u.co.uk> wrote:
Before acting on this e-mail or opening any attachments you are advised to read
The Caudwell Holdings group of companies' disclaimer at the end of this e-mail.
=======================================================

Hi there,

I'm new to iBatis so excuse my lack of knowledge. I am currently looking at modifying an exisitng J2SE Swing application so that it uses iBatis/Spring  for DB access rather than user JDBC directly. I have read the info on the iBatis site and also had a read about the DAO pattern for J2EE (  http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html ). I am unsure why my application (problem) logic should know about both my POJO and the DAO associated with it. I would have thought my application would just need to know about the POJO object and that would hide the details of the DAO behind the scene. In effect my POJO would have its normal get/set methods plus methods associated with persistence such as update, create, getNext .......

If anyone could point me to something that could clear my mental block about this or explain why what I'm advocating is wrong I'd be most grateful.

Cheers

Steve Webb



=======================================================
Confidentiality Notice
This e-mail is confidential and intended for the use of the named recipient only.  If you are not the intended recipient please notify us by telephone immediately on +44(0)1782 600600 or return it to us by e-mail.  Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of The Caudwell Holdings group of companies.

Encryptions and Viruses
Please note that this e-mail and any attachments have not been encrypted.  They may therefore be liable to be compromised.  Please also note that it is your responsibility to scan this e-mail and any attachments for viruses.  We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Monitoring
Activity and use of The Caudwell Holdings group of companies' systems is monitored to secure its effective use and operation and for other lawful business purposes.  Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes.