ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: DAO Objects - Hiding ?
Date Fri, 22 Jul 2005 03:25:33 GMT
Wow. what a fantastic list of DAO resources. Wiki anyone?

Clinton


On 7/21/05, Eric Blue <ericblue76@gmail.com> wrote:
> 
> 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