On Fri, May 18, 2012 at 6:33 AM, Tibor Mlynarik
<[email protected]> wrote:
> hmm, and isn't the only reason to convert entity into value to be able
> to serialize it (to JSON) ?
> For what else is good such transform ?
> I can see reason could be that after uow has completed entities are
> unusable. But what is rationale behind this behaviour ? When I want to
> develop 3-tier system now, I have to use only values on client/UI
> tier.
Ok, so first of all, in 1.x, one were not allowed to have Associations
at all in ValueComposites, so this discussion could not even surface
back then. Marc wrote the DCI sample against the 1.4 codebase, and the
DTOs there are simply necessary.
In 2.0, we are adding support for Associations in Values, and now
comes the semantic nightmare, which you are starting to touch on. This
was the default in the ORM world, and IMHO it is not very well solved
there either...
> I think that value serialization should have different schematics than
> entities.
> To serialize entity one should be able to specify graph depth,
> similarly as fetch plan. Cycles should be supported and repeated
> entities should be serialized by internal refs.
I think "Fetch plan" is a leaking SQL abstraction, and doesn't belong.
So the current behavior of ValueComposites are simple and straight
forward; An Association is to a Entity, referenced by Identity and if
traversed the current UoW will be used to retrieve it.
Now, that is very easy to describe (and to make work).
You are suggesting (I think), that if we introduce Entity->Value (via
JSON or not), that the Association is automatically traversed and that
the internal Identity reference is replaced with the serialized (or
Value of) referenced entity. And as most of us knows, the "depth"
becomes an issue, as do circular references and possibly many other
edge cases.
Another possible solution, which may be conceptually simpler, is to introduce
save(OutputStream out);
load( InputStream in );
on UnitOfWork.
The "depth" and circular references issues goes away; The client code
is responsible to traverse the needed graph, which loads the entities
in the UoW, and can easily be serialized. If an Association is
traversed after the UoW has been loaded on client side, but doesn't
exist, then simply a EntityNotFoundException will be thrown. Easy to
explain, easy to document, and relatively easy to implement with no
new concepts introduced.
But, since all of this is surfacing in 2.0, I think it is necessary to
have a deep discussion on this topic. Glad you brought it up.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
