O que eu uso?

O que eu uso?

Olá, como vai você?

As polêmicas

Do lado de cá, continuo me metendo em polêmicas e mais polêmicas nos grupos de discussões nacionais, e nesse final de semana decidi sair desses grupos. A discussão por aqui não é muito produtiva, leva-se tempo para que as pessoas foquem no foco de uma discussão enquanto, outros fazem agressões descabidas, ou mesmo falem muita besteira. Chato isso, mas de fato, há muita gente achando que sabe, o que não sabe! (mais…)

[deprecated]Apresentação Oragon Architecture

[deprecated]Apresentação Oragon Architecture

[deprecated]

Olá,

como vai você? Bom, espero que nesse dia das mães não esteja enfurnado no computador. Bom, do meu lado a minha fica distante de mais, em muitos os sentidos, portanto, lá vamos nós!

Hoje não vou falar muito, vou compartilhar apenas uma apresentação que fiz sobre algumas features do Oragon Architecture. A maioria já é bem conhecida, mas algumas outras são novinhas. Abaixo temos a apresentação, espero que goste. (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!

Legado Versus Design – Database First e Code First

Legado Versus Design – Database First e Code First

Bom, quem acompanha o Oragon Architecture ao longo dos anos, mesmo que de forma despretensiosa, em algum momento me questiona sobre algumas decisões tomadas. Vou tentar ser breve para relatar alguns dos problemas e soluções que motivaram minhas decisões. Nesse tópico, vou falar de gestão de base de dados, Code First e Database First.

Esse assunto merecia um post inteiro, mas vou ser breve e tentar resumir em poucos parágrafos.

É comum ver nas empresas aplicações sendo construídas e desligadas, a cada ciclo de troca de diretores e gerentes. A máxima é que as aplicações vão, mas os dados ficam. Dificilmente temos ou o descarte ou a total remodelagem dos dados. Sob essa ótica, em algum momento você vai se deparar com algum cenário em que precisa construir uma nova solução em cima de um banco legado. Na minha carreira dificilmente encontrei cenários diferentes destes. Outra situação comum, é encontrar grandes empresas com regras para criação de aplicações isoladas das regras de criação e gestão de banco de dados. Geralmente empresas contam com alguns DBAs e possuem uma área de banco bem estruturada, no entanto, há muito pensamento arcaico por traz de DBAs e administradores de dados. Geralmente ou hora eu era responsável pela definição do padrão de arquitetura das aplicações ou fazia parte de um time que o fazia. Nos dois casos, o dilema de trabalhar com bases legadas ou de ter uma área que estruturava banco de dados trazia dificuldade para qualquer modelagem que não se baseasse e Database First.

As aplicações vão, mas os dados ficam!

Para suportar melhor esses ambientes, a geração de código, com base em banco, foi um aliado fenomenal. Ao longo dos anos a geração de código foi melhorando e chegamos ao ponto de não precisar de nenhuma intervenção humana no processo. Basta configurar regras e pronto, todo o código nasce a partir de um banco legado. Esse é o motivador para a ênfase em database first. Pode parecer retrógrado, mas se você não está em uma startup, com certeza fará todo o sentido pensar em algo assim.

Grande abraço!