Difference between revisions of "Persistence unified"

(A tentative manifesto)
(A tentative manifesto)
Line 13: Line 13:
 
Here is a first proposal:
 
Here is a first proposal:
  
*The framework should provide just three abstractions to the developer: PERSISTENCE_MEDIUM, PERSISTENCE_FORMAT and PERSISTENCE_MANAGER
+
====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:  
+
Possible specializations of these abstractions could be:  
  
-FILE_MEDIUM, NETWORK_MEDIUM, RELATIONAL_DB_MEDIUM, CUSTOM_MEDIUM,  
+
* FILE_MEDIUM, NETWORK_MEDIUM, RELATIONAL_DB_MEDIUM, CUSTOM_MEDIUM,  
  
-BINARY_FORMAT, STRING_FORMAT, XML_FORMAT, DADL_FORMAT, CUSTOM_FORMAT,
+
* BINARY_FORMAT, STRING_FORMAT, XML_FORMAT, DADL_FORMAT, CUSTOM_FORMAT,
  
-SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER
+
* 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
+
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 formats should be properly incapsulated. This can be achieved using the XXX_FORMAT class hierarchy

Revision as of 10:01, 17 August 2007

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 of 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