DAO Fusion versus other DAO libraries

[Vojtech Szocs]

I have started a brief research recently, searching for alternative
Java-based DAO pattern implementations and comparing them to what DAO
Fusion currently offers.

I try to focus my attention to the following criteria:

1) how rich is the standard set of DAO operations provided out of the
box
2) support of complex domain model design (how much code do I need to
write for different types of entities)
3) query / search API robustness and possible pitfalls (how domain
model changes affect entity query consistency)
4) integration test support, which covers core and custom DAO
functionality
5) extra features that are handy or simply interesting

[Suresh Sanjeev Rashid]

Are there any results of your research? This is interesting for me as
we decide to use this project thanks

[Vojtech Szocs]

Yes, I have some rough notes written down but since we are busy now I
didn't have time to put them here. My initial comparison was with
Hades as Hussachai mentioned this OpenSource library in his post. Here
are my notes so far - they are, however, not categorized using
criteria outlined above.

I've taken a quick look at Hades (http://trac.synyx.org/hades/wiki).
Here are my thoughts - a comparison against DAO Fusion, taken mostly
from "hades-reference.pdf". This is not meant to say that one library
is better than the other one, it's just my point of view on some of
their aspects.

Persistent entity model - compare PersistentEntity interface hierarchy
for both libraries (I am wondering why Hades chose to include method
such as isNew() to an entity interface since the underlying entity
state handling is managed by Hibernate anyway)
- DF Persistable interface gives you hints how to implement object
identity, hashCode/equals implementation options, inheritance
mappings, etc.
- DF users don't have to repeat code such as @Id Long id / getId() /
setId() since this is handled by PersistentEntity which is essentially
a @MappedSuperclass
- DF features support for mutable/immutable entities (mutable with
optimistic locking support)
- DF features PersistentEnumeration useful for enumerated types to be
persisted into database

Standard DAO functionality
- DF's PersistentEntityDao allows you to have one DAO for many
entities that share a common parent entity (e.g. a common DAO for
persistent enumerations)
- DF has a sophisticated persistent entity criteria API, see
PersistentEntityCriteria and related classes, note that this criteria
API is object-oriented, in contrast to AOP proxy magic / named queries
supported by Hades
- Hades' "read by example" logic (ExtendedGenericDao) is ultimately
implemented via Hibernate query-by-example, which works on direct
properties of persistent entities only
- Hades contains GenericDaoFactoryBean that creates dynamic proxies
(actual DAO implementations), so you just specify DAO interface,
custom business-specific DAO functionality integration is a little bit
cumbersome (I have to declare additional "MyDaoCustom" interface)
- Hades "finder methods" are quite restricted in their functionality,
because string-based NamedQueries are inefficient/unmanageable in long
term and dynamic finder method arguments (CREATE mode) work only on
direct entity properties only

Hades has an interesting auditability support (alternative approach to
AOP = use native Hibernate entity life cycle hooks). The custom Spring
namespace support is also very nice. However, DF does not force you to
use Spring, it focuses purely on JPA/Hibernate (Spring is required for
integration tests only).

I kind of missed following things in Hades:
- advanced query support (filtering entities by nested properties, for
example)
- integration test support, core integration tests to prove standard
DAO functionality on non-trivial sample domain for most popular
databases
- some discussion about hashCode/equals implementation alternatives,
object identity versus database identity, their pros and cons, etc.

To sum it up, Hades is nice and efficient library for smaller
projects, especially when you are familiar with writing named queries
(your domain model will get more complex as your application grows).
DAO Fusion, on the other hand, provides tools for building and testing
DAO layers for complex domain models - object-oriented criteria API
which shields you from Hibernate details, integration test support,
rich entity model / DAO functionality, Criteria Transfer Object (CTO)
pattern implementation, etc.

As mentioned above, each library has its own target domain and
specific features suitable for different styles of developing DAO
layers.

Vojtech

On Jun 10, 11:16 pm, Suresh Sanjeev Rashid <rashid...@gmail.com>
wrote:

[huss...@gmail.com]

Vojtech, Thank you for the good comparison. In fact, Hades is quite
very easy, I can learn it in one hour.
One thing that makes it easy is because it's simple. Nothing new to
learn (at least for me).
DAO fusion learning curve is more steeper than Hades. but I'm sure it
can handle the difficult situations
without breaking the initial design. I'm looking for the best practice
for the big project.
That is the reason why I'm waiting for DAO Fusion. Why wait ? Because
I can't run fast, I just can walk
step-by-step. The walk will start about the end of July or when the M2
finishes. :-)

