Hi Rickard,
I'm not using uow.apply() at all so I can surely live without it :)
Paul
Le 16 avr. 2010 à 04:54, Rickard Öberg <[email protected]> a
écrit :
Hi guys,
I have been reading an excellent book called "80/20 Principle" by
Richard Koch. The basic idea behind 80/20 is that "20% of input
gives 80% of output", and the rest of the book is examples of
applying that.
This idea applies a lot in software I think. His argument is that
usually 20% of functionality is used 80% of the time. Apple software
is a prime example, where they instead of having all sorts of
functionality cut down on features, but make them really good and
yet they contribute to most uses of the software.
In thinking about this for API design, it seems to be similar: 20%
of an API is used 80% of the time, so focus on that 20% being really
easy to use. The part of the API that is used all the time in Qi4j
apps (or at least it's what I'm seeing), is the UnitOfWork API. But
part of the UoW API, and the implementation, feels unnecessarily
complicated due to the apply() method, which I still haven't quite
figured what the semantics of is to be honest. Internally the
support for "apply()" makes it quite a bit more difficult to
implement EntityStores, as they have to allow EntityStates to be
valid even after apply().
Since apply() can sort of be supported by implementing caching in
EntityStores instead, I would therefore suggest that we drop apply
(). This would also make UoW callbacks easier to understand, as the
semantics for what happens with apply() is a bit undefined.
Preferably I would want to make it as easy as possible to implement
EntityStores for the new range of NOSQL-stores, and IMO dropping
apply() would help with that.
WDYT?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
