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
