[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]Roadmap da Reestruturação do Oragon Architecture

[deprecated]Roadmap da Reestruturação do Oragon Architecture

[deprecated]

Olá, como vai você?

Espero que esteja tudo bem! Nesse post vou falar das mudanças previstas para o Oragon Architecture nas próximas semanas. No post Oragon Architecture – A evolução e os novos desafios eu falo da evolução ao longo dos anos e do que pretendemos fazer focando no big picture do projeto. Agora é hora de especificar os detalhes que envolvem a construção do projeto. Enfim, transformar uma ideia em resultado, para isso é necessário planejar. Abaixo vamos abordar a estratégia de migração do Oragon Architecture. Espero que goste!

(mais…)

Stack e Queue também são seus amigos

Stack e Queue também são seus amigos

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).

2014-04-17_151114

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!

Stack e Queue também são seus amigos

Integrações, XML`s e NoSQL

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

  1. Usamos Xsd2Code para gerar as classes, em C# para mapeamento de todos as entidades e propriedades definidas no XSD. Gerou mais de 200 classes.
  2. 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!