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
datasource?
----- Original Message -----
From: "Steve Webb" <[EMAIL PROTECTED]>
To: <[email protected]>
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.
