About Designing DAO
[113 byte] By [dave123a] at [2007-10-3 0:25:00] 
will it be better if i use creational pattern (Abstract Factory pattern) to implement DAO?DuffyMo ?
> will it be better if i use creational pattern
> (Abstract Factory pattern) to implement DAO?
>
> DuffyMo ?
I'm not duffy, but I'll have a go anyway...
Yes
The DAO pattern is used to isolate the business layer from persistence responsibilities, among which knowing where the data comes from. If you instantiate your DAO directly in your business code, you're coupling it to the DAO implementation (technology, vendor, etc)
Torajiroua at 2007-7-14 17:17:21 >
thanks "Tora" for the reply.
i was thinking about using the Abstract factory pattern in design DAO.
I know that DAO implementation should be isolated from the Business Layer thats why there is lots of framework(hibernate, Oracle Toplink, Entity Bean etc) are being developed. My problem is to develop a small appication where i can't use these framework, since the application is not that big. So i'm decided that i'm going to develop my own DAO. Allthough i'm comfortable with hibernate, ejb etc.
In the next post i'll show you the design, since i does not have time right now.
ANY Way Thanks for the reply.
dave123a at 2007-7-14 17:17:21 >
Actually those frameworks do not serve to isolate your DAO from your business layer. They serve to map your DAO onto a datastore so that you don't have to. Isolation is an additional issue of its own. Dont forget about JDO. Excellent ORM with free implementation in JPOX.org. I like its system better than Hibernate.
Your on the right track for sure. I would recommend that you do not create your own ORM but instead use one of these. Even with a small application, you have the same problems to solve. Its a good exercise if its for learning. But you will find over time that as you learn more you need to add more code and it ends up being not so small. My JDBC implementation is in fact larger than my JPOX/JDO implementation and its still not nearly as robust...
_dnoyeBa at 2007-7-14 17:17:21 >
"_dnoyeb"
I like the advice of yours. actually i was wondering when the appication becomes bigger then i'm aspecting then i should have to use these ORM technology.
I never tried the JDO. I heard about JDO or you can say i read the JDO specification.
Can you give me some pointers to compare these technologies ?
Again thanks.
dave123a at 2007-7-14 17:17:21 >
> Actually those frameworks do not serve to isolate
> your DAO from your business layer.
Right, it can't isolate the DAO from the business layer. After all, it has to create those business objects. It has to know about them somehow.
But it does isolate the persistence layer from the business layer. If there are no references to the persistence layer in the business layer, then you've accomplished it.
Funny thing about coupling - you can never drive it to zero without making the class useless to anybody.
>They serve to map
> your DAO onto a datastore so that you don't have to.
> Isolation is an additional issue of its own. Dont
> forget about JDO. Excellent ORM with free
> implementation in JPOX.org. I like its system
> better than Hibernate.
>
> Your on the right track for sure. I would recommend
> that you do not create your own ORM but instead use
> one of these. Even with a small application, you
> have the same problems to solve. Its a good exercise
> if its for learning. But you will find over time
> that as you learn more you need to add more code and
> it ends up being not so small. My JDBC
> implementation is in fact larger than my JPOX/JDO
> implementation and its still not nearly as robust...
I agree that you should not create your own ORM. There are so many choices for persistence these days: Hibernate, iBatis, JDO, the new JPA (might want to look into that). Pick one, don't write your own.
%
duffymoa at 2007-7-14 17:17:21 >
> will it be better if i use creational pattern
> (Abstract Factory pattern) to implement DAO?
>
> DuffyMo ?
Hi dave123,
I'm not a Factory fan in this case. The important thing is an interface for the DAO.
I'm using Spring a lot these days, so I'm not in favor of Factories. I prefer dependency injection.
%
duffymoa at 2007-7-14 17:17:21 >
> > Actually those frameworks do not serve to isolate
> > your DAO from your business layer.
>
> Right, it can't isolate the DAO from the business
> layer. After all, it has to create those business
> objects. It has to know about them somehow.
>
> But it does isolate the persistence layer from the
> business layer. If there are no references to the
> persistence layer in the business layer, then you've
> accomplished it.
>
They isolate the persistence layer from the DAO layer.
JDO/hibernate and the classes that you create to manage the ORM is the persistence layer. The DAO sits on top of the persistence layer and manipulates the JDO/hibernate objects. The business layer in turn manipulates the DAO objects.
Having a small application is even more reason to choose an existing ORM. Else you will find that the ORM layer you create is larger than your whole application.
JDO is a compile time technology. It will alter your class files (with a 2nd compile tool) by adding hidden methods to do the reconciling with the database. So at runtime its seamless and hidden mostly. JDO is a standard with several implementations. I use the free one called jpox.org.
Hibernate is a runtime technology. It alters your objects at runtime to accomplish the same thing. (I havent used hibernate yet but this is what I am told) Hibernate is one organization and one implementation, but more widely adopted and used currently.
I use essentially the abstract factory pattern for my DAO layer. And a factory pattern for my persistence layer. I'm not familiar with "dependency injection."
_dnoyeBa at 2007-7-14 17:17:21 >
> They isolate the persistence layer from the DAO layer.
I think persistence == DAO. What else is DAO for?
> JDO/hibernate and the classes that you create to
> manage the ORM is the persistence layer. The DAO
> sits on top of the persistence layer and manipulates
> the JDO/hibernate objects. The business layer in
> turn manipulates the DAO objects.
No, JDO and Hibernate are technologies you can use to implement DAOs. DAOs usually start life as interfaces. But I consider the interfaces and their implementations together to comprise the persistence layer.
The service or business layer instantiates DAOs and domain objects to implement the use cases.
> Having a small application is even more reason to
> choose an existing ORM. Else you will find that the
> ORM layer you create is larger than your whole
> application.
Not necessarily so.
> JDO is a compile time technology. It will alter your
> class files (with a 2nd compile tool) by adding
> hidden methods to do the reconciling with the
> database. So at runtime its seamless and hidden
> mostly. JDO is a standard with several
> implementations. I use the free one called
> jpox.org.
"compile time" == byte code modifications. That's what some people don't like about JDO.
> Hibernate is a runtime technology. It alters your
> objects at runtime
No, Hibernate does not alter byte code. That's one of its selling points.
> to accomplish the same thing. (I
> havent used hibernate yet but this is what I am told)
You need better sources.
> Hibernate is one organization and one
> implementation, but more widely adopted and used
> currently.
>
>
> I use essentially the abstract factory pattern for my
> DAO layer. And a factory pattern for my persistence
> layer. I'm not familiar with "dependency injection."
You should learn about DI. It's important these days.
http://www.martinfowler.com/articles/injection.html
%
duffymoa at 2007-7-14 17:17:21 >
> > They isolate the persistence layer from the DAO
> layer.
>
> I think persistence == DAO. What else is DAO for?
>
hehe, yes. Now you are confusing me. The JDO/Hibernate provides ORM that can be used as your persistence layer. I don't think of these tools as DAOs themselves. They are used by your DAOs to provide the persistence. Your DAO "layers" job is to hide all the implementation details of the ORM from the business layer. You would not want your ORM objects manipulated by your business layer, though I know this is how they all like to market themselves.
> > JDO/hibernate and the classes that you create to
> > manage the ORM is the persistence layer. The DAO
> > sits on top of the persistence layer and
> manipulates
> > the JDO/hibernate objects. The business layer in
> > turn manipulates the DAO objects.
>
> No, JDO and Hibernate are technologies you can use to
> implement DAOs. DAOs usually start life as
> interfaces. But I consider the interfaces and their
> implementations together to comprise the persistence
> layer.
>
OK. However, I have seperated this into two seperate packages. The DAO objects and the ORM objects they manipulate. You are welcome to unify these and this is how these ORMs advertise themselves to be used.
The DAOs change as the interfaces for them change. The JDO classes change as I decide to go with a different database structure. This made my life simpler as I am the only developer. This also happened because I copied the DAOs from a seperate project and retrofitted in the JDO classes :D
It was easier to know everything in one class was dedicated to JDO. That meant I didn't have to maintain a mental picture of the two duties the 'DAOs' would perform.
I might change once things stabilize.
> The service or business layer instantiates DAOs and
> domain objects to implement the use cases.
>
> > Having a small application is even more reason to
> > choose an existing ORM. Else you will find that
> the
> > ORM layer you create is larger than your whole
> > application.
>
> Not necessarily so.
>
No, but the smaller the application the more likely this is the case. ORM is not a simple thing though you can create access to a database simply.
_dnoyeBa at 2007-7-14 17:17:21 >
> > I use essentially the abstract factory pattern for
> my
> > DAO layer. And a factory pattern for my
> persistence
> > layer. I'm not familiar with "dependency
> injection."
>
> You should learn about DI. It's important these
> days.
>
> http://www.martinfowler.com/articles/injection.html
>
> %
Thanks for that link. I read the article and it sparked some interesting thoughts.
Actually, I am using OSGI through Eclipse to locate the factory implementation. So its a 'service locator' pattern. The user (or admin) chooses at runtime (initial setup) from a selection of implementations. From then on that factory is automatically attached to a certain project. All DAOs from a given implementation are obtained through that factory. So its not the DAO layer that is obtained through the factory, that comes from a service locator.
Also this choice happens at runtime so DI will not really fit.
The one thing I will likely do is isolate the service locator a bit more so that subsequent uses of the service closely mimmic dependency injection (with respect to a particular package/bundle). That should make unit testing a bit easier whenever I get around to that.
Message was edited by:
_dnoyeB
_dnoyeBa at 2007-7-14 17:17:21 >
> > > I use essentially the abstract factory pattern
> for
> > my
> > > DAO layer. And a factory pattern for my
> > persistence
> > > layer. I'm not familiar with "dependency
> > injection."
> >
> > You should learn about DI. It's important these
> > days.
> >
> >
> http://www.martinfowler.com/articles/injection.html
> >
> > %
>
> Thanks for that link. I read the article and it
> sparked some interesting thoughts.
>
> Actually, I am using OSGI through Eclipse to locate
> the factory implementation. So its a 'service
> locator' pattern. The user (or admin) chooses at
> runtime (initial setup) from a selection of
> implementations. From then on that factory is
> automatically attached to a certain project. All
> DAOs from a given implementation are obtained through
> that factory. So its not the DAO layer that is
> obtained through the factory, that comes from a
service locator.
>
> Also this choice happens at runtime so DI will not
> really fit.
When do you think DI happens?
> The one thing I will likely do is isolate the service
> locator a bit more so that subsequent uses of the
> service closely mimmic dependency injection (with
> respect to a particular package/bundle).
Right, if you understand DI you can do it on your own. More work, though.
> That should
> make unit testing a bit easier whenever I get around
> to that.
You'll have to have the container running to test. That'll be harder.
%
duffymoa at 2007-7-14 17:17:21 >
> > > They isolate the persistence layer from the DAO
> > layer.
> >
> > I think persistence == DAO. What else is DAO for?
> >
>
> hehe, yes. Now you are confusing me. The
> JDO/Hibernate provides ORM that can be used as your
> persistence layer. I don't think of these tools as
> DAOs themselves. They are used by your DAOs to
> provide the persistence.
The DAOs are interfaces, so they have to have an implementation in order to do anything. The implementations, be they Hibernate or JDO or JPA, are in the same packages, so yes, they are part of persistence.
> Your DAO "layers" job is to
> hide all the implementation details of the ORM from
> the business layer. You would not want your ORM
> objects manipulated by your business layer, though I
> know this is how they all like to market themselves.
No they don't.
> OK. However, I have seperated this into two seperate packages.
I have the interfaces in a package named "persistence", and implementations as packages under those (e.g., "hibernate", "jdo", etc.) They're all still under "persistence".
> The DAO objects and the ORM objects they
> manipulate. You are welcome to unify these and this
> is how these ORMs advertise themselves to be used.
What is this advertising that you're reading? Please post a link.
> The DAOs change as the interfaces for them change.
Since the implementations implement the interfaces, yes they have to change. But you should find that those are VERY stable.
> The JDO classes change as I decide to go with a
> different database structure.
Not necessarily, unless you mean adding or removing columns from a table and associated attributes from an object. That's the whole point - the database is now isolated from the objects.
> This made my life
> simpler as I am the only developer. This also
> happened because I copied the DAOs from a seperate
> project and retrofitted in the JDO classes :D
You duplicated code? You didn't include it as a 3rd party JAR? Ever heard of the DRY principle? You just violated it.
> It was easier to know everything in one class was
> dedicated to JDO. That meant I didn't have to
> maintain a mental picture of the two duties the
> 'DAOs' would perform.
>
> I might change once things stabilize.
> No, but the smaller the application the more likely
> this is the case. ORM is not a simple thing though
> you can create access to a database simply.
I think mapping 1:1, 1:m, and m:n relationships isn't that difficult. Things like inheritance can be tricky.
I'm betting that you haven't done enough with ORM to judge.
%
duffymoa at 2007-7-14 17:17:21 >
> Also this choice happens at runtime so DI will not
> really fit.
>
> When do you think DI happens?
>
Well to be fair its all relative. One package looks up the dependency and another receives the injection. This is the same no matter if you are using so-called dependency injection or service locator.
The major facet of my program is that the dependency can not be known until runtime. (relative to the package in question)
> > The one thing I will likely do is isolate the
> service
> > locator a bit more so that subsequent uses of the
> > service closely mimmic dependency injection (with
> > respect to a particular package/bundle).
>
> Right, if you understand DI you can do it on your
> own. More work, though.
>
more work than what?
> > That should
> > make unit testing a bit easier whenever I get
> around
> > to that.
>
> You'll have to have the container running to test.
> That'll be harder.
>
> %
What container? I don't use spring or any such thing. I don't have any containers.
_dnoyeBa at 2007-7-14 17:17:21 >
> Well to be fair its all relative. One package looks
> up the dependency and another receives the injection.
> This is the same no matter if you are using
> so-called dependency injection or service locator.
But in one case you need a Java EE container running and in the other you don't.
> The major facet of my program is that the dependency
> can not be known until runtime. (relative to the
> package in question)
You don't know what implementation you need for the PersonDAO?
> > Right, if you understand DI you can do it on your
> > own. More work, though.
> >
>
> more work than what?
More work to do DI without a DI engine.
> What container? I don't use spring or any such
> thing. I don't have any containers.
No Java EE container? No servlet/JSP engine? No Tomcat, no WebLogic? It's a desktop app?
%
duffymoa at 2007-7-14 17:17:21 >
My Way
Package A-Business
Contains DAO interfaces
Package B-DAO
Implements DAO interfaces, uses JDO objects
Package C-Persistence
JDO objects and handlers
or Advertised way
Package A-Business
Contains DAO interfaces
Package B-DAO/Persistence
implements DAO interfaces right on JDO objects
Either way works. Both ways share the same dependencies. However, with my way I can isolate any and all persistence code in the package with the persistence handling objects. It seems like a nice division for me. Its similar to the question about composition vs. inheritance.
> > The JDO classes change as I decide to go with a
> > different database structure.
>
> Not necessarily, unless you mean adding or removing
> columns from a table and associated attributes from
> an object. That's the whole point - the database is
> now isolated from the objects.
This is the whole point. The database is isolated from which objects? Its not isolated from the JDO objects because the JDO objects fully understand the database schema and must in order to read/write to/from the database tables.
>
> > This made my life
> > simpler as I am the only developer. This also
> > happened because I copied the DAOs from a seperate
> > project and retrofitted in the JDO classes :D
>
> You duplicated code? You didn't include it as a 3rd
> party JAR? Ever heard of the DRY principle? You
> just violated it.
>
Not really. It was easy to copy and paste in the DAOs. But in fact, the original DAOs used JDBC, they were modified to use JDO. They needed to implement the same interfaces and have generally the same methods so it was an easy starting point. These two sets of DAOs are not similar anymore.
Ill do this again when I make my hibernate implementaiton. There is a much larger chance the hibernate DAOs will end up looking a lot like the JDO DAOs in which case I will unify them.
>
> > No, but the smaller the application the more
> likely
> > this is the case. ORM is not a simple thing
> though
> > you can create access to a database simply.
>
> I think mapping 1:1, 1:m, and m:n relationships isn't
> that difficult. Things like inheritance can be
> tricky.
>
> I'm betting that you haven't done enough with ORM to
> judge.
>
> %
You would loose that bet.
I been working with JDO for about 2 years now. I been doing my JDBC implementation probably 7 years. So I saw first had how to deal with it directly in SQL, then I saw what JDO had to offer.The difficulty comes in managing transactions and implementing rollback strategies and cacheing. The relationships too are tricky with inheritance 1:1 1:n etc. Then when the schema changes for JDBC I have to put on my DBA hat. I have to tinker with SQl and with objects. With JDO I can keep thinking in terms of objects moreso.
Implementing my DAOs in JDBC vs. JDO is about the same amount of hand coding.
_dnoyeBa at 2007-7-21 9:05:59 >
Sorry, dbnoye, I'm not following where you're getting this "advertised way". Who's way is it?
Here's how I think about it:
package service - contains service interfaces and implementations
package model - contains domain objects
package persistence - contains DAO interfaces and implementations
Note: Nothing about persistence in any layer above it.
>
> Either way works. Both ways share the same
> dependencies. However, with my way I can isolate any
> and all persistence code in the package with the
> persistence handling objects. It seems like a nice
> division for me. Its similar to the question about
> composition vs. inheritance.
No, I don't agree. It's not similar to composition vs. inheritance in my mind.
> This is the whole point. The database is isolated
> from which objects? Its not isolated from the JDO
> objects because the JDO objects fully understand the
> database schema and must in order to read/write
> to/from the database tables.
Obviously. But they should be isolated from the business objects. That's where the isolation comes in.
> Not really. It was easy to copy and paste in the DAOs.
Easy, but cut & paste can be fraught with error. Duplicating code in two places to access the same tables? I'd think about a common JAR, separate from both projects.
> But in fact, the original DAOs used JDBC, they
> were modified to use JDO. They needed to implement
> the same interfaces and have generally the same
> methods so it was an easy starting point. These two
> sets of DAOs are not similar anymore.
Different DAO implementations is fine. The key thing is that the interface doesn't change.
>
> Ill do this again when I make my hibernate
> implementaiton. There is a much larger chance the
> hibernate DAOs will end up looking a lot like the JDO
> DAOs in which case I will unify them.
Not sure why you need Hibernate if you've got JDO experience that's happy.
> You would loose that bet.
When I say ORM, I mean Hibernate. JDBC is not ORM. I'm not so familiar with JDO, so if you tell me that it's ORM, then I'll take that on faith.
> I been working with JDO for about 2 years now. I
> been doing my JDBC implementation probably 7 years.
> So I saw first had how to deal with it directly in
> SQL, then I saw what JDO had to offer.The
> difficulty comes in managing transactions and
> implementing rollback strategies and cacheing.
That's exactly what Spring's declarative transactions and Hibernate's caching and lazy loading do for you. Tricky, indeed, if you try to do it on your own.
> The
> relationships too are tricky with inheritance 1:1
> 1:n etc. Then when the schema changes for JDBC I
> have to put on my DBA hat. I have to tinker with
> SQl and with objects. With JDO I can keep thinking
> in terms of objects moreso.
>
> Implementing my DAOs in JDBC vs. JDO is about the
> same amount of hand coding.
Then why bother with JDO?
%
duffymoa at 2007-7-21 9:05:59 >
> Here's how I think about it:
>
> > package service - contains service interfaces and
> implementations
> package model - contains domain objects
> package persistence - contains DAO interfaces and
> implementations
>
>
> Note: Nothing about persistence in any layer above
> it.
I agree with this.
>
> >
> > Either way works. Both ways share the same
> > dependencies. However, with my way I can isolate
> any
> > and all persistence code in the package with the
> > persistence handling objects. It seems like a
> nice
> > division for me. Its similar to the question
> about
> > composition vs. inheritance.
>
> No, I don't agree. It's not similar to composition
> vs. inheritance in my mind.
>
I know. since you consider the whole DAO as the persistence layer you wont be concerned. This is fair. For me I subdivide my DAOs into the persistence part and the dao implementing part, but its still presented to the rest of the world through the DAO layer as a single layer. I did this subdivision with my JDO implementation but not with my JDBC implementation.
> >
> > Ill do this again when I make my hibernate
> > implementaiton. There is a much larger chance the
> > hibernate DAOs will end up looking a lot like the
> JDO
> > DAOs in which case I will unify them.
>
> Not sure why you need Hibernate if you've got JDO
> experience that's happy.
I do it to learn Hibernate.
>
> > You would loose that bet.
>
> When I say ORM, I mean Hibernate. JDBC is not ORM.
> I'm not so familiar with JDO, so if you tell me that
> it's ORM, then I'll take that on faith.
>
JDO is ORM. You can use JDBC to create your own ORM which is what I did. Or perhaps lets say I used JDBC to implement the DAOs since I did not create an actual general ORM library out of it.
> > I been working with JDO for about 2 years now. I
> > been doing my JDBC implementation probably 7
> years.
> > So I saw first had how to deal with it directly in
> > SQL, then I saw what JDO had to offer.The
> > difficulty comes in managing transactions and
> > implementing rollback strategies and cacheing.
>
> That's exactly what Spring's declarative transactions
> and Hibernate's caching and lazy loading do for you.
> Tricky, indeed, if you try to do it on your own.
>
> > The
> > relationships too are tricky with inheritance 1:1
> > 1:n etc. Then when the schema changes for JDBC I
> > have to put on my DBA hat. I have to tinker with
> > SQl and with objects. With JDO I can keep
> thinking
> > in terms of objects moreso.
> >
> > Implementing my DAOs in JDBC vs. JDO is about the
> > same amount of hand coding.
>
> Then why bother with JDO?
>
> %
Maybe I wasn't fair. With JDO I get a lot more features and manageability. Basically everything you expect to get when you use ORM over plain SQL.
_dnoyeBa at 2007-7-21 9:05:59 >
Other Topics New Topic
Other Topics Hot Topic
Other Topics
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding