liip / dataaggregator
The data aggregator cumulates information provided by a loader and routes them to a persistence layer
Installs: 19 181
Dependents: 0
Suggesters: 1
Security: 0
Stars: 16
Watchers: 11
Forks: 5
Open Issues: 5
Requires
- beberlei/assert: >=1.5
- psr/log: ~1.0
Requires (Dev)
- lapistano/proxy-object: dev-master
- phpunit/phpunit: @stable
Suggests
- monolog/monolog: Allows more advanced logging of the application flow
This package is not auto-updated.
Last update: 2022-02-01 12:25:38 UTC
README
This bundle is no longer maintained. Feel free to fork it if needed.
Liip DataAggregator
Current Travis Status
Purpose
The DataAggregator provides a structured way to fetch/retrieve information form different sources, process this information, and to persist it even to several destinations at once. To be able to archive this it is build on a threefold of component types:
- the loader
- the aggregator
- the persistor
Furthermore the goal of this library is to be as small as it can be providing the most and simplest way to be extended and altered to ones' personal needs.
The managing component - the aggregator
The aggregator is the heart of the library. Since itself do not have any knowledge about the structure of the information shared between a loader and a persistor it takes care of the connection between those two and manages their interaction. Being a simple registry loaders and persistors get attached to it and run iteratively. Since it shall not have any knowledge about the transfer format it should not process nor alter the information it passes through.
The information fetching/retrieving component - the loader
The name already unveils to purpose of this component. It has all knowledge of how to extract information from a request or response. The source and format of the data is loader specific. Still following the idea of haveing a footprint as lean and small as possible the interface of a loader requires only two methods. One (load()) to actually extract the data from a response and a second (stopPropagation()) to notify the aggregator hat it might be a good idea to stop invoking every other reggistered loader. This might be the case when a loader was setup as a filter mechanism and the result being return is already empty.
The information storage - the persistor
The purpose of the persistor is to make the information retrieved from the aggregator permanently available. This also means that the loader and persistor must have the same idea about the information passed between them. Furthermore it is possible for the persistor to process the data to be stored.
Special flavors
Hybrid
Imagine an implementation acting towards a loader as an aggregator and towards an aggregator as a loader. This makes it possible to encapsulate a specific set of sources to one loader and provide the collected and probably already process information to the aggregator on the 1st level of your implementation. This makes it even easier to reuse loaders and persistors and should encourage you to follow all the nice oop principles out there (SOLID, DRY, ...).
Transformers
As the sketch shows the transformers are a more general approach to create a special transfer format (like e.g. a Doctrine entity) form the loaded data. This makes it much easier for an invoked persistor to do his work. Further a dedicated data validation can be introduced in the named transfer format.
Concept sketch
Installation
The source is now PSR-0 compatible. There is no specific installation routine to be followed. Just clone or checkout
the source into to your project and use it. In case you don't use a
PSR-0 compatible autoloader, you only have
to add the bootstrap.php
into your bootstrap or autoloader.
###Composer
Add the following lines to your composer.json
file and update your project's composer installation.
{ "require": { "liip/dataaggregator": "dev-master" } }
This composer configuration will checkout the 'cutting edge' version ('dev-master') of the project. Be alarmed that this might be broken sometimes.
NOTE: In case you do not know what this means the composer project website is a good place to start.
Github
Thus I recommend the composer way to make DataAggregator a dependency to your project. The sources are also available via github. Just clone it as you might be familiar with.
$ git clone git://github.com/liip/DataAggregator.git
Logging
This project does for different reasons favor Monolog for the logger of choice. Unfortunately Monolog does not implement the Psr\Log\LoggerInterface. Therefor an Adaptor was implemented to bring the two worlds together. So in case you want to use a monolog logger use the MonologAdaptor as dependency instead of monolog directly.
Update 2013-01-12: @gnutix brought to my attention that Monolog just added support for the Psr-3. This is actually good news, it soon will be possible to get rid of the formerly introduced MonoLogAdaptor. Kudos to everyone involved in that achievement.
Validation
The DataAggregator provides the base to introduce validation in to a loader, persistor and/or an entity (aka an instance of the class representing your transferred data).
Plain validator
The idea behind a validator is to verify constraints are met by a value of a variable. Therefore theu interface defines the »validate« method usually throwing an exception if any constraint is not met. In case a decision other than handling an exception is needed the »isValid« method shall return a boolean indicating the validation has been passed (true) or not (false).
Validator strategies
A strategy is a set of validators. Each of them bound to a specific type or classname a validation shall be invoked on.
Dependencies
- Assert (http://github.com/beberlei/assert)
Suggestions
- Monolog (https://github.com/Seldaek/monolog)