Kripton ORM: reusable generic base DAO interface

Abubusoft Blog

Kripton ORM: reusable generic base DAO interface

This post was inspired by the following question from StackOverflow: Reusable generic base class DAOs with Android Room. I reuse the original question and I try to approach the problem with Kripton.

Room’s approach avoids using an ancestor interface for DAO interface to define for the SELECT operations. A parent DAO interface can be used only to define operationINSERT/UPDATE/DELETE but no SELECT operation. The reason is that Room Library allows defining queries specifying all the SQL code. In the StackOverflow question, the model that the developer want to solve is:

public interface BaseDao<T> {
 
  @Insert
  void insert(T object);
 
  @Update
  void update(T object);
 
  @Query("SELECT * FROM #{T} WHERE id = :id")
  void findAll(int id);
 
  @Delete
  void delete(T object);
 
}
 
// DAO interface foo
public interface FooDao extends BaseDao<FooObject> { ... }
 
// DAO interface bar
public interface BarDao extends BaseDao<BarEntity> { ... }

With Kripton, life is better.

Question: is there any way to create reusable generic base interface DAOs with Kripton?

The answer is YES. It’s possible to define SELECTINSERTUPDATE and DELETE operation on a generic parent interface.  Let’s take the previous question and previous model and see them in Kripton context. Translating model into Kripton style we obtain:

public interface BaseDAO<E> {
 
    @BindSqlSelect(where = "id=${work.id}")
    List<E> selectById(@BindSqlParam("work") E bean);
 
    @BindSqlInsert
    public void insertThread1(E bean);
 
    @BindSqlUpdate(where = "id=${work.id}")
    public boolean update(@BindSqlParam("work") E bean);
 
    @BindSqlDelete(where = "id=${work.id}")
    public boolean delete(@BindSqlParam("work") E bean);
}

And the derived DAO interfaces:

// Dao interface Foo
public interface FooDao extends BaseDao<FooObject> { ... }
 
// Dao interface Bar
public interface BarDao extends BaseDao<BarEntity> { ... }

Why Kripton allows us to do these? The answer is simple: because Kripton allows defining a query in explicit mode, specifying all the SQL or in compact mode, specifying only the necessary SQL part. Given a specific DAO interface, Kripton already knows that the interface is associated to a specific POJO and every operation that will be done on it (it is also possible to go beyond this, but this is not the situation). So… if we know that a SELECT work on a TABLE, which is the part of the query that we really need? The WHERE conditions!!!

@BindSqlSelect(where = "id=${work.id}")
List<E> selectById(@BindSqlParam("work") E bean);

This fact allows to bring commons method SELECTUPDATEINSERT and DELETE defined in a compact model to a base DAO interface.

For any question don’t hesitate to comment on this post.

For more information about how to define SQL method in Kripton, you can also read this post and this mini-guide on Kripton ORM.

For more information about Kripton Persistence Library:

Happy coding!

xcesco


 

Leave a Reply

Your email address will not be published. Required fields are marked *