ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zarar Siddiqi" <zarar.sidd...@utoronto.ca>
Subject Re: DAO Objects - Hiding ?
Date Thu, 21 Jul 2005 19:28:10 GMT
I'm not too sure what you're getting at.  Are you suggesting that it's OK to 
have a method called "update" or "create" inside your POJO which accesses a 

----- Original Message ----- 
From: "Steve Webb" <Steve.Webb@Phones4u.co.uk>
To: <user-java@ibatis.apache.org>
Sent: Thursday, July 21, 2005 7:26 AM
Subject: DAO Objects - Hiding ?

> 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.

View raw message