Do you really need of the a database? Know the XPrevail.

What it is prevalence?

The prevalence concept originally was idealized by the Brazilian Klaus Wuestefeld and materialized in the project Prevayler, an implementation in Java. It is an union of old separately applied concepts already in other scenes.

As I mentioned in the summary, the use of the prevalence is an alternative to the use of database. With it, all the business-objects are persisted in the memory and have guarantee of that they will be recouped faithful in case that has some fall of energy or fails in the application. Amongst the main prevalence use advantages I can cite:

     - The great profit of performance for query's;
     - The drastic reduction of costs of a solution (it eliminates costs of serving pair here the database (the hardware), licenses of the 
       serving software of data base, operational cost of maintenance and etc);
     - Induces a development truily objects oriented (in the my most interesting opinion).

It does not leave to visit the section " What it is?" in the site of XPrevail project.

Key concepts 

To understand the functioning general of the prevalence is important that before let us know some terms comumente used inside of this concept, of this form, let us see to follow the main ones of them.

PrevalenceEngine : One is about an prevalence framework's class, that is responsible for all the execution proceeding, it register and backup of the alterations carried through in the PrevalentSystem . Many times we referenciamos it simply as " engine ". We will see more ahead than the XPrevail  make available four type of different engines , each one with its particularitities. 

PrevalentSystem : A class defined for the user who must to reference all the business objects of the application, or either, the objects that will be persisted. The objects referenceds ones will be serializeds when snapshot will be requested to PrevalenceEngine one. Of this form, any object is of this class will have its lost state. 

Snapshot : The PrevalenceEngine is the process in which serialize all the PrevalentSystem (in the reality we will see more ahead than the XPrevail supports the work with multiples PrevalentSystem 's), such which it is at the moment of the request. This gives to origin a new archive of snapshot, and becomes unnecessary the reading of the archives of log of previous operations. 

Operation : By the original concept considered by the prevalence, all alteration to be carried through in objects kept for a PrevalentSystem must be made through objects of class that implement the IOperation interface defined by framework. These instances are passed to the PrevalenceEngine for register and execution. In the prevayler project the interface equivalent is called Transaction . (to see in manifest more details). 

Prevalence execution flux 

To understand the concept better, I go to describe which now would be the flux of execution of a prevalent application. It imagines that let us have only one business class in one given application, the Client class . We go to the pacings to become this prevalent application. <o:p>

1. We need to define a class that will keep reference our Client objects , it it will be our PrevalentSystem and it could call Clients . <o:p>

2. We will have to declare a reference it PrevalenceEngine and to initialize it, moment in which will be demanded the information of which class will be the PrevalentSystem, of course must inform Clients . <o:p>

3. The initialization of the PrevalentSystem must be requested to the PrevalenceEngine, through the PrevalentSystem property. It will accurately return an instance from the Clients class with an equal state to the one of the last execution (in case that she has had one). <o:p>

4. As it was mentioned, any alteration in the PrevalentSystem, to prevail is demanded that it is made through objects of class that implement  the IOperation interface . Thus, we can declare two class, a AddClient call and another RemoveClient call , both implementing the IOperation interface . Respectively they would be used to add and to remove objects  Client of the PrevalentSystem. (To the long one of this text we will be able to see what the XPrevail considers for a simpler and intuitive programming, not demanding the creation of these class) <o:p>

5. To add a client, we now need to create an instance of the AddClient class , passing in its constructor the necessary information the execution of its task. We must then request to the PrevalenceEngine that executes this operation. This will involve the serialization of the AddClient  object later in an archive destined to log of operations and its execution, where of fact the addition of the client will occur. <o:p>

6. Let us say that after to execute some times item 5, beyond terms also carried through some removals of client, we will have then a PrevalentSystem I contend one definitive amount of Client objects . The archive of log of operations will contain a serialized version of all the objects (that they implement IOperation ) that they had effected alterations in the PrevalentSystem, accurately in the same order where they had occurred. <o:p>

7. Case in this point occurred an energy feed. Our application would have to be restituted in air, so soon the environment has been re-established. At the moment of the initialization of the PrevalenceEngine, it it will go to read all the generated archives of log of operations. It will deserialize all the objects contained in the archives and will go to execute them again. He attempts against for the detail that the objects kept in this archive are of the AddClient class , not them of the Client class . The PrevalenceEngine is constantly registering the alterations carried through in business objects, not them business objects itself. <o:p>

8. Having the application directed to air and its recouped previous state, we could generate plus some alterations in the PrevalentSystem and request one snapshot. At this moment the PrevalenceEngine will go to generate a new archive, not one of operations, but a specifically for snapshot. This archive will contain a serialized version of the entire PrevalentSystem, or either, effectively of all the business objects. Let us say that after snapshot, we made plus some alterations in the state of the PrevalentSystem and occurred another feed of energy. <o:p>

9. When our application to request the initialization of the PrevalenceEngine, it will search for most recent snapshot generated. Of ownership of it, it will deserialize its content and will get a version of the PrevalentSystem. Made this, it will catch all the archives of log of posterior operations to last snapshot and re-will execute all previously the operations in top of the gotten PrevalentSystem. This will result in a PrevalentSystem such which existed before the feed, of the possible optimized form more. <o:p>

<o:p> 

Requirements of the prevalence <o:p>

<o:p> 

The prevalence possess two required requirements to be taken care of for the business objects that will be persisted, them must be serializables and deterministics. A deterministic object is that one that submitted to one same series of alterations, in one same order, always will result in one same final state. The class that represents the PrevalentSystem, obviously, also needs to be serializable. In .NET the more efficient and simplest form to become a serializable class is through the SerializableAttribute attribute. <o:p>

The involved concepts in the prevalence are established in such way to execute the tasks of an optimized form, this reflected in questions as: <o:p>

- To serialize the alterations in business objects, in the place of proper them, this significantly diminishes the amount of space in disk necessary to guarantee the state of the PrevalentSystem. <o:p>

- Not to have any type of indexation in the generated archives, after all the objective is not to simulate a data base, but yes to eliminate it. Of this form, one concentrated only in the process of serialization and restoration of the objects. <o:p>

- The restoration of a PrevalentSystem through its snapshot is extremely faster than the backup through log of operations. It is easy to perceive the reason, through one snapshot it deserialize the PrevalentSystem as a whole, directly, already with log of operations, it it needs to deserialize all the objects of operations and to execute them again. Therefore he is recommended to carry through snapshots periodically, but it has care, during snapshot of a PrevalentSystem cannot be modified. <o:p>

<o:p> 

One another important detail, as all the objects are kept in memory, to work of efficient form with prevalence are necessary to have memory RAM enough to house all the objects of business of the system. <o:p>

I wait that they have noticed that covering the described pacings previously we do not have no involved instruction SQL. Positive a collateral effect of the prevalence concept is that we are obliged to face with more seriousness the object oriented concept, therefore will be only with it that we will work. We use our proper programming language to carry through querys, can bring and manipulate the data of any form. 

<o:p> 

What it is the XPrevail? <o:p>

<o:p> 

The XPrevail is a .NET prevalence objects layer, friendly and extended, implemented in Delphi for .NET. The framework is compatible with any language .NET, besides being freeware and opensource. The manifest topic XPrevail brings the reasons for which the XPrevail exists, as well as its differentials front to other implementations of prevalence. <o:p>

<o:p> 

Great part of you differentiate them searched for me, front to the others frameworks of prevalence, had been in favor of a more natural programming, providing one framework so transparent and less intromicive how much it was possible. I looked for to leave the model of programming with  the XPrevail in such way that an application was less dependent of it, facilitating the swap of the mechanism of persistence without great efforts. <o:p>

<o:p> 

I see the persistence as an isolated aspect of a software, not having to influence significantly in its model, architecture and implementation. This ideology was a constant during the modeling and implementation of the XPrevail. These objectives had taken me to make it some things of different form, besides adding some small features.

<o:p> 

Amongst the main ones you differentiate brought for the XPrevail I can detach the following ones: <o:p>

<o:p> 

PrevalentSystem's multiples <o:p>

<o:p> 

The XPrevail brings the MultiSystemsPrevalenceEngine, capable to work with  multiples PrevalentSystem's based in transparent proxy's of NET. This type of engine brings the great advantage not to need to define objects to carry through all the alterations in the PrevalentSystem, these alterations can be made through methods defined in the proper PrevalentSystem. The calls to these methods are intercepted and automatically converted into objects that are, in the traditional way, serialized and executed. <o:p>

<o:p> 

It makes possible a good splitting of responsibilities, in mode that each PrevalentSystem keeps operations only on objects logically related. Moreover, we can use the controlling class of the proper system as the PrevalentSystem's, not needing to create a global one involving them. <o:p>

<o:p> 

In summary, the use of PrevalentSystem's multiples helps to the terms a friendly and elegant code, more compliant with the good oriented object programming. <o:p>

Covering on all the business objects <o:p>

<o:p> 

The XPrevail introduces, through the ExtremePrevalenceEngine , the possibility to intercept all the solicitations carried through to business objects and automatically to transform them into appropriate objects, to serialize them and to execute them. With this, we can work of full transparent form, having access business objects and modifying them directly, without the intervention of a external class, not even of a PrevalentSystem. <o:p>

<o:p> 

This is an important pacing in the process to become the use of the XPrevail friendliest the client code, with some few requirements, will be able to make the prevalence of business objects directly, exactly for alterations carried through in them. This also contributes for a form of more natural programming and less dependent of the XPrevail or the concept of prevalence (It sees in roadmap the intention of the XPrevail in also supporting persistence in relationary data base).

Support to aspects oriented programming - AOP <o:p>

<o:p> 

Another well interesting feature brought by the XPrevail is the possibility to use a model of development based on the concepts of the aspects oriented programming, many times referenced simply as AOP. Great part of framework is based on proxy's, in turn, in the interception of code, basic principle of the AOP. Of this form, as I already it came using a similar boarding for communication between proxy's and internal class of framework, it was only question to publish a way it client code to get features of this boarding, so soon I  perceived this potential. 

Engines of framework that they implement the IAspectsSupport interface , currently the MultiSystemsPrevalenceEngine and the ExtremePrevalenceEngine , make avaible half to register and to deregister aspects (any object that implements the IAspect interface ) .

The XPrevail make avaible two implemented aspects, in version preliminary daily pay, that can already freely be used by the client code, is they it TraceAspect and ProfileAspect . Respectively, they are capable to register called the methods in top business objects and to register the times taken for execution of the same ones. This is features extremely useful and powerful, certainly it still will be well developed in the future versions of the XPrevail (to see roadmap). <o:p>

<o:p> 

He does not leave to visit the " Manifest" section in the site of XPrevail.

Working with the XPrevail <o:p>

<o:p> 

We will now see an full example of use of the ExtremePrevalenceEngine , the main PrevalenceEngine of the XPrevail, in it is where we find the real essence of framework. Before continuing, a tutorial reading of the  Hello Prevalence and Hello Prevalence 2 , in the site of the XPrevail, can sufficiently help the agreement of the example that we will develop here. <o:p>

<o:p> 

Defining the object model <o:p>

<o:p> 

Before thinking about the persistence we need first to define the model of our business objects. For simplicity questions we go to work with only one business object, People . We will use it stops creating a small application for I register in cadastre of people.

  People = class 
  strict private
    FName: System.String;
    FBirthDate: System.DateTime;
    FEMail: System.String;
  public
    function ToString : String; override;
    procedure set_Name(const Value: System.String);
    procedure set_EMail(const Value: System.String);
    procedure set_NiverDate(const Value: System.DateTime);
    function get_Age: Integer;
    property Name : System.String read FName write set_Name;
    property Age : Integer read get_Age;
    property EMail : System.String read FEMail write set_EMail;
    property BirthDate : System.DateTime read FBirthDate write   set_NiverDate;
    constructor Create(aName : String; aEMail : String; aBirthDate :   DateTime);
  end; 

Soon, this would be the definition standard of our class, however we need to make some alterations in mode that it takes care of the requirements of the prevalence and the ExtremePrevalenceEngine. For this, we will need to make the following modifications: <o:p>

<o:p> 

1. As it was said, the business objects need to be serializables, then we must include the SerializableAttribute attribute in the class. <o:p>
2. The business objects, as well as the PrevalentSystem, need to be descending MarshalByRefObject. <o:p>
3. So that framework obtains to correctly identify a given business object, it it needs to implement the IObjectID interface, besides being marked with the BusinessObjectClassID attribute. <o:p>

<o:p>

Carried through the necessary alterations, the interface of our People class is thus:

  [Serializable] <o:p>

  [BusinessObjectClassID(PeopleClassID)] <o:p>

  People = class (MarshalByRefObject, IObjectID) <o:p>

strict private <o:p>

  FID : System.String; <o:p>

    FName: System.String; <o:p>

    FBirthDate: System.DateTime; <o:p>

    FEMail: System.String; <o:p>

  public <o:p>

    function ObjectID : string; <o:p>

    function ToString : String; override; <o:p>

    procedure set_Name(const Value: System.String); <o:p>

    procedure set_EMail(const Value: System.String); <o:p>

    procedure set_NiverDate(const Value: System.DateTime); <o:p>

    function get_Age: Integer; <o:p>

    property Name : System.String read FName write set_Name; <o:p>

    property Age : Integer read get_Age; <o:p>

    property EMail : System.String read FEMail write set_EMail; <o:p>

    property BirthDate : System.DateTime read FBirthDate write   set_NiverDate; <o:p>

    constructor Create(aID, aName : String; aEMail : String; aBirthDate :   DateTime); <o:p>

  end; <o:p>

  The next pacing is to create a class that will be our PrevalentSystem, sees then the definition of the PeopleManager class for this intention.

  [Serializable] <o:p>

  [PrevalentSystemClassID('{319D4955-4CE8-4443-9010-9BAE12046C24}')] <o:p>

  PeopleManager = class (MarshalByRefObject, IBusinessObjectFromID) <o:p>

  strict private <o:p>

    FPeoples : ArrayList; <o:p>

  strict protected <o:p>

    function BusinessObjectFromID(BOClassID, ObjectID: string): TObject; <o:p>

  public <o:p>

    function AllPeoples : ArrayList; <o:p>

    [BusinessObjectExport] <o:p>

    function get_Peoples(Index: Integer): People; <o:p>

    property Peoples[Index : Integer] : People read get_Peoples; <o:p>

    function get_PeopleCount : Integer; <o:p>

    property PeopleCount : Integer read get_PeopleCount; <o:p>

    [Operation] <o:p>

    [BusinessObjectExport] <o:p>

    function AddPeople(aID, aName : String; aEMail : String; aBirthDate :   DateTime) : People; <o:p>

    [Operation] <o:p>

    [RealBusinessObjectRecovery] <o:p>

    procedure RemovePeople(aPeople : People); <o:p>

    constructor Create; <o:p>

  end; <o:p>

Such which a business object class, the PrevalentSystem also needs to descend of MarshalByRefObject and to receive the Serializable attribute (in the truth to be serializable). As the ExtremePrevalenceEngine is a PrevalenceEngine that it supports to work with some PrevalentSystem's, it is necessary that they are marked with the PrevalentSystemClassID attribute, so that framework obtains to identify them correctly. It also notices that the IBusinessObjectFromID interface is implemented by the PeopleManager class, this is necessary only if the PrevalentSystem in question keeps reference the business objects. <o:p>

<o:p> 

It observes the use of some attributes decorating methods of the PeopleManager class, let us see now so that it serves each one of them. <o:p>

<o:p> 

1.      Operation : It indicates to the XPrevail that the method in question carries through alterations in the state of the PrevalentSystem. In case that a method that modifies the state of the PrevalentSystem is marked with this attribute, the alteration will not prevail. <o:p>

2.      BusinessObjectExport : It indicates to framework that this method returns an object from business for is of the PrevalentSystem, this form, the XPrevail intercepts this call and returns one proxy for the object in question, in mode that the alterations carried through directly in the object are persisted. It observes that, as in all mechanism of persistence, it fits to the programmer to decide what will be persisted. Alterations in an object of business gotten for a method without this attribute will not be persisted. <o:p>

3.      RealBusinessObjectRecovery : It indicates to the XPrevail that it must recoup the object from a version duplicate of it (more details in the box to follow). <o:p>

<o:p> 

RealBusinessObjectRecovery <o:p>

The prevalence in general way prohibit that class that implement the IOperation interface (or Transaction in the Prevayler), or either, that they modify the state of a PrevalentSystem has direct reference to a business object. Therefore of this form, the business object will be duplicate and the alteration in question will be given in this version duplicates, this cause sufficient problems. This error is sufficiently common, being considered an error of baptism of the prevalence. <o:p>

<o:p> 

Then, the XPrevail does not recommend that this is fact, however not prohibit. It it leaves the option of thus shape you its code, being client of will involve some cost of performance. Being certain of this option, it is enough to mark the method with the RealBusinessObjectRecovery attribute and the XPrevail will take care of so that this does not generate unexpected problems. This will be demonstrated in the example. <o:p>

<o:p> 

Soon, now already we have our justifd class to develop our prevalent example. And best, all the persistence code already was practically fact, or either, almost none. It observes that the requirements of the XPrevail are not very intrusive, since attributes and/or implementations of interfaces are decided with adornments through. An eventual decision to remove the XPrevail as persistence mechanism, or to customize software to another mechanism, does not imply in a significant loss of code. <o:p>

<o:p> 

Developing a console application <o:p>

<o:p> 

We now go to create a console application to illustrate the use of the class that we define. So that the text is not big extensive, I will place only the really excellent stretches of implementation. To have access to the full code it is enough to make download of the applicatory one of example of this article. To compile it, it is essential to lower the XPrevail, you can make this through link http://xprevail.sourceforge.net/en-us/download.htm. <o:p>

<o:p> 

The first point to comment as to get an initial instance of our PrevalentSystem and as we will see, it must be requested to the PrevalenceEngine. But for this, we need first to get an instance of proper engine. The code below illustrates all this process:

001. var <o:p>

002.    Engine : ExtremePrevalenceEngine; <o:p>

003.    GenKeys : GenerateKeys; <o:p>

004.    PManager : PeopleManager; <o:p>

005. <o:p>

006. begin <o:p>

007.    Engine := XPrevailFactory.CreateExtremePrevalenceEngine([typeOf(GenerateKeys), <o:p>

              typeOf(PeopleManager)], Path.Combine(Environment.CurrentDirectory, 'data')); <o:p>

008.    GenKeys   := Engine.PrevalentSystems[typeOf(GenerateKeys)] as GenerateKeys; <o:p>

009.    PManager := Engine.PrevalentSystems[typeOf(PeopleManager)] as PeopleManager; <o:p>

<o:p> 

010. {…} <o:p>

011. end. <o:p>

The lines 002 to 004 contain only the declarations of the references. In line 007 the creation of an instance of the  ExtremePrevalenceEngine class is requested, as we can see, this is made through the XPrevailFactory class. The CreateExtremePrevalenceEngine method requires as first parameter an array of System.Type representing the PrevalentSystem's that will be managed by engine. As the parameter informs the folder where the archives of log of operations and archives of snapshots will be placed.

Certainly you already it perceived that we are using as a PrevalentSystem, represented for the GenerateKeys class. That as the name it suggests, will serve exactly as a generator of ID's for our objects. The definition of this class is very simple and can below be seen:

  [Serializable] <o:p>

  [PrevalentSystemClassID('{5CFE36DA-9C6A-495F-911B-10CD99374195}')] <o:p>

  GenerateKeys = class (MarshalByRefObject) <o:p>

  strict private <o:p>

    HashKeys : HashTable; <o:p>

  public <o:p>

    [Operation] <o:p>

    function NewKey(ObjectType : System.Type) : Integer; <o:p>

    constructor Create; <o:p>

  end; <o:p>

It assures that an only one for objects of a specified type is generated sequential, can occur of business objects to have equal ID's, since that they are of different types. This is a requirement of the ExtremePrevalenceEngine . It observes that as it does not keep business objects, does not need to implement the IBusinessObjectFromID interface. To follow we can see the implementation of its main method, the NewKey.

function GenerateKeys.NewKey(ObjectType: System.Type): Integer; <o:p>

var <o:p>

  KeyID : Integer; <o:p>

begin <o:p>

  Monitor.Enter(ObjectType); <o:p>

  try <o:p>

    if HashKeys.Contains(ObjectType) then <o:p>

      begin <o:p>

        KeyID := Integer(HashKeys.Item[ObjectType]); <o:p>

        Inc(KeyID); <o:p>

        HashKeys.Item[ObjectType] := &Object(KeyID); <o:p>

      end <o:p>

    else <o:p>

       begin <o:p>

        KeyID := 1; <o:p>

        HashKeys.Add(ObjectType, &Object(KeyID)); <o:p>

      end; <o:p>

    Result := KeyID; <o:p>

  finally <o:p>

    Monitor.Exit(ObjectType); <o:p>

  end; <o:p>

end; <o:p>

Strings 008 and 009 get the instances of our PrevalentSystem's. As the operations of the PeopleManager will use the GenerateKeys , it is important that this last either requested first one. This is made through the PrevalentSystems property, having informed the System.Type of the intended PrevalentSystem. We now go to continue analyzing some stretches keys of the implementation of our applicatory one. <o:p>

<o:p> 

Adding a people <o:p>

<o:p>