Firstly would like to leave the information of that
the XPrevail project was not conceived by the copy/traduction of the sources of
any another one framework of prevalence, but yes by implementation of the
concept, originally creative for Klaus Wuestefeld , in accordance with my proper ideas
and one initial aiming of my interest. The XPrevail is implemented in
Delphi for .NET - my primary language, therefore, the framework is
compatible with any .NET language.
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
"intrusive" 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 exchange of the
persistence mechanism without great efforts.
The model of work originally considered by the
Prevayler, based on the standard GoF Command, is a recognized object oriented
solution. It can bring much flexibility and, if lead well, easiness of
maintenance. This model brings the benefit of the total transparency for
business objects, therefore they not even know that they are being persisted.
However, on the other hand, it brings some
inconvinientes. The application can negative be affected by a great
number of class "auxiliary" generated to carry through the
operations over business objects. In case that it has the
necessity of change in the persistence mechanism, this will demand a
significant effort, besides being able loses part of the carried through
codification. Also we have inconviniente sensation of not have
self-sufficient business objects, that can modify itself same. They finish
if becoming context class, without independent behavior, only containers of
data. Clearly that we can have operations in business objects, but they
or cannot modify the internal state of the object self, or alone they can
be called from a class that implements the ITransaction* interface.
Contrary case the change of states is not persisted.
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 resources.
Amongst the main characteristics that distingüem the
XPrevail of the others prevalence frameworks, I can detach the shown ones
below:
Many PrevalentSystem's
The XPrevail supports all the found primary original boarding in the
Prevayler, in which the alterations in a
PrevalentSystem is carried through through objects that also implement the
ITransaction*
interface. The XPrevail has a PrevalenceEngine such which the
TransparentPrevalenceEngine,
found in the Bamboo.Prevalence, based in transparent proxys of
.NET. This type of engine already 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's and executed. However it possesss a problematic potential.
When a PrevalentSystem keeps reference to some types
of business objects it finishes having to have some methods to work in some
types of different objects. This brings problems of maintenance and
legibility to the code, besides to be something well questionable according to
optics of the good object oriented programming.
For to resolve this situation the XPrevail brings the MultiSystemsPrevalenceEngine,
capable of the work with many PrevalentSystem's at the same time. It
makes possible a good separation of responsibilities, in way that each
PrevalentSystem keeps operations only on objects logicamente
related. Moreover, we cam to use the controlling class of the
proper system as the PrevalentSystem's, not needing to create a global one
involving them.
In summary, the use of PrevalentSystem's multiples
helps to have a friendly and elegant code, more condizente with the good
object oriented programming. Consults the documentation of the class of
the XPrevail to get greaters details.
Covering on all business objects
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 directly work
of completely transparent way, accessing business objects and
modifying directally, without the intervention of a external class, not even of
a PrevalentSystem.
This is an important step in the process to become
the use of the XPrevail friendliest to 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).
Aspect oriented programming (AOP) support
Another well interesting characteristic brought by the XPrevail is the
possibility to use a development model based on the concepts of the aspect
oriented programming, many times referenced simply as AOP.
Great part of framework is based on proxys, in turn, in the code interception,
basic principle of the AOP. Of this form, as I already it came using a similar
boarding for communication between proxys and internal class of framework, it
was only question to publish a way it client code to get resources of this
boarding, so soon I perceived this potential.
Th engines of framework that they implement the IAspectsSupport interface,
currently the MultiSystemsPrevalenceEngine and the ExtremePrevalenceEngine, make
available half to register and to unregister aspects. We consider a aspect
any object that implements the IAspect interface.
The XPrevail disponibiliza two implemented aspects, in version preliminary,
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 business objects and to register the times taken for
execution of the same ones. This is resources extremely useful and
powerful, certainly it still will be well developed in the future versions of
the XPrevail (to see
roadmap).
*Beyond these characteristics added,
still exist others, perhaps less important, but that they can be perceived
in the work with framework. One of them would be the nomeclature used for
the interface to be implemented by the objects that modify the state of the
PrevalentSystem. In the XPrevail it is called IOperation,
different of ITransaction as she is in the Prevayler. The IOperation
name was used by the focus given to the XPrevail project, where almost always
it will be intercepting methods - operations of class. Moreover, the ITransaction
name will have to be used by the support the transactions, such which in a
RDBMS, future versions of the project (to see
roadmap).
It is this, desire that has been well understanded that at any
moment wanted to locate the XPrevail in degree of competition with any one
another one, quite to the contrary, will be able certainly to cooperate in
favor of the spreading of the concept. But it wanted to explain some
differences of the XPrevail project, as well as the objectives and thoughts
that had taken me they.
Regards,
Fernando Vasconcelos Mendes - FernandoVM