[deprecated]Oragon Architecture – Application Hosting – Suporte para Nijnect e SimpleInjector e qualquer outro container

[deprecated]Oragon Architecture – Application Hosting – Suporte para Nijnect e SimpleInjector e qualquer outro container

[deprecated]

Bom, tenho escrito o bastante para nem precisar perguntar como você está! Né?!

Já estamos íntimos e agora vou contar uma novidade! Implementei o suporte a dois containers bem conceituados no mercado e simplifiquei o modelo para que você possa implementar facilmente uma nova extensão para qualquer IoC container que tenha o interesse de trabalhar.

Só para mostrar como é simples, está aqui todo o código para estender o Oragon Architecture Application Hosting para o Ninject.

public interface INinjectFactory : IContainerFactory<IKernel> { }
public class NinjectApplicationHostController : ApplicationHostController<INinjectFactory, IKernel> { }
public class NinjectApplicationHost : ApplicationHost<NinjectApplicationHostController, INinjectFactory, IKernel> { }

Se não se convenceu ainda, aqui está o código para criar uma integração nova com o SimpleInjector

public interface ISimpleInjectorFactory : IContainerFactory<Container> { }
public class SimpleInjectorApplicationHostController : ApplicationHostController<ISimpleInjectorFactory, Container> { }
public class SimpleInjectorApplicationHost : ApplicationHost<SimpleInjectorApplicationHostController, ISimpleInjectorFactory, Container> { }

Simples né?!

A escolha dos dois frameworks se deu pelas suas características enquanto o SimpleInjector é o mais rápido em diversos benchmarks, o Ninject é de cara o mais procurado. (mais…)

[deprecated]Oragon Architecture – Por que? Pra que?

[deprecated]Oragon Architecture – Por que? Pra que?

[deprecated]

Olá, tudo bom?

Vou falar um pouco do meu projeto pessoal o Oragon Architecture. Se você me acompanha, sabe que falo bastante dele, e vou aproveitar para responder algumas perguntas que já me fizeram nos últimos dias.

 

Já fui questionado algumas vezes porque criar um framework de aplicação, uma arquitetura relativamente gorda, baseada em geração de código com base em banco e muita configuração com Spring.Net.

Bom, primeiro, o Oragon Architecture me viabilizou criar projetos que jamais seriam possíveis sem ele, no prazo que foram realizados. Esse é o principal motivador! Com ele alguns projetos de anos, conseguem ser realizados em meses, pelo simples fato de eliminar necessidade de codificação repetitiva. Quando você se preocupa apenas com o negócio deixando de lado aspectos não funcionais, tudo fica mais fluente no dia-a-dia de desenvolvimento. Gestão de Exceptions, Tratamento de erro, gestão de conexões, leak de conexões, sessões não finalizadas, tudo isso deixa de fazer parte do seu código na medida que você passa a usar os aspectos de AOP do Oragon Architecture.

O acesso a dados é bem facilitado, usando NHibernate e FluentNHibernate. Há quem questione o modelo. Bom, tive poucas chances na vida de trabalhar com bases de dados criadas do Zero, ou chances de realizar code-first. Muitas das vezes as empresas possuem equipes de DBA`s ou AD`s que são responsáveis pela modelagem do banco. Essa foi a melhor forma de me adaptar a estes cenários. Do ponto de vista do código gerado, há uma boa riqueza de detalhes na geração de código, como a criação de padrões que podem gerar facilmente nomes fluentes para bancos cheios de regras. Como uma coluna USUA_CD_USUARIO, virar CodigoUsuario, ou apenas Codigo, da mesma forma que USUA_DT_CRIACAO pode virar DataCriacao, com o case correto também. Pluralização em PT-BR e EN-US também são features interessantes da geração de código. Isso permite gerar código de uma forma bem inteligente, muito próximo do que nós mesmo modelaríamos manualmente, contemplando relações 1xN, Nx1, NxN e 1×1.

Quanto ao Spring.Net, bom, o primeiro fator que motiva na utilização dele é o fato de injetarmos modelos de dependências completas e a riqueza de features, como AOP e seus diversos helpers para outros muitos frameworks, como Quartz, RabbitMQ. Uso o Spring.Net desde 2006, uma pesquisa no google pode mostrar isso, nesse período ainda não existia WCF, e o Spring.Net já fazia abstração completa de protocolo para WebServices, Enterprise Services (COM+), Remoting e InProcess.

Aliás, essas abstrações de protocolo`me ajudaram a ver um mundo diferente, e desde então tudo que faço abstrai sempre o protocolo de comunicação. No Oragon Architecture, temos um conjunto de abstrações para plugar serviços em filas RabbitMQ, seguindo os mesmos princípios. Você implementa suas regras de negócio, o resto fica com a arquitetura. Como será a hospedagem, envelope de mensagem In/Out, tratamento de exceções, timeout, isso tudo fica a cargo da arquitetura.

O modelo desconectado do protocolo, permite que possamos desenvolver soluções com múltiplas distribuições, e permite mudar a estratégia de deploy em minutos, saindo de WCF, para WebServices, embedded, ou usando filas RabbitMQ. São muitas possibilidades com um código apenas. Nenhuma dessas mudanças exigem mudanças nos códigos e essa é a mágica dessa arquitetura: Abdicar das decisões mais complexas pelo tempo necessário para que elas obtenham o maior grau de maturidade possível. O pipeline em cima do RabbitMQ também é excelente, permite que um fluxo completo seja dividido em steps com filas de erro e filas de processamento, viabilizando uma grande escalabilidade horizontal.

Mas não são só flores, foram muitos anos construindo o projeto, evoluindo a cada parceiro e empresa que eu passava.

Muito mudou ao longo dos anos, os aspectos de AOP não trabalhavam em conjunto, agora cooperam entre si. A cada demanda nova, novas features nascem, novos conceitos são aplicados. Me orgulho de ter feito, para a BRQ um modelo de MVC, bem próximo do que há no Web API. Quando comecei a estudar Web API, joguei muito código fora, assim como quando encontrei o TopShelf. Me orgulho muito disso pois sempre que eu puder usar algo pronto, para me fornecer uma infraestrutura robusta, vou fazê-lo.

O papel do Oragon Architecture não é recriar a roda, mas coordenar as engrenagens para que se construa software mais fácil.

Muitas vezes sou questionado sobre a performance e escalabilidade da arquitetura:

A arquitetura provê uma infraestrutura robusta para o desenvolvimento corporativo, conta com soluções mais e menos performáticas/escaláveis, mas se usarmos as soluções corretas, como cache, por exemplo, podemos escalar bem mais que soluções que usam ADO.NET para acesso a dados e código 100% inline. Ganhando infinitamente no tempo de desenvolvimento. Não há mistério, cada escolha implica necessariamente em uma renúncia, mas para cada dificuldade, há um facilitador ao lado, e com um pouco de conhecimento de arquitetura, é possível chegar ao infinito!!

 

Grande abraço,

espero que gostem!

IOC / DI – Você está fazendo isso errado!

IOC / DI – Você está fazendo isso errado!

Olá, agora vou tocar em um assunto que parece uma ferida para muitos, mas considero bem básico. Infelizmente, acredito haja quem confunda estes conceitos, e por ter encontrado pela estrada alguns projetos com tais problemas relacionados à compreensão de IoC e DI, venho escrever esse post. É um tema tão cotidiano que hoje está disponível também no Macoratti*, portanto não vou explicar o conceito, mas me ater no que vejo de errado por aí. (mais…)