XPrevail is a .NET object prevalence layer, friendly and extended. In case that you already it knows the prevalence concept the manifest section brings the reasons for which the XPrevail exists, as well as its differentials front the other implementations.

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

The prevalence use is an alternative to the use of the 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 advantages of the prevalence use we can cite the great profit of performance for querys and the drastic reduction of costs of a solution (the data base eliminates costs of serving pair here (the hardware), licenses of the serving software of database, operational cost of maintenance and etc).

We now go to inside understand the general functioning of the prevalence, starting for some used common terms of this concept:

PrevalenceEngine: The instance of an internal class of framework that it is responsible for all the execution proceeding, registers and recovery of the alterations carried through in the PrevalentSystem.

PrevalentSystem: A class that must contain internal reference to all the business objects of one given application. The objects in the referenceds ones will be serializeds completely when snapshot will be requested to PrevalenceEngine one. Of this form, any object is of this class will have its lost state.

Command/Transaction: The version 2.0 of Prevayler now denominate Transaction what in version 1.0 it called Command. All alteration to be carried through in objects kept for the PrevalentSystem must be made through objects of class that implement the Transaction interface defined by framework.  These instances are passed to the PrevalenceEngine for register and execution. In the XPrevail project the IOperation interface is the equivalent the existing Transaction in the Prevayler (to see manifest for more details).

Snapshot: Is the process in which the PrevalenceEngine serialize all PrevalentSystem, such which it is at the moment of the request. This becomes unnecessary the reading of the previous log transactions files.

Known some of the involved terms we go now to a description of the process.  It imagines that let us have only one class of business in one given application, the class Customer. We go to the steps to become our prevalent application.

1. We need to define a class that will keep reference to our objects of the Customer class, it will be our PrevalentSystem and it could call Customers.

2. We will have to declare a reference for the PrevalenceEngine and initialize it, moment in which will be demanded the information of which class will be the PrevalentSystem, of course must inform Customers.

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

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 Transaction interface. Thus, we can declare two class, a called AddCustomer and another called RemoveCustomer, both implementing the Transaction interface. Respectively they would be used to add and to remove objects Customer in/of the PrevalentSystem.

5. To add a customer, we now need to create an instance of the AddCustomer class, passing in its constructor the necessary information the execution of its task. We must then request to the PrevalenceEngine that executes this transaction. This will involve the serialization of the object AddCustomer in an archive destined to log of transactions and after execution of the transaction, where of fact the addition of the customer will have to occur.

6. Let us say that after to execute some times the item 5, beyond terms also carried through some removals of customers, we will have then a PrevalentSystem I contend one determinated amount of Customer objects. The archive of log of transactions will contain a serialized version of all the objects (that they implement Transaction) that they had effected alterations in the PrevalentSystem, accurately in the same order where they had occurred.

7. Case in this point occurred an energy imperfection. Our application would have to be restituted in air, so soon the environment has been re-established. At the moment of the PrevalenceEngine initilization, it it will go to read all the generated archives of log of transactions. It will deserialize all the objects contained in the archives and will go re-to execute them. He is intent, the objects kept in this archive they are for examples, of the AddCustomer class, not them of the Customer class. The PrevalenceEngine is constantly registering the alterations carried through in business objects, not them objects of business in itself.

8. Having the application go back to air and its recouped previous state, we could generate plus some alterations in the PrevalentSystem and request a snapshot. At this moment the PrevalenceEngine will go to generate a new archive, not one of transactions, but 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 imperfection of energy.

9. When our application to request the PrevalenceEngine initialization, 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, after to last snapshot will catch all the archives of log of transactions and re-will execute all previously the transactions in top of the gotten PrevalentSystem. This will result in a PrevalentSystem such which existed before the crash, of the possible optimized form more.

This would be more or less the flow of execution of a prevalent application.

The prevalence has two obligator 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.

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

- Serialize the alterations in business objects, in the place of proper them, this reduce significantly the amount of space in record necessary to guarantee the state of the PrevalentSystem.

- Don't have any type of indexation in the generated archives, the objective is not to simulate a database, but yes to eliminate it. Of this form, one concentrated only in the process of serialization and object recovery.

- The recovery of a PrevalentSystem through its snapshot is extremely faster than the recovery through log of transactions. 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 transaction objects and re-execute them. Therefore it is recommended to carry through snapshots periodically.

Bom, terminamos aqui essa visão geral do conceito de prevalência, recomendo a leitura do FAQ para tirar quaisquer eventuais dúvidas
restantes (ou geradas) após a leitura desse texto.

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

Good, we finish here this vision general prevalence concept, I recommend the reading to it of the FAQ to take off any eventual doubts after remaining (or generated) the reading of this text.