Steve,
If I understand your question correctly, it seems that you want the POJO to=
=20
know how to persist itself. This certainly is one way to do it, however I=
=20
would probably advise against it. If I recall, one of Scott Ambler's books=
=20
(The Object Primer, 2nd edition) detailed an architecture similar to this=
=20
where the POJO implemented a Persistable interface (which had basic CRUD=20
methods).=20
One problem with this approach (among many others) is that since you have n=
o=20
business delegate/service layer/DAO, you don't have real extensible control=
=20
over who can create/retrieve/update/delete the data (authentication and=20
authorization). For example, you may want to allow you web application to=
=20
save Account POJOs, but not if they are instantitated from a CLI or Windows=
=20
client.
I stuggled with this same question a while ago. When you have time, here ar=
e=20
some sites and articles worth reading that are related to DAOs and DTOs.=20
Some have a wider scope that what your looking for, but are still worth=20
looking at.
Data Access Object (DAO) J2EE Pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.h=
tml
Transfer Object (DTO) J2EE Pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.htm=
l
Pattern Problem
http://forum.java.sun.com/thread.jspa?threadID=3D569418&tstart=3D225
General Design with BO's, DTO's and DAO's
http://forum.java.sun.com/thread.jspa?threadID=3D582832&tstart=3D134
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=3D23705
Custom-Grained Data Transfer Objects
http://www.practicalsoftwarearchitect.com/articles/customgrained/customgrai=
ned.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:
>=20
> Before acting on this e-mail or opening any attachments you are advised t=
o=20
> read
> The Caudwell Holdings group of companies' disclaimer at the end of this=
=20
> e-mail.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>=20
> Hi there,
>=20
> I'm new to iBatis so excuse my lack of knowledge. I am currently looking=
=20
> at modifying an exisitng J2SE Swing application so that it uses=20
> iBatis/Spring for DB access rather than user JDBC directly. I have read t=
he=20
> info on the iBatis site and also had a read about the DAO pattern for J2E=
E (=20
>=20
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject=
.html). I am unsure why my application (problem) logic should know about bo=
th my=20
> POJO and the DAO associated with it. I would have thought my application=
=20
> would just need to know about the POJO object and that would hide the=20
> details of the DAO behind the scene. In effect my POJO would have its nor=
mal=20
> get/set methods plus methods associated with persistence such as update,=
=20
> create, getNext .......
>=20
> If anyone could point me to something that could clear my mental block=20
> about this or explain why what I'm advocating is wrong I'd be most gratef=
ul.
>=20
> Cheers
>=20
> Steve Webb
>=20
>=20
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> Confidentiality Notice
> This e-mail is confidential and intended for the use of the named=20
> recipient only. If you are not the intended recipient please notify us by=
=20
> telephone immediately on +44(0)1782 600600 or return it to us by e-mail.=
=20
> Please then delete it from your system and note that any use, disseminati=
on,=20
> forwarding, printing or copying is strictly prohibited. Any views or=20
> opinions are solely those of the author and do not necessarily represent=
=20
> those of The Caudwell Holdings group of companies.
>=20
> Encryptions and Viruses
> Please note that this e-mail and any attachments have not been encrypted.=
=20
> They may therefore be liable to be compromised. Please also note that it =
is=20
> your responsibility to scan this e-mail and any attachments for viruses. =
We=20
> do not, to the extent permitted by law, accept any liability (whether in=
=20
> contract, negligence or otherwise) for any virus infection and/or externa=
l=20
> compromise of security and/or confidentiality in relation to transmission=
s=20
> sent by e-mail.
>=20
> Monitoring
> Activity and use of The Caudwell Holdings group of companies' systems is=
=20
> monitored to secure its effective use and operation and for other lawful=
=20
> business purposes. Communications using these systems will also be monito=
red=20
> and may be recorded to secure effective use and operation and for other=
=20
> lawful business purposes.
>=20
>
|