Preimeiramente gostaria de deixar a informação de que o projeto XPrevail não foi concebido pela cópia/tradução dos fontes de nunhum outro framework de prevalência, mas sim pela implementação do conceito, originalmente criador por Klaus Wuestefeld , de acordo com minhas próprias idéias e um inicial direcionamento de meu interesse. O XPrevail é implementado em Delphi for .NET - minha linguagem primária, portanto, um framework compatível com qualquer linguagem .NET.

Grande parte dos diferencias buscados por mim, frente aos outros frameworks de prevalência, foram em prol de uma programação mais natural, provendo um framework tão transparente e menos intromicivo quanto fosse possível. Procurei deixar o modelo de programação com o XPrevail de tal maneira que uma aplicação ficasse menos dependente dele, facilitando a troca do mecanismo de persitência sem grandes esforços.

O modelo de trabalho originalmente proposto pelo Prevayler , baseado no padrão GoF Command, é uma reconhecida solução orientada a objetos. Pode trazer muita flexibilidade e, se bem conduzido, facilidade de manutenção. Esse modelo traz o benefício da total transparência para os objetos de negócios, pois eles nem mesmo sabem que estão sendo persistidos.

Contudo, por outro lado, traz alguns inconvinientes. A aplicação pode ser negativamente afetada por um grande número de classes "auxiliares" geradas para realizar as operações em cima dos objetos de negócio. Caso haja a necessidade de mudança no mecanismo de persistência, isso demandará um esforço significativo, além de podermos perde parte da codificação realizada. Também temos a inconviniente sensação de não termos objetos de negócios auto-suficientes, que podem alterar a si mesmos. Eles acabem se tornando classes de contexto, sem comportamento independente, apenas containers de dados. Claro que podemos ter operações nos objetos de negócios, mas elas ou não podem alterar o estado interno do próprio objeto, ou só podem ser chamadas a partir de uma classe que implementa a interface Transaction*. Caso contrário a mudança de estados não é persistida.

Vejo a persistência como um aspecto isolado de um software, não devendo influcienciar significativamente em seu modelo, arquitetura e implementação. Essa ideologia foi uma constante durante a modelagem e implementação do XPrevail. Esses objetivos levaram-me a fazer algumas coisas de forma diferente, além de adicionar alguns pequenos recursos.

O XPrevail suporta toda a abordagem original primária encontrada no Prevayler , na qual as alterações em um PrevalentSystem são realizadas através de objetos que implementam a interface Transaction*. O XPrevail também possue um PrevalenceEngine tal qual o

TransparentPrevalenceEngine , encontrado no Bamboo.Prevalence, baseados em proxys transparentes do .NET. Esse tipo de engine já traz a grande vantagem de não precisar definir objetos para realizar todas as alterações no PrevalentSystem, essas alterações podem ser feitas através de métodos definidos no próprio PrevalentSystem. As chamadas a esses métodos são interceptadas e automaticamente convertidas em objetos que são, da maneira tradicional, serializados e executados. Contudo ele possui um potencial problemático.

Quando um PrevalentSystem mantém referência a vários tipos de objetos de negócios ele acaba tendo de ter vários métodos para trabalhar em vários tipos de objetos diferentes. Isso traz problemas de manutenção e legibilidade ao código, além de ser algo bem questionável segundo a ótica da boa programação orientada a objetos

Para resolver essa situação o XPrevail traz o MultiSystemsPrevalenceEngine , capaz de trabalhar com vários PrevalentSystem's ao mesmo tempo. Ele possibilita uma boa separação de responsabilidades, de modo que cada PrevalentSystem mantenha operações apenas sobre objetos logicamente relacionados. Além disso, p odemos usar as classes gerentes do próprio sistema como os PrevalentSystem's, não precisando criar uma global envolvendo-as.

De forma resumida, o uso de múltiplos PrevalentSystem's ajuda a termos um código amigável e elegante, mais condizente com a boa programação orientada a objetos. Consulte a documentação das classes do XPrevail para obter maiores detalhes.

O XPrevail introduz, através do ExtremePrevalenceEngine , a possibilidade de interceptar todas as requisições realizadas aos objetos de negócio e automaticamente transformá-las em objetos apropriados, serializá-los e executá-los. Com isso, podemos trabalhar de forma completamente transparente, acessandos os objetos de negócios e modificando-os diretamente, sem a intervenção de uma classe externa, nem mesmo de um PrevalentSystem.

Esse é um importante passo no processo de tornar o uso do XPrevail mais amigável ao código cliente, com algumas poucas exigências, poderemos fazer a prevalência dos objetos de negócios, mesmo para alterações realizadas diretamente neles. Isso também contribui para uma forma de programação mais natural e menos dependente do XPrevail ou do conceito de prevalência (Veja em roadmap a intenção do XPrevail em suportar persistência em banco de dados relacionais também).

Outra característica bem interessante trazida pelo XPrevail é a possibilidade de utilizar um modelo de desenvolvimento baseado nos conceitos da programação orientada a aspectos, muitas vezes referenciada simplesmente como AOP.

Grande parte do framework é baseado em proxys, por sua vez, na interceptação de código, princípio básico da AOP. Dessa forma, como eu já vinha utilizando uma abordagem similar para comunicação entre proxys e classes internas do framework, foi apenas questão de publicar uma maneira do código cliente obter recursos dessa abordagem, tão logo eu percebi esse potencial.

Os engines do framework que implementam a interface IAspectsSupport, atualmente o MultiSystemsPrevalenceEngine e o ExtremePrevalenceEngine , disponibilizam meios de registrar e desregistrar aspectos. Consideramos um aspecto qualquer objeto que implemente a interface IAspect.

O XPrevail disponibiliza dois aspectos implementados, em versão pré- liminar, que podem já ser utilizados livremente pelo código cliente, são eles o TraceAspect e ProfileAspect . Respectivamente, eles são capazes de registrar chamadas a métodos em cima dos objetos de negócios e registrar os tempos levados para execução dos mesmos. Esse é um recurso extremamente útil e podereso, certamente ele será ainda bem desenvolvido nas versões futuras do XPrevail (ver roadmap).

*Além dessas características adicionas ainda existem outras, talvez menos importantes, mas que podem ser percebidas no trabalho com o framework. Uma delas seria a nomeclatura utilizada pela interface a ser implementada pelos objetos que alteram o estado do PrevalentSystem. No XPrevail ela é chamada IOperation, diferente de Transaction como é no Prevayler. O nome IOperation foi utilizado pelo foco dado ao projeto XPrevail, onde quase sempre ele estará interceptando métodos - operações de classes. Além disso, o nome ITransaction deverá ser utilizado pelo suporte a transações, tal qual num RDBMS, em versões futuras do projeto (ver roadmap).

É isso, desejo que tenha ficado bem compreedido que em momento algum quis posicionar o XPrevail em grau de competição com qualquer um outro, muito pelo contrário, poderemos certamente cooperar em prol da divulgação do conceito. Apenas quis explicar algumas diferenças do projeto XPrevail, bem como os objetivos e pensamentos que me levaram a elas.