Oragon Architecture

O que é?

Oragon Architecture, é um Application Framework, Open Source que contribuo e cuido ha anos. Comecei o projeto com código fechado, em 2007, após anos usando uma base consistente de frameworks e padrões para desenvolver projetos .Net. A intenção inicial era ter uma base de código pronta, para reduzir o tempo de codificação da infraestrutura de mecanismos das aplicações que eu construía. Com o passar dos meses, o projeto foi crescendo até poder ser chamado de Application Framework, organizando e orquestrando uma série de padrões e mecanismos diversos. Desde o início, a proposta do projeto é entregar robustez e absorver a complexidade na hora de integrar frameworks e padrões. A proposta sempre foi deixar o código das aplicações o mais simples possível, deixando a cargo do Oragon Architecture, toda a responsabilidade por gerir a infraestrutura rotineira no desenvolvimento de aplicações de negócio.

A evolução do projeto

A adoção

Para aqueles que trabalham comigo, não é mistério que eu tento ao máximo aplicá-lo aos projetos que participo. Assim, os projetos me geram demandas arquiteturais, que tento contemplá-las no Oragon Architecture, e assim a cada projeto que faço o Oragon Architecture fica maior e mais completo. Eu realmente não faço ideia de quantos projetos já usei a solução, mas com certeza são algumas dezenas. No início o projeto contava apenas com helpers diversos, depois entrou a geração de código estática (ainda usando MyGeneration). Com a geração de código, surgiu a demanda pelos primeiros aspectos AOP, que evoluem sempre: seja com a criação de novos aspectos ou o aperfeiçoamento os aspectos existentes.

Services

O Oragon Architecture foi concebido sobre o Spring.Net, usando e estendendo suas abstrações para prover aplicações mais robustas. A principal feature do Spring.Net que usávamos no início eram os Services Abstractions, que permitiam deploy de serviços já construídos usando diversas tecnologias (leia mais). Essas abstrações permitem facilitar a computação distribuída, hospedando serviços e client-proxies para diversas tecnologias, como:

Essas abstrações são realizadas via configuração, sem a necessidade de sequer recompilar sua solução. Sob esse princípio, o Oragon Architecture seguiu nessa linha, oferecendo mais e mais abstrações, permitindo que decisões que geralmente envolvem grande refactoring, pudessem ser tomadas a qualquer momento, inclusive após o fim do desenvolvimento do projeto.

A infraestrutura do Spring.Net para abstração de serviços nasceu bem antes do surgimento do WCF. Até sua criação, a substituição de um deploy de serviço embarcado para remoto, não demandava alterações no código.

Somente com a chegada do WCF, e por causa das exigências dos novos atributos (ServiceContract, OperationContract, DataContract, DataMember), esse tipo de troca de abordagem exige pequenas mudanças em seu código.

RabbitMQ Services

Em 2013, o projeto evoluiu muito e todas as implementações baseadas em MSMQ foram substituídas por versões baseadas em RabbitMQ. Adicionamos o Workflow Pipeline ao projeto e a possibilidade de hospedar serviços usando RabbitMQ para transporte de mensagens, abdicando da utilização do WCF para esses cenários.

Geração de Código

Com o amadurecimento do processo de geração de código, por volta de 2010, o MyGeneration deixou de ser utilizado como ferramenta auxiliar e incorporei todo o pipeline de geração de código ao projeto, permitindo ainda o versionamento de todas as configurações de geração de código, junto com o projeto. Melhorando a gerência de versões e configuração. Sob a premissa de que código gerado não deve ser modificado manualmente, essa infraestrutura ficou muito robusta na medida que novos recursos como:

  • Plugins de resolução de padrões de nomenclatura de tabelas e colunas
  • Plugins para pluralização em PT-BR e EN-US
  • Plugins para Resolução de conflitos de nomes
  • E as abstrações para a criação de plugins novos, por demanda, projeto-a-projeto

Com esses plugins, é possível mapear uma tabela com nome TB_USUA com uma coluna chamada USUA_CD_USUARIO em uma classe chamada Usuario, com uma propriedade CodigoUsuario ou ainda, apenas Codigo, com o case correto, inclusive.

As primeiras versões, dos templates, geravam código para NHibernate, e seus HBMs, no entanto com o lançamento do FluentNHibernate, a geração de código ficou mais limpa, como nos exemplos abaixo.

Nesse exemplo, temos plugins simples, mas coma capacidade e demonstra o plugin de pluralização, seguindo as normas do Inglês (Directories, uma lista de entidades Directory).

