![[deprecated]Oragon Architecture – Application Hosting – Suporte para Nijnect e SimpleInjector e qualquer outro container](https://gago.io/wp-content/uploads/2014/04/IOC-Frameworks.fw_.png)
por Luiz Carlos Faria | abr 22, 2014 | Open Source, Oragon Architecture
[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…)
por Luiz Carlos Faria | abr 17, 2014 | Desenvolvimento
Olá, tudo bom com você?
Espero que sim! Estou aqui para falar rapidamente de Pilhas e Filas. Bom, o C# possui no namespace System.Collections.Generic, duas classes genéricas, bem úteis, mas muito ignoradas: Stack<T> e Queue<T>.
O que você precisa saber de Queues e Stacks:
Queues implementas FIFO (First in, First Out), enquanto Stacks implementa LIFO (Last in, First Out).
Métodos e Propriedades mais relevantes
Comuns a Ambos
//
// Summary:
// Returns the object at the top of the System.Collections.Generic.Stack<T> or System.Collections.Generic.Queue<T>
// without removing it.
//
// Returns:
// The object at the top of the System.Collections.Generic.Stack<T> or System.Collections.Generic.Queue<T>.
//
// Exceptions:
// System.InvalidOperationException:
// The System.Collections.Generic.Stack<T> or The System.Collections.Generic.Queue<T> is empty.
public T Peek();
// Summary:
// Gets the number of elements contained in the System.Collections.Generic.Stack<T> or System.Collections.Generic.Queue<T>.
//
// Returns:
// The number of elements contained in the System.Collections.Generic.Stack<T> or System.Collections.Generic.Queue<T>.
public int Count { get; }
System.Collections.Generic.Queue<T>
//
// Summary:
// Adds an object to the end of the System.Collections.Generic.Queue<T>.
//
// Parameters:
// item:
// The object to add to the System.Collections.Generic.Queue<T>. The value can
// be null for reference types.
public void Enqueue(T item);
//
// Summary:
// Removes and returns the object at the beginning of the System.Collections.Generic.Queue<T>.
//
// Returns:
// The object that is removed from the beginning of the System.Collections.Generic.Queue<T>.
//
// Exceptions:
// System.InvalidOperationException:
// The System.Collections.Generic.Queue<T> is empty.
public T Dequeue();
System.Collections.Generic.Stack<T>
//
// Summary:
// Removes and returns the object at the top of the System.Collections.Generic.Stack<T>.
//
// Returns:
// The object removed from the top of the System.Collections.Generic.Stack<T>.
//
// Exceptions:
// System.InvalidOperationException:
// The System.Collections.Generic.Stack<T> is empty.
public T Pop();
//
// Summary:
// Inserts an object at the top of the System.Collections.Generic.Stack<T>.
//
// Parameters:
// item:
// The object to push onto the System.Collections.Generic.Stack<T>. The value
// can be null for reference types.
public void Push(T item);
Bom, era somente isso que eu queria passar. Vale a pena dar uma olhada em outras classes disponíveis no namespace System.Collections aconselho olhar:
System.Collections.Concurrent.ConcurrentQueue<T>
System.Collections.Concurrent.ConcurrentStack<T>
System.Collections.Generic.SortedSet<T>
System.Collections.Generic.SortedList<TKey, TValue>
System.Collections.Generic.LinkedList<T>
todos estão nos assemblies mscorlib ou System.
Era só isso!
Grande abraço!
por Luiz Carlos Faria | abr 16, 2014 | Architecture
Olá, tudo bom?
Nesse post gostaria de abordar uma solução que usei no iMusica e que pode também te ajudar com integrações baseadas em XML ou qualquer formato unquerable(neologismo). Antes de falar da solução, vou falar do problema. Nossas integrações no iMusica geralmente se dão por meio de troca de arquivos, contendo pacotes com mídia e metadados. Os metadados são armazenados em arquivos XML complexos. Independente do schema do XML usado, uns mais completos, outros mais enxutos, a quantidade de informação é colossal. O metadado do mercado fonográfico é muito extenso.
A dificuldade de manipulação desse conteúdo era gigantesco, pelos seguintes motivos:
- Segmentação do storage
- Necessidade de queries em arquivos
- Acesso a grandes volumes de informação para obter dados pontuais
Toda essa complexidade fazia parte do dia-a-dia do meu time. Não que hoje ainda não faça, mas estamos trabalhando para minimizar isso. O metadado tem um destino, sempre, a manutenção de tabelas em um SGDB. Começamos a reestruturação dos serviços redesenhando os modelos de integração em uma base intermediária no SGDB, mas ao chegarmos próximos a 100 tabelas (e não havíamos mapeado sequer a metade do schema xsd) optei por abortar a ideia. Outro maluco já havia tentado fazer isso antes, e no final das contas, essa foi a terceira iniciativa, que assim como as outras, morreu! Pensei em bases XML, mas armazenar XML é extremamente insano, principalmente se comparado a formatos mais enxutos, como json. Busquei algumas bases XML, achei o Sedna e o eXist-db mas usar XQuery não foi algo motivador. Já que estava estudando sobre NoSQL tive a ideia de pesquisar sobre outras alternativas NoSQL e o resultado foi excelente.
Talvez você esteja perguntando sobre as vantagens de usar o MongoDB:
- Queries complexas
- Armazenamento (quase que infinito)
- Schemaless (poupa muito trabalho)
Agora um desafio, salvar o XML, que diga-se de passagem, já vi chegar a 3mb no MongoDB.
A solução: Schemas e Geração de Código
- Usamos Xsd2Code para gerar as classes, em C# para mapeamento de todos as entidades e propriedades definidas no XSD. Gerou mais de 200 classes.
- Fazemos a leitura do XML com base em deserialização, e persistimos os mesmos objetos (classes geradas com Xsd2Code) no MongoDB.
Você poderia usar CouchBase, CouchDB, entre outras soluções, eu usei MongoDB.
Enfim, essa foi uma solução simples, e eficiente para o meu problema de integrações. Após a persistência no MongoDB, toda a minha infra que depende dos documentos, usa o MongoDB e nunca mais o XML original. Para integrações em formatos diferentes, fazemos parsers em XSLT para transformar do formato original para o formato utilizado na plataforma e assim a base de código para tratar esses documentos continua sendo a mesma.
Esses pensamentos ajudam muito a evitar segmentação em aplicações corporativas. O custo de manutenção é bem menor do que construir bases de código diferentes para realizar as mesmas coisas.
Esta não é a única solução nem cogito ser a melhor, mas foi a que me atendeu graciosamente! Espero que compartilhando contigo possa pelo menos abrir suas cabeça para ideias do tipo.
Um grande abraço e até mais!
![[deprecated]Oragon Architecture – Por que? Pra que?](https://gago.io/wp-content/uploads/2015/06/Oragon-Architecture-Penknife.export-5573b448v1_site_icon.png)
por Luiz Carlos Faria | abr 15, 2014 | Architecture, Open Source, Oragon Architecture
[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!
![[deprecated]Roadmap da Reestruturação do Oragon Architecture](https://gago.io/wp-content/uploads/2014/04/generico-oragon-architecture.png)