Difference between revisions of "Persistence unified"
(→A tentative manifesto) |
|||
| Line 25: | Line 25: | ||
Classes which objects have to be persisted should not be polluted with persistence code, for example adding specific persistence-related attributes or by inhering from some other class that provides persistence services. | Classes which objects have to be persisted should not be polluted with persistence code, for example adding specific persistence-related attributes or by inhering from some other class that provides persistence services. | ||
| − | *The access to the persistence services should be as uniform as possible. This can be achieved using the XXX_MANAGER class hierarchy that handles access to specific kinds of persistence stores | + | *The access to the persistence services should be as uniform as possible. This can be achieved using the XXX_MANAGER class hierarchy that handles access to specific kinds of persistence stores. |
| − | *The different media should be properly incapsulated. This can be achieved using the XXX_MEDIUM class hierarchy | + | *The different media should be properly incapsulated. This can be achieved using the XXX_MEDIUM class hierarchy. |
| − | *The different formats should be properly incapsulated. This can be achieved using the XXX_FORMAT class hierarchy | + | *The different formats should be properly incapsulated. This can be achieved using the XXX_FORMAT class hierarchy. |
Revision as of 09:06, 17 August 2007
Contents
Unified persistence for Eiffel
This project is about developing a single, integrated and simple persistence framework for Eiffel.
- Single because nothing else should be needed to access any kind of persistence services.
- Integrated because aims at integrating both the already existing technologies and frameworks, as far as they deliver the intended benefits, and possibly new ones.
- Simple because it should be very easy to use, removing all the unnecessary complexity.
A tentative manifesto
The first proposed task is to agree upon a sort of ‘manifesto’ of desirable features for the framework.
Here is a first proposal:
Three abstractions
The framework should provide just three abstractions to the developer: PERSISTENCE_MEDIUM, PERSISTENCE_FORMAT and PERSISTENCE_MANAGER.
Possible specializations of these abstractions could be:
- FILE_MEDIUM, NETWORK_MEDIUM, RELATIONAL_DB_MEDIUM, CUSTOM_MEDIUM, ...
- BINARY_FORMAT, STRING_FORMAT, XML_FORMAT, DADL_FORMAT, CUSTOM_FORMAT, ...
- SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ...
Persistence independence
Classes which objects have to be persisted should not be polluted with persistence code, for example adding specific persistence-related attributes or by inhering from some other class that provides persistence services.
- The access to the persistence services should be as uniform as possible. This can be achieved using the XXX_MANAGER class hierarchy that handles access to specific kinds of persistence stores.
- The different media should be properly incapsulated. This can be achieved using the XXX_MEDIUM class hierarchy.
- The different formats should be properly incapsulated. This can be achieved using the XXX_FORMAT class hierarchy.
