Difference between revisions of "Persistence unified"

(→‎A tentative manifesto)
Line 14: Line 14:
 
Many people have devoted considerable efforts to persistence in Eiffel. It is important to take advantage of their insights and tools, and not to reinvent what has already been devised. Please make sure you are familiar with the list on the [[:Category:Persistence|general persistence page]], and if you are familiar with a project not referenced there please add it.
 
Many people have devoted considerable efforts to persistence in Eiffel. It is important to take advantage of their insights and tools, and not to reinvent what has already been devised. Please make sure you are familiar with the list on the [[:Category:Persistence|general persistence page]], and if you are familiar with a project not referenced there please add it.
  
−
==A tentative manifesto==
+
==Design principles==
 
The first task is to agree on desirable features for PERSIST. Here is a first proposal:
 
The first task is to agree on desirable features for PERSIST. Here is a first proposal:
  
−
# Essential abstractions
+
# Design orthogonality
−
# Independence from persistence code
+
# Persistence uniformity
−
# Uniform access
+
 
# Encapsulation and extension
 
# Encapsulation and extension
 
# Pure Eiffel
 
# Pure Eiffel
 
# Newbie-proof
 
# Newbie-proof
 +
# Essential abstractions
  
 
You can find some details in the following paragraphs.  
 
You can find some details in the following paragraphs.  
 +
 +
===Design orthogonality===
 +
It should be possible to add persistence mechanisms to an application without affecting the other aspects of its design. Developers should not, for example, need to add persistence-related attributes, or require application classes to inherit from specific persistence classes.
 +
 +
 +
===Persistence uniformity===
 +
 +
There are many kinds of persistence medium, from plain files to relational databases, object-oriented databases and networks. Programmers using PERSIST should only have to take into account the properties of the persistence medium that they choose to consider. This means in particular that it must be possible to write a PERSIST application that will work with different persistence media.
 +
 +
===Extendibility===
 +
It should be possible to add new kinds of persistence medium. (For a possible approach see XXX_FORMAT classes below.)
 +
 +
===Pure Eiffel===
 +
No external calls to C macros, just plain Eiffel should be used to implement the framework
 +
 +
===Newbie-proof===
 +
Ideally the programmer should only create the desired manager object and invoke the features to store or retrieve an object  passing the object itself as an argument.
  
 
===Essential abstractions===
 
===Essential abstractions===
Line 40: Line 57:
 
* BINARY_SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ...
 
* BINARY_SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ...
  
−
===Independence from persistence code===
 
−
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.
 
−
 
−
===Uniform access===
 
−
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.
 
−
 
−
===Encapsulation and extension===
 
−
The different media should be properly incapsulated and the same time there should be place for extensions. This can be achieved using the XXX_MEDIUM class hierarchy.
 
−
 
−
The different formats should be properly incapsulated and the same time there should be place for extensions. 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
 
−
 
−
===Newbie-proof===
 
−
Ideally the programmer should only create the desired manager object and invoke the features to store or retrieve an object  passing the object itself as an argument.
 
  
 
==Diagrams and code samples==
 
==Diagrams and code samples==

Revision as of 15:11, 26 August 2007

Unified persistence for Eiffel

(Temporary name: PERSIST.)

The PERSIST project is about developing a single, integrated and simple persistence framework for Eiffel:

  • Single: PERSIST should remove the need for any more specific solution such as serialization, object-relational interfaces, interfaces to object-oriented databases, all of which become functionalities of PERSIST.
  • Integrated: PERSIST should integrate existing mechanisms and add new ones as needed, in a consistent framework.
  • Simple: PERSIST should hide all unnecessary complexity from programmers; in Alan Kay's words, easy things should be easy and difficult things should possible.

Community input is expressly sought to help PERSIST achieve these goals.

Existing persistence mechanisms

Many people have devoted considerable efforts to persistence in Eiffel. It is important to take advantage of their insights and tools, and not to reinvent what has already been devised. Please make sure you are familiar with the list on the general persistence page, and if you are familiar with a project not referenced there please add it.

Design principles

The first task is to agree on desirable features for PERSIST. Here is a first proposal:

  1. Design orthogonality
  2. Persistence uniformity
  3. Encapsulation and extension
  4. Pure Eiffel
  5. Newbie-proof
  6. Essential abstractions

You can find some details in the following paragraphs.

Design orthogonality

It should be possible to add persistence mechanisms to an application without affecting the other aspects of its design. Developers should not, for example, need to add persistence-related attributes, or require application classes to inherit from specific persistence classes.


Persistence uniformity

There are many kinds of persistence medium, from plain files to relational databases, object-oriented databases and networks. Programmers using PERSIST should only have to take into account the properties of the persistence medium that they choose to consider. This means in particular that it must be possible to write a PERSIST application that will work with different persistence media.

Extendibility

It should be possible to add new kinds of persistence medium. (For a possible approach see XXX_FORMAT classes below.)

Pure Eiffel

No external calls to C macros, just plain Eiffel should be used to implement the framework

Newbie-proof

Ideally the programmer should only create the desired manager object and invoke the features to store or retrieve an object passing the object itself as an argument.

Essential abstractions

It should be possible to develop most persistence-aware applications based on knowledge of just three abstractions:

  • PERSISTENCE_MEDIUM, covering the kind of medium onto which objects are mapped; it should be possible to work with a very abstract view of such a medium, or, if desired, to take advantage of more specific properties.
  • PERSISTENCE_FORMAT, controlling the mapping between object properties and their outside representation.
  • PERSISTENCE_MANAGER: control object to specify modalities of writing and reading, and find out how the operations actually occurred.

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, ...
  • BINARY_SERIALIZATION_MANAGER, RDBMS_MANAGER, CUSTOM_MANAGER, ...


Diagrams and code samples

Here is a link to the persistence code samples page where you can have a look at some code and a class diagram.

Open discussion

For an open discussion on the design choices please have a look at the persistence framework design discussion.

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.

Contacts

  • Marco Piccioni
  • Bertrand Meyer
Retrieved from "https://dev.eiffel.com/index.php?title=Persistence_unified&oldid=9597"