Skip to end of metadata
Go to start of metadata

What is grepo?

The Generic Repository (grepo) is an open source (ASLv2) framework for Java which allows you to access (database) repositories in a generic and consistent manner. Using grepo, it is generally no longer required to provide all the boilerplate code which is necessary in order to access (database) repositories from Java. All you have to do is write appropriate database code (queries, procedures, functions etc.), an appropriately annotated Java interface, and very little Spring configuration. Using the framework has the following advantages:

  • Improves development time because no implementations are required for data access objects (DAOs).
  • Simplifies development and increases code quality - you won't hear your colleague say "Hey look, what I've found - I guess this is not the way we do this normally?!" anymore.
  • Makes your data access layer consistent - similar/equal data access operations are "implemented" (and thus work) in the same way which in turn makes software more stable and in general better maintainable.


The Generic Repository Framework (grepo) has its origins back in 2007. I started development after reading Per Mellqvist's article "Don't repeat the DAO". My employer BearingPoint INFONOVA GmbH develops and maintains various business applications for its customers (mainly telecom providers). The software is developed/extended by various development (scrum) teams. Even though we have a professional development environment (using professional/good tools and frameworks etc...) and development guidelines (detailed coding conventions etc...) it turned out that the data access layers in our software products got quite fragmented, inconsistent and bloated - mainly because of big development teams and large software products, the typicall daily project-stress and the always reoccoring (similar) boilerplate code for database access logic. So we started developing a framework which in turn was tuned and improved in order to achieve the following main goals for our software products:

  • Ensure coding conventions and guidelines.
  • Avoid boilerplate code for database access logic.
  • Improve development time and code quality.

Finally we came up with a framework based on Spring and Hibernate. The framework is integrated in our software products for quite a while right now and is used for basically (at least about 90%) all new database related access objects. We are quite happy with the result and thus we decided to make it open source - and so the Generic Repository project was born.


The main goals of the framework are:

  • Simplicity - The framework should be easy to use and understand - grepo was designed around the convention over configuration paradigm.
  • Flexibility - The framework should be flexible enough, so it can be used for most database access specific tasks - grepo is easily configurable and extensible in order to fit custom/special needs.
  • Consistency - The framework should assist in building consistent data access layers - grepo allows to define and configure rules and guidelines (coding conventions etc...) for the data access objects. Those rules are then applied and enforced by the framework - grepo has a predefined (default) set of rules which may be customized for custom/special needs.


The main features of the framework are:

  • generic support for Hibernate based DAOs
  • generic support for Jpa based DAOs
  • generic support for executing database stored-procedures and function
  • highly customizable


The framework consists of the following main components:

Generic Query (gquery)

The "Generic Query" component allows to access databases using SQL queries. Currently the following ORM (Object Relational Mapping) tools/APIs are supported:

  • Native Hibernate API
  • Java Persistence API

The gquery component defines a set of (default) rules for repositories which may be customized/extended for custom/special needs. The framework provides default implementations for both "read-only" and "read-write" repositories which may be used for basic CRUD operations. However its up to you to provide your own implementation(s) if desired. Furthermore gquery offers the possibility to define and execute various queries (SQL, HQL, JPQL) and DAO methods without requiring custom implementations.

Generic Procedure (gprocedure)

The "Generic Procedure" component allows to access databases using PLSQL (that is calling stored procedures and/or functions) without requiring custom implementations - gprocedure is build on top of the Spring (JDBC) framework.

Generic Statistics (gstatistics)

The "Generic Statistics" component allows to collect runtime statistics of software layers. The component is easily extensible in order to fit custom needs. The gquery and gprocedure components provide out of the box support to collect statistics for dao layer(s) using this component. Because of its extensibility collecting statistics is not only limited to class methods but can also be used to track entire business processes and the like.

  • No labels