ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Blue <ericblu...@gmail.com>
Subject Re: DAO Objects - Hiding ?
Date Thu, 21 Jul 2005 22:12:27 GMT
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.
> 
>

Mime
View raw message