TGLMAN

Primitive Boxing Problem

Hi All, I'm back with a new challenge to explain about one my project.
Like the previous post explain i'm working on this project (Object Query) to find a new way to write DBMS query directly in java.

So my idea is not so hard to implements until you are thinking in Object way, like almost all java think, but there are few things that in java are not object one of this are the primitives types, and this primitive types are common in an DDD domain that's mean if I'm not able to handle this problem my idea is died!

So now i have to start to think to a good solution:
What i've in my project is a pure java domain, and a proxy instance of a class of domain, so i can just start from this point to try to solve my problem.

Another start point for try to solve this problem is the java (from 1.5) behavior, that allow to to transfer primitive type values in an object way through code, wrapping it in an specific object(java.lang.Integer,java.lang.Long, ecc..) this is called boxing.

So i can try to create an my owned boxing object to use for handle primitive types, this i think is not hard just define an api that receive primitive type and return an object that represent the path of primitive type call. with a code like this:
	Object primitiveBoxed = query.box(proxy.getHome().getWeight());
Ok I can solve my problem, just because when i call the method getWeight on my proxy a create a fake value to associate to path "home.weight",
and the call box() i receive the previous value and from this value i can extract the associate path and after create a "Boxing" object with associate path.
after this operation i've an object with associate the path like a normal object.

So i found i way to solve the problem of primitive values .... and i just implemented it !!
wonderful!!
Done !!

DDD Query Way

In last few years I was lucky and I had the opportunity to work with some new and powerful java frameworks and with the newest software design approaches, and in particular I specialized in DDD (Domain Driven Design).
When you try to develop a software following DDD principles you need to use some frameworks that help you to thinking only to domain, example the ORM for the persistence or user interface generator for the user interaction.
Now I want focus on persistence because in my work experience I found some gap in the persistence frameworks.

Explain the gap:

if you are using java probably you want define all rules and all behavior of your domain using only java, and this is almost possible,

Just define a domain:

public class Person {
   private String name;
   private String surname;
   private Dog dog;
   //.... gets sets ...
}

public class Dog {
   private String name;
   //.... gets sets ...
}

And try to persist the domain(JPA api):

Person p = new Person();
p.setName("Name");
p.setDog(new Dog());

EntityManager manager=...
manager.persist(entity)

Ok you can do all CRUD(create read update delete) only with java, this is good!! but what happen if you try to search something??

"select * from Person where name=:name"

I have to use another SQL-like language (JPQL,JDOQL,HQL. etc...) this is not java ... not good.

The reasons why this is not good are many:

  • if you want refactoring your code you have to check all SQL-like everywhere
  • You can't check at compile time if something is wrong like types field names
  • have to learn another language
  • at least i broken my DDD principles ;)

Ok now we need something of different but before start an hard work I'll try to check on Internet if someone did it!

Yes i found it:

JPA type safe query
JDO type safe query
SQL type safe query

Yes good, someone(of big) have the same my problem and they try to solve it... but i don't like this kind of solution! you have to define manually or generate automatically another static class that expose a reflection of your domain end then if you change something you have to update it!

Ok ... Is my time ! I try find a better solution!

I worked with java for years and I had discovered there is three main way to write implementation independent code:

  • Statically with simple java interface(all know it)
  • Dynamicaly with reflection (almost all know it)
  • Dynamicaly with proxy (almost all use it, but just someone know it)
so the first solution is not for me because a can't force people to adapt to my interfaces, the second one is good but i need somthing of more powerful, proxy is your time ;)

usualy when we want execute a query in a DDD approch we want an object that describe the query, where we set the target of query the conditions and all we need:
	ObjectQuery<Person> query = new GenericObjectQuery<Person>(Person.class);
good this object can be the start of my proxy, just do it
	ObjectQuery<Person> query = new GenericObjectQuery<Person>();
	Person target = query.target();
	query.eq(target.getName(),"test");
Yeeeaaa I like it, and I have done it:ObjectQuery

But ... is not finished here .... to complete it I have to fix lot of problems... but this is another post ;)

Twitter:
tglman
Github:
tglman
SourceForge:
tglman
Ohloh:
tglman
Software:
www.tglman.org