Hussachai

[Vojtech Szocs]

Hi Hussachai :) thanks for your ideas, DAO Fusion is more complex than
Hades, but allows you to do lots of advanced stuff which is necessary
for big projects, which usually come with complicated domain models
(we are actually developing DAO Fusion based on requirements of one
big project that uses it for data access). One thing that you might
like about DAO Fusion is its object-oriented criteria API which
shields you from any Hibernate details and allows you to write quite
complex queries :-) I believe that having programmatic query API (even
Hibernate Criteria API) is much better (= much more maintainable) than
plain-old JPQL named queries. Imagine your data model changes in some
way (application always changes in time) - you must go through / test
all affected named queries. In DAO Fusion, if you stick to good
practice of externalizing entity properties as constants which you use
in your criteria, you get compile-time errors = much better than
possible hidden JPQL inconsistencies (which you discover only by
testing). On the other hand, if your database is already designed and
you have SQL guru by your side, named queries can be OK. For us, our
domain model evolved in time quite rapidly and I couldn't even imagine
if we had to write those complex JPQL queries.

For complexity - I think DF's entity model and core DAO classes /
interfaces are quite simple, only things which are more complex are
our criteria API and CTO pattern. I'm sure you can get familiar with
criteria API very soon - we plan to revise our ref docs to include
more examples so people can learn it much quicker. Also the promised
step-by-step tutorial for Hello DAO is on the way, unfortunately it's
not out yet because since we changed the API in M1 we must do tutorial
compliant with 1.2.0.

Igor is also working on the bitemporal pattern support, it's a very
interesting feature that allows you to add time information to your
entities (e.g. tracking some entity in time). There will be special
ref doc dedicated to bitemporal pattern - explanation how it works and
how to use it. So if you plan to have data model that requires to
track some data in time, bitemporal pattern is a very good solution.

By the way did you try out our Hello DAO app? If yes, what are your
thoughts? Optionally what do you think of changes in M1 (if you are
watching our changes)

Vojtech

[Vojtech Szocs]

I forgot to add one last note:) actually your first post (about the
roadmap) gave us lots of inspiration to continue our development. We
even considered possible JDO support (for example, you could take "JDO
Fusion" and deploy it on Google App Engine) but, the biggest challenge
is that JDO doesn't support true object-oriented criteria API. On the
other hand, JPA 2.0 will come with its own criteria API so we need to
be prepared for this one in any case.

Vojtech

[huss...@gmail.com]

Quote(Vojtech): "By the way did you try out our Hello DAO app? "
I checked out the example immediately after I received the news from
you via
this discussion board.
But unfortunately I cannot run it because it depends on 2 factors.
1) I didn't use maven before. I don't know how to run it from command
line.
It always show me the "ERROR".
2) I make the eclipse project from scratch and copy files that I was
checked it out to the source directory but I don't know about GWT
too.
If I have more time, I will try again with more patient.

For me, sometime test case is more familiar than the example. I always
learn
the framework/library when I can't understand the example or even run
it up.
I'm curious how can you test the library. I found only abstract class
no concrete test class provided.

Quote(Vojtech) "Optionally what do you think of changes in M1"
Good! this project is very active and the author has an open mind.
That was I think.
Recently week I'm quite very busy and I've no time for learning the
new thing.
That why I cannot tell you about the technical detail. I confess that
I don't understand it now.

To get it up and running, first thing I need to learn is Maven.

PS. Vojtech, I'd like to thank you for the good response and kindly
supports
my desire about roadmap.

Hussachai

[Vojtech Szocs]

Hi Hussachai,

I've created a quickstart guide for "Hello DAO" that explains all the
steps necessary to run the application and browse it in Eclipse IDE:
http://groups.google.com/group/dao-fusion/browse_thread/thread/c3a6304ef28fe02c

(Maven / Ant / Eclipse setup is included)

In future, we can put it on some page perhaps so that other people can
get started with all the necessary tools too.

As for tests, "Hello DAO" currently doesn't have custom DAO operations
(besides using standard ones) and hence no custom integration tests
which would cover these custom operations (DAO Fusion's core
functionality is already covered by core integration tests - look at
BaseHibernateCoreIntegrationTest and its subclasses to get an idea how
integration tests work in general). We will add some custom DAO
operations and tests to "Hello DAO" as well later :-)

Vojtech