Abaixo temos um exemplo mais complexo, excelente para demonstrar as capacidades da Geração de Código Oragon Architecture.

Nesse exemplo, temos algumas features bem interessantes:

  • Suporte a convenções onde a propriedade CodGrupoAcesso é gera uma propriedade chamada CodGrupo.
  • As tabelas GrupoAcessoAcaoSistema geram, respectivamente, as entidades Grupo e Acao.
  • As pluralizações corretas
    • IList<Acao> Acoes
    • IList<ProfissionalGrupo> ProfissionaisGrupo
  • A resolução de convenções de criação de banco como a coluna FlgGrupoAdministrativo gerando a propriedade GrupoAdministrativo.

OS EXEMPLOS NÃO FORAM MANIPULADOS MANUALMENTE, são exemplos de código gerado automaticamente.

Oragon Architecture

Oragon Architecture

O gerador, quando configurado corretamente, tem a capacidade de realizar conversões de nomes de colunas e tabelas e resolução de plurais. Tudo para gerar um código mais limpo e o mais próximo do que modelaríamos manualmente, se o fizéssemos.

A infraestrutura de geração de código foi criada pensando no GAP entre DBAs e suas regras e os desenvolvedores. É comum, encontrarmos um conjunto de regras absurdo, em grandes corporações. As técnicas e features usadas no gerador visam assimilar as regras de conversão para tornar sua vida mais produtiva, e independente.

Programação Orientada a Aspectos

(Aspect-Oriented Programming)

No projeto cuidamos muito bem de assuntos que geram ovehead de código.

NHibernate AOP

No exemplo proposto na própria documentação do Nhibernate temos:

Com os aspectos do Oragon Architecture, a nossa versão do exemplo ficaria:

Nesse exemplo o aspecto é definido via atributos. O código fica mais limpo.

Outra característica extremamente relevante é quando você precisa de que diversas tarefas cooperem em uma única transação. Geralmente você precisaria criar a session do NHibernate em sua camada de serviço e repassá-la, repositório a repositório. Ou usar algum modelo Singleton ThreadSafe para fazer isso.

Os contextos AOP criados no Oragon Architecture foram desenhados para que você marque seus métodos com atributos, e a infraestrutura do Oragon Architecture gerencia todo o ciclo de vida, em um isolamento threadsafe, durante a execução do seu método. Qualquer requisitante, na mesma thread, chamado pelo método que contém o atributo, automaticamente herda toda a infraestrutura já definida, sem a necessidade de enviar parâmetros específicos como contextos do NHibernate, contexto de cache e transações.

No exemplo abaixo, temos uma cooperação transacional, tanto o método Save do UserDataProcess quanto LogDataProcess, usam a mesma sessão e transação para executarem suas tarefas.

MongoDB AOP

A propósito, não poderia deixar de demonstrar a utilização do MongoDB. Usando o atributo [MongoDBContextAttribute(string key)] é possível usar os mesmos conceitos abordados nos exemplos do NHibernate. A propósito, a intenção é abordar mais e mais tecnologias.

Redis AOP

Assim como com o NHibernate, e com MongoDB, temos um exemplo com Redis.

Multiplos Aspectos

Se você tem cenários que utilizam muitas tecnologias, a infraestrutura de aspectos permite que você use-as todas juntas, de forma transparente. Como no exemplo abaixo:

No exemplo acima, temos a mesma infraestrutura de aspectos criando contextos para:

  • MongoDB
  • Redis
  • NHibernate, apontando para uma configuração específica de uma base SQL Server
  • NHibernate, apontando para uma configuração específica de uma base MySQL

Esse código foi tirado de um exemplo real, onde um XML é convertido para Json e persistido no MongoDB, mas com a ajuda do Cache, podemos evitar esse passo, obtendo o mesmo objeto direto do Redis. Em adição, dois updates em bases distintas, uma usando MySQL e a outra SQL Server, são necessárias.

Nesse exemplo, temos ao final, toda a execução das operações com banco, usando uma transação distribuída (configurável). Abrimos e fechamos automaticamente todas as sessões e transações do NHibernate, MondoDB e Redis, respectivamente antes e depois de chamar o método Store. Todas as chamadas, na mesma classe ou de a outras classes que acontecerem a partir da chamada do método Store, compartilharão todos os recursos solicitados pelas configurações de atributos do método Store. Tudo isso acontece com a simples marcação de atributos em métodos de serviço.

 

Leia mais sobre Oragon Architecture!

Gostou, quer saber mais sobre isso? Deixe sua opinião, dúvida ou simplesmente comente!