Technè

Inversão de controle (IoC) é um padrão que descreve técnicas genéricas para suportar uma arquitetura plug-in, onde os objetos podem “procurar” os outros objetos que eles necessitam para executar determinada ação.

IoC está sendo muito utilizado em projetos orientados a objeto. Conceitos como interface, herança e polimorfismo são bem presentes. O uso de IoC tem como objetivo reduzir o acoplamento, facilitar o reuso e os testes no projeto de software.

Em uma hierarquia, os módulos de nível mais alto não devem depender diretamente dos módulos de nível mais baixo. Ambos devem depender de abstrações. As abstrações não devem depender de detalhes da implementação, mas estes detalhes devem depender das abstrações. Desta forma, invertendo o controle.

A Injeção de Dependências é um caso especial do padrão IoC onde a técnica de programação é baseada em alterar o comportamento sem modificar classes internas. Além de classes independentes umas das outras por meio de abstrações, a injeção de dependências gera menor impacto para introdução de mudanças e um código mais facil de testar.

Um container de injeção de dependências é capaz de criar objetos com todas suas dependências injetadas e totalmente prontos para uso. Em geral estes containers podem ser configurados manualmente (programaticamente) ou dinamicamente (através de arquivos de configuração por exemplo).

Vamos falar neste post do uso de IoC na tecnologia Microsoft .NET.
O Unity da Microsoft foi escolhido como exemplo de container para entender melhor o uso de IoC.

O Unity suporta diversos tipos de injeção, como por exemplo: injeção por construtor, injeção por métodos gets e sets, injeção por arquivos de configuração, entre outras.

Como primeiro passo, precisamos criar uma Interface para ele.

Como segundo passo, vamos fazer o setup dele dentro do Global.asax da Aplicação Web.
OBS: Não é obrigatório fazer desta forma, é apenas uma abordagem que considero interessante e indicada por “gurus” da Microsoft.

Observem que no BuildContainer() tem um TODO para que seja adicionado o registro dos objetos.

Existem diversas formas de se registrar os objetos e cada uma está ligada a uma necessidade especifica, neste post, não irei tratar todas elas para termos oportunidade de discutir cada uma delas com mais tempo em um momento futuro.

Diante disto, vamos considerar a Injeção por Construtor utilizando a seguinte forma de registro:

unityContainer.RegisterType<INTERFACE/CLASSE ABSTRATA, CLASSE CONCRETA>();

Agora vamos olhar o código abaixo para entender o que este registro significa…

Observem que no exemplo, temos uma interface para o Logger chamada de ILogger. Temos também três implementações de Logger: uma para arquivo (FileLogger), uma para memória (MemoryLogger) e uma para banco de dados (DatabaseLogger). Além disto, existe uma Classe X que em seu construtor recebe a interface por parâmetro e fica apta a usar um dos 3 logs. Quem define qual deles será utilizado, é o registro que foi feito anteriormente no container do Unity.

Ou seja, voltando para o setup no Global.asax, em meu exemplo iremos colocar o seguinte registro:

unityContainer.RegisterType<ILogger, DatabaseLogger>();

e posteriormente faremos…

X x = container.Resolve<X>();

Neste momento o Unity irá resolver o objeto X e injetar a dependência do ILogger para a classe concreta do DatabaseLogger.

Espero que esta introdução ao IoC e Unity tenha ajudado de alguma forma… Em posts posteriores, podemos entrar em mais detalhes…

Referências:
http://unity.codeplex.com/
http://msdn.microsoft.com/en-us/library/cc440954.aspx/
http://msdn.microsoft.com/en-us/library/dd203101.aspx/

Existem várias maneiras de exportar um arquivo MS Excel utilizando .NET, a abordagem que será explicada nesse post será utilizando tags HTML com seus respectivos estilos.

A abordagem escolhida pode ser utilizada por qualquer linguagem de programação, porque esse tipo de exportação não está ligado ao framework .NET e sim ao padrão HTML, o qual ao definir no header da página qual o tipo do conteúdo, os browsers mais atuais reconhecem automaticamente o arquivo e inicia o processo de download do arquivo.

Na figura acima na linha 173 a 180 está um exemplo de como escrever o header para documentos MS Excel. Nesse tipo de exportação só é possível criar uma pasta por arquivo, portanto caso o projeto precise de uma planilha com mais de uma pasta seria melhor procurar uma outra solução.

O conteúdo que será exportado nesse caso será inserido dentro de uma ‘div‘, que é opicional, na linha 187 que possui uma string com uma ou várias tabelas HTML, com seus respectivos estilos css.

No code behind da página que vai realizar a ação de export do relatório é necessário colocar o conteúdo da página gerado no método mostrado na imagem anterior no Reponse.Write, como mostra a figura abaixo.

Na figura acima ilustra um trecho de código que configura a resposta da requisição para criar um conteúdo que seja reconhecido pelo browser como um conteúdo do MS Excel, na linha 71 é informado o nome do arquivo que será exportado, na linha 74 informando ao response que o conteúdo da página é do MS Excel, o valor da constante é ‘application/vnd.ms-excel‘ .

Na linha 76 o método da primeira figura é chamado para criar o conteúdo no formato desejado, e na linha 78 o resultado do método é passado como parâmetro para o Response.Write, que escreverá o conteúdo do relatório na página, e na linha 79 a resposta é finalizada.

Obs.: vale uma ressalva sobre CSS, nesse tipo de exportação o excel não reconhece mais de uma classe de CSS por tag, portanto, caso seja necessário utilizar mais de uma classe de CSS, utilize a classe que possua o maior conteúdo e a que possuir menor conteúdo coloque o estilo na mão.

Como sabemos algumas soluções desenvolvidas hoje pelas software houses tem algum requisito que expõe ou executa procedimentos em um ambiente distribuído. A Microsoft utiliza atualmente em um de seus pilares de desenvolvimento de software (Windows Communication (Foundation) um recurso conhecido como Callback, que permite que não só um host cliente se comunique com o servidor, mas também o caminho inverso. 

Primeiro, vamos imaginar um problema que se aplica a um ambiente distribuído, onde existe um requisito do projeto que diz que um determinado item da aplicação precisa ser monitorado constantemente, a fim de que, qualquer mudança nesse item precisa ser visualizada e reconhecida imediatamente através de outros aplicativos. 

Um exemplo prático de um sistema com esse cenário seria o monitoramento de temperatura  para reatores em uma usina nuclear nesse caso a usina está instalada na Bolívia, controlado por uma empresa brasileira com cede em Recife, onde um determinado aplicativo cliente precisa ser notificado (Como um evento) de quando a temperatura oscila, para que, de forma gráfica, possa notificar o centro de controle da empresa, nada critico somente para fins de informação. 

Abaixo veremos uma solução para esse sistema de monitoramento que atende a esse requisito, infelizmente não demostrarei passo a passo a criação e codificação de um serviço com WCF, mas vou tentar detalhar a parte de maior interesse que é o callback. 

O projeto foi feito utilizando o Microsoft .Net Framework 3.5 e o Visual Studio 2010 onde podemos encontrar uma solução com três projetos: 

• MonitoringReactor.Core (ClassLibrary) que implementa toda a lógica do sistema de monitoramento.
• MonitoringReactor.Services (WCF Service Application) que expõe nosso sistema através de um webservice.
• MonitoringReactor.Client (Windows Presentation Faundation) que é nosso aplicativo que será notificado quando a temperatura de um reator mudar.

O principal projeto que vamos utilizar é o MonitoringReactor.Services, pois ele é que implementa o callback e expõe nossas funcionalidades para outros aplicativos. Essa exposição como tinha falado anteriormente é feita através de um webservice, vamos aos detalhes dessa implementação. 

No diretório: 

> MonitoringReactor.Services
> Contracts
- IMonitorService.cs
- IMonitorServiceCallback.cs 

Encontraremos duas interfaces que descrevem as implementações do serviço, a primeira IMonitorService que descreve os métodos disponíveis no nosso webservice e IMonitorServiceCallback que descreve a implementação do callback, o callback no fim das contas é uma implementação de uma interface que o cliente é obrigado a fazer se ele quiser consumir as funcionalidades desse serviço, ou seja, o servidor vai executar uma instancia de uma classe no host cliente. Segue a duas imagens referentes a essas estruturas: 

Podemos visualizar nesse código três métodos do nosso webservice. O principal destaque é a referência explicita que está destacada no código para um contrato de callback, isso implica em dizer que quando o serviço for consumido por alguma aplicação será necessário que o aplicativo implemente esse contrato de callback IMonitorServiceCallback. Vamos dar uma olhada agora no contrato: 

A interface IMonitorServiceCallback descreve apenas 1 método TemperatureChange(string, int). É com esse método que vamos notificar a qualquer aplicativo conectado a esse serviço que a temperatura de um reator nuclear especifico foi alterada. A implementação de nosso serviço é bem simples e não vou entrar em detalhes. Existe um método IMonitorService.Subscribe(string) de nosso webservice que é muito importante para que o servidor possa se comunicar com o host cliente: 

Só reforçando a classe MonitorService é que implementa a interface IMonitorService de nosso serviço, podemos ver no método Subscribe(string) que é capturado o canal de comunicação com a chama ao método: OperationContext.Current.GetCallbackChannel<IMonitorServiceCallback>(); Com isso podemos executar os métodos que a interface do nosso callback disponibiliza. 

Obs.: É importante frisar que para que um serviço possa utilizar o recurso de callback para um host cliente, só existe dois tipos de protocolos disponíveis no WCF, são eles: WSDualHttpBinding e NetTcpBinding, ambos dispôem de comunicação dulplex. 

Basicamente a implementação de um serviço que executa callbacks no host cliente é isso. Para implementar um serviço que executa callbacks você precisará primeiro implementar a  interface que descreve os procedimentos que podem ser executados no host e capturar o canal de comunicação do servidor com o host cliente. 

Já no lado do aplicativo que vai consumir o serviço vou demostrar como é possível se conectar ao nosso webservice e implementar o nosso callback de comunicação. 

No projeto: 

> MonitoringReactor.Client
- CallbackCapture.cs 

A classe CallbackCapture, é quem implementa o nosso contrato de callback que demonstramos no projeto MonitoringReactor.Services. Basicamente, quando o método TemperatureChange dessa classe for executado, isso será o resultado do envio da notificação do servidor para o cliente, simples assim.  Mas cadê o código que faz a comunicação? Para o desenvolvedor, inicialmente isso não é motivo de preocupação, pois os próprios componente de comunicação do WCF faz isso por você, no entanto, quando existe cenários mais complexos, e que exigem algum tipo de restrição, é muito importante que o desenvolvedor tenha a expertise para trabalhar com essas configurações de comunicação e não ficar preso as configurações default: 

Código de conexão com o webservice: 

Como vocês podem notar, o desenvolvimento de um serviço com callback exige do desenvolverdor um pouco mais de conhecimento com relação ao desenvolvimento de serviços, se você está começando agora, vou disponibilizar algumas referências que pode ajudá-lo nos primeiros passos com essa tecnologia, pois o foco do post foi somente demostrar a funcionalidade de callback. Qualquer dúvida é só perguntar aqui mesmo no blog. 

Referências:
- Documentação do WCF: http://msdn.microsoft.com/en-us/library/dd456779.aspx
- Chat feito com callbacks: http://www.codeproject.com/KB/webservices/ChatRoom.aspx
- Código fonte: http://bit.ly/cO24KS 

Essa dica vale para qualquer versão do Visual Studio

Porque testar com NUnit?

Estou trabalhando em um projeto que roda tanto no Windows quanto no Linux (usando Mono), se eu usar o teste de unidade que já vem no Visual Studio estarei limitado a IDE, e lá no Linux estou usando o MonoDevelop para desenvolvimento.

Quais as minhas alternativas?

Para integrar o NUnit ao Visual Studio você tem, basicamente, duas opções: ou você compra uma ferramenta que faz isso pra você, ou você usa a interface que já vem com o NUnit e integra ela ao Visual Studio. Se alguém conhecer outra forma, eu gostaria de saber.

1) Se você optar pela primeira alternativa, você vai ter que comprar uma ferramenta como TestDriven.Net, ReSharper ou alguma outra. O problema dessas ferramentas é que elas são pagas, e eu mesmo que não quero pagar pra rodar testes de unidade. Se você já usa uma dessas ferramentas, só continue a ler se você quiser aprender como integrar o NUnit sem o auxílio delas.

2) Na segunda alternativa temos duas outras opções para integração. (a) criar o projeto de testes como um projeto executável e chamar a GUI dentro dele passando a DLL de testes como parâmetro (particularmente acho essa opção uma gambiarra e não recomendo isso pra ninguém); (b) a segunda, e mais elegante, é configurar o Visual Studio para chamar essa interface do NUnit já passando o projeto selecionado como parâmetro.

Como configurar o Visual Studio?

Você só vai precisar executar dois passos para configurar o Visual Studio. (passo 1) Ir no menu Tools > External Tools. (passo 2) Entrar com os dados segundo a imagem abaixo. Após esses dois passos, vai aparecer um novo item no menu Tools chamado “NUnit”. Você pode clicar nele para executar a GUI do próprio NUnit aplicado ao projeto corrente.

Como depurar meus testes?

Uma vez que você esteja com a GUI do NUnit aberta e rodando (rodando a interface e não o teste), você pode informar ao Visual Studio que você deseja testar aquele programa que está rodando fora. E como eu faço isso? Você vai no menu “Debug > Attach to process” e seleciona o programa do NUnit que está executando, da mesma forma que ilustrado na figura abaixo.

Agora você pode rodar seus testes de unidade usando NUnit sem ter que usar uma ferramenta de terceiros.