[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Re: Discussion - Framework v2 Roadmap



On 17 February 2015 at 19:48, klas berlič <klas.berlic AT gmail.com> wrote:
> Cache indeed needs storage to do its job, but it is not just that, it has
> numerous functions that come on top of storage the same with databases, you
> can't degrade them both just to storage, it's like you would say car is the
> same as engine.

That analogy isn't quite right. It's saying if you are designing a
car, choosing "which engine" is an implementation details, and all you
provide is an interface to the transmission and fuel system. And in
the process of design, you want to delay the decision of selecting
which engine you want to use for as long as possible (cf Clean or
Hexagonal Architecture).

So in terms of getting some data, my API should not care, initially,
or as far as my unit tests are concerned, whether data is coming from
a JSON file, canned data in memory, or a full blown instance of
Teradata with multiple caching layers.

The point is caching is an implementation detail but at it's heart
it's a type of storage. For example, a "find" method in a model should
connect to a single storage adapter. That adapter may choose to
implement a caching layer, but the model should not have to worry
about both a persistent storage layer and a caching layer (that's an
implementation detail it should not care about).

> Cache            >
> Database        >   Storage  >  Filesystem
> Session          >

Almost.

Project 1: Model -> Storage Interface > Filesystem
Project 2: Model -> Storage Interface > Database
Project 3: Model -> Storage Interface > Cache > Database (implements
CacheableDatabase)

The point is that the model is interchangable across projects, and is
very easy to test. But the base code for a, for example, Redis cache
should extend from StorageInterface is my point. It's just CRUD.

> One more suggestion for Input. This is more application stuff, but simple
> modification to implement bookkeeping of inputs requested trough API (from
> quick look it seems only method to return inputs array is needed) would
> create a base for auto id calculation for view cache in application,
> dropping the need for manually listing those safe parameters in display
> method.

On that one I think I'd start to follow Symfony's request and response
models (the Node Express package uses this pattern also).

Regards,
Andrew Eddie

-- 
Framework source code: https://github.com/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
--- 
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.