Kommentare zu: The DAO is dead! Long live the DAO!

Von: Oliver Gierke

Oliver Gierke — Wed, 17 Feb 2010 15:12:14 +0000

Good point! I am actually entirely with you when it comes to question look for solutions to solve the problem in a more elegant way. So the benefits I’ve pointed out were meant to be the driver to use a DAO instead of throwing all your query logic into a service, it was not meant the other way round. Although I’m really fond of what already exists in the .NET space regarding LINQ and hope to see something similar in Java, I’m wonder if that wil revolutionize the way we access data to the extend you describe. I see a clear benefit in integrating the querying into the host language I still see benefits in separating the declartion of what to query from the actual usage of the data. So IMHO hiding the declarative stuff behind a simple interface method is not much more than naming a query and then using it in a type safe manner by its name, which addresses the SOC mentioned in the original post.

Anyway, thanks for your thought!
Ollie

Von: Alex

Alex — Wed, 17 Feb 2010 14:48:35 +0000

If JPA didn’t kill the DAO, Linq is going to kill it. It’s just happen that query constructions is now part of the object oriented languages, despite the old school software eng. people efforts to ignore it and put everything in standard operations and message interchange. As OO languages are departing from the pure OO world, it may be time to rethink the OO design, don’t you think ?
Tik, Tak, Tik, Tak, DAO’s death is a question of time: and in my opinion, I just hate to write “one more class” to do what could be automatic (and was automatic in the forgotten PL/SQL time languages). It’s google time: I want to query the machine ;)

Von: Oliver Gierke

Oliver Gierke — Sun, 13 Sep 2009 09:27:28 +0000

Hey Rogério,

I tend to disagree as the sentence you quote does not even mention the term “domain object”. Thus IMHO “specific” means pretty much “database specific operations”. The reason I come to this conclusion is the question why anyone would bind functionality specific (meaning tightly bound) to the domain object to a separate concept interface? The DAO’s responsibility is to encode *persistence specific* aspects to not bother the domain objects with functionality not related to its core responsibilities.

As the article moves on wih a second sentence you also quote here it should become clear, that having a 1:1 relationship between a DAO and a domain object is not strictly necessary. As I understand the paragraph this just describes that the interface of a DAO is equiped with domain types and its purpose: hiding database (or perstistence technology related) specifics from clients unsing it.

Regards,
Ollie

Von: Rogério Liesenfeld

Rogério Liesenfeld — Sat, 12 Sep 2009 14:48:36 +0000

Oliver, you have misunderstood the wikipedia article on DAO.
Specifically, the part where it says “…, providing some specific operations …”.
The word “specific” in this context means operations specific to individual domain entities, not general-purpose operations like “persist(o)” or “remove(o)” that can be called for any domain object “o”.

This is stated more clearly in the parts that say “… domain-specific objects and data types (the public interface of the DAO), …” and “… specific DBMS, database schema, etc. (the implementation of the DAO)”.

Von: magomarcelo

magomarcelo — Thu, 05 Feb 2009 11:29:39 +0000

I find Hades really interesting, but what about existing domain classes where I cannot implement a given interface like Persistable? Is ther a solution to have them not depending on Hades maybe using AOP?

Von: Oliver Gierke

Oliver Gierke — Wed, 21 Jan 2009 09:19:25 +0000

@Lava – you have to be registered to create new forum posts. There should be link on the upper right corner where you can do this. Once you’ve registered, you should see a link saying “Create new post” or something like that. Hope that helps out. Feel free to contact me directly, if you have questions.

@snoobab – I second that entirely. The problem actually results from the habit to place business logic that is actually tied to the domain objects into services, which in case can be worked around by simply accessing the DAO or repository. As Hades can not enforce the domain driven design of entities we chose DAO as term. Repository would imply a domain driven view too much. Don’t get me wrong – I really like to leverage DDD. But we do not want to imply guidance that we do not give actually ;).

Ollie

Von: snoobab

snoobab — Wed, 21 Jan 2009 08:48:03 +0000

@Oliver: Yes agree that you can view DAO as Repository. The problem is that generally people don’t follow the other ‘good’ principles referred to in DDD in that typically business rules are implicitly coded into the DAO’s and there isn’t an over-arching thought process such as Aggregate pattern.

What therefore tends to happen is that new developers to a particular project will search for any DAO, instantiate the factory and start obtaining data, which may completely bypass any constraints or business rules.

Cheers
snoobab

Von: Lava Kafle

Lava Kafle — Wed, 21 Jan 2009 03:58:31 +0000

I did not see any forums on Hades site that you linked.

Von: Clinton Lee

Clinton Lee — Tue, 20 Jan 2009 22:51:49 +0000

I agree, DAO layers need to still exist despite these ORM technologies. We had JDO in my companies application abstracted away via a DAO. When our JDO vendor was failing our requirements, we decided to (for a number of technical and feature reasons) switch over to a JPA vendor. We probably spent just as much time, if not more, in research and estimation than actually coding over to JPA. We then came in way under time and budget… There is no way we could have done this in such time without our persistence being abstracted into a DAO.

Yesterday it was JDO, today it’s JPA, who knows what tomorrow will bring? (db4o anyone?) So even though these are common interfaces, at times the common interfaces change.

Von: Oliver Gierke

Oliver Gierke — Tue, 20 Jan 2009 21:10:16 +0000

@snoobab – Thanks for your comment. DAO is widely regarded as synonym for Eric Evans’ Repository. So I do think, too. By creating a technology neutral interface for a DAO you actually take the step from a database abstraction towards a repository for entities.

Regards,
Ollie