DAO Fusion overview

Building, testing and maintaining Data Access Object layers in applications can be basically done in two ways:

  • let the developers build up all the boilerplate code and configuration (which is, hopefully, easy to maintain in the long run) along with proper integration tests
  • use a comprehensive and well-tested library that handles all these tasks for you, saving you time and resources and letting you focus on the actual business logic

Choose your way

DAO Fusion aims to help Java developers build their server-side DAO layers with ease, doing most of the usual heavy lifting and providing support for common DAO-related tasks and patterns.

DAO Fusion overview

DAO Fusion introduces conventions and best practices into DAO layer development in terms of a consistent and extensible persistent entity model and standard DAO interfaces / abstract implementations which already provide most of the usual DAO functionality. DAO Fusion defines a generic and extensible entity criteria API that covers most typical use cases while taking care of Hibernate specific issues at the same time.

DAO Fusion supports applications with loose coupling between the client and server via the criteria transfer object pattern, which helps when building complex client-side data components that use filtering, sorting and paging functionality. The bitemporal pattern, on the other hand, helps to add temporal aspects to domain models in order to track data in time.

Last but not least, DAO Fusion provides an out-of-the-box integration test support that ensures proper test coverage of core DAO functionality and enables you to write your own custom integration tests for the chosen database at the same time.

How it all started

DAO Fusion results from an effort to unify the concept of a DAO layer across projects based on Java platform. DAO Fusion evolved from a simple DAO library to its present state thanks to people who realized the benefits of such solution in long-term horizon. Should we decide to stick with plain-old JPA / Hibernate together with some simple DAO abstractions, we would most probably end up with code that is hard to change and test later, bound to Hibernate specifics and quirks, not even mentioning that other Java projects did the same thing while repeating same old patterns.

For developers, adopting DAO Fusion might be an overhead since they can go straight with JPA / Hibernate in their applications anyway. However, in the long run, it's a different story.

Open source - why not?

The fact that DAO Fusion went open source after its initial release was a natural step in its evolution. After all, what's the real benefit of having such library hidden inside a company with a couple of people responsible for its maintenance and further development?

Open source projects involve many people collaborating together to build a software that is useful to each and every community member, and that's the value DAO Fusion aims to achieve.