Comments on: Rethinking the traditional DAO pattern

By: Andy

Andy — Tue, 08 Jul 2008 14:55:00 +0000

Wow, Kenrick– that’s a slick idea! I need to explore method injection more as its a powerful technique in Spring that is similar to a lot of the MOP features you get in Groovy. Thanks for pointing that out, man!

By: Kenrick Chien

Kenrick Chien — Tue, 08 Jul 2008 14:17:57 +0000

Interesting idea, to put CRUD logic in the domain object/POJO. Adding to what James said, you could use “lookup method injection” (see section 3.3.8.1 at http://static.springframework.org/spring/docs/2.0.x/reference/beans.html) anytime you wanted your POJO, and have Spring manage the DAO dependency by injecting it, instead of looking it up statically.
This way, if you’re using the full Spring stack, your beans would all be wired when your container starts up and
the domain object could be easily unit tested by mocking out the DAO interface w/EasyMock, JMock, etc.

Thanks for sharing this idea.

By: rails 2 0 oracle

rails 2 0 oracle — Sat, 05 Jul 2008 11:45:29 +0000

[...] resource??s hip client interface from its data access mechanisms??? meaning that clients to a partichttp://thediscoblog.com/2008/06/17/rethinking-the-traditional-dao-pattern/scroll down to read an excerpt from this article - ACM QueueTune in to learn how oracle plans to [...]

By: Software Development

Software Development — Mon, 30 Jun 2008 09:09:19 +0000

hey

Really nice tips!

will try to keep it in my mind

thanks!

By: DZone weekly links #3 | Sergi Castillo

DZone weekly links #3 | Sergi Castillo — Sun, 29 Jun 2008 07:19:32 +0000

[...] Rethinking the traditional DAO pattern [...]

By: Andy

Andy — Wed, 25 Jun 2008 20:53:56 +0000

Stephan- you are correct– my approach does make testing a bit more challenging– so long as your domain objects remain simple bean-like objects though, do you really need to unit test them? That is, don’t they only hold true meaning when they are wired to some data store? I’m thinking that integration-like tests are more realistic for domain objects; consequently, I don’t mind too much that to work with these objects, as I’ve coded them, I need to have a live database.

You raise great points– thanks for sharing! And thanks for the pointer to Qi4J! This is interesting stuff!

By: Stephan Schmidt

Stephan Schmidt — Tue, 24 Jun 2008 20:56:44 +0000

I still like and use Dao objects. Folding the Dao into the Domain object combines two concerns, reduced reusability, makes testing more difficult and is harder to maintain.

From my point of view, every class should satisfy one concern, not several ones. Perhaps that’s the reason I like ideas like Qi4J for it’s composite oriented programming.

Peace
-stephan

By: Andy

Andy — Wed, 18 Jun 2008 12:49:07 +0000

James- I didn’t consider the aspect approach, but I think it’s an excellent idea!

By: James

James — Wed, 18 Jun 2008 12:41:32 +0000

Thanks for sharing your approach.
Perhaps you’ve considered this, but I think spring could wire your domain object with aspectJ or loadtimeweaving, instead of the static code to find or load the spring context.

By: smith mountain lake | Hottags

smith mountain lake | Hottags — Wed, 18 Jun 2008 06:11:59 +0000

[...] Rethinking the traditional DAO patternscenario "the domain object should faciliate creating new instances", { given "a new race is created", { new Race("SML 10K", new Date(), 6.2, "race the hills of Smith Mountain lake").create() } then "the domain class should actually …The Disco Blog - http://thediscoblog.com pay per click advertising [...]