Difference between revisions of "Persistence unified"
(→Code samples) |
(→Code samples) |
||
Line 32: | Line 32: | ||
No external calls to C macros, just plain Eiffel should be used to implement the framework | No external calls to C macros, just plain Eiffel should be used to implement the framework | ||
==Code samples== | ==Code samples== | ||
− | Here is a link to the [[persistence code samples]] page where you can have a look at some code. | + | Here is a link to the [[persistence code samples]] page where you can have a look at some code. |
− | + | ||
− | + | ||
==Additional tasks== | ==Additional tasks== | ||
===Which name?=== | ===Which name?=== | ||
Find an appropriate name for the framework is of course absolutely fundamental. It seems fair that anyone interested could provide one or more names within a certain period of time. After that a poll may be created to determine the winner. A first proposal could be EIUNPE which stands for EIffel UNified PErsistence. | Find an appropriate name for the framework is of course absolutely fundamental. It seems fair that anyone interested could provide one or more names within a certain period of time. After that a poll may be created to determine the winner. A first proposal could be EIUNPE which stands for EIffel UNified PErsistence. |
Revision as of 06:32, 18 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 by removing all the unnecessary complexity it should be very easy to use for an Eiffel newcomer.
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 by 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.
Pure Eiffel
No external calls to C macros, just plain Eiffel should be used to implement the framework
Code samples
Here is a link to the persistence code samples page where you can have a look at some code.
Additional tasks
Which name?
Find an appropriate name for the framework is of course absolutely fundamental. It seems fair that anyone interested could provide one or more names within a certain period of time. After that a poll may be created to determine the winner. A first proposal could be EIUNPE which stands for EIffel UNified PErsistence.