Tecnologia de Internet (Locaweb)

No último sábado (27/06) rolou o .Net Architets Day 2009 voltado para arquitetura de software (com foco em .Net).

Pouco ou quase nada se falou sobre uso de alguma ferramenta específicas Microsoft, até porque o foco do grupo que já existe há algum tempo é exatamente a utilização do .Net com práticas de engenharia de software e arquitertura.

O evento, segundo a organização, não teve fins lucrativos e o valor foi revertido em brindes e coffe break além de algumas outras despezas (achei muito bacana a prestação de contas apresentada pelo Giovanni, idealizador do grupo).

Estes foram os temas apresentados, com um pequeno resumo de cada palestra. De acordo com a organização, as apresentações e as filmagens estarão disponíveis no site do grupo em breve.

Programando com prazer com Domain Driven Design (DDD) – Giovanni Basi

A principal preocupação do arquiteto ou desenvolvedor de software deve ser com o futuro, ou seja, a “manutenibilidade” do sistema. Com o design baseado na lógica do domínio do cliente (DDD), tudo fica mais fácil, desde a forma de se comunicar (linguagem ubíqua) até a modelagem, desenvolvimento e manutenção do software.

Utilizando Injeção de dependência com Unity (Enterprise Library) – Leandro Daniel

O acoplamento é um problema enorme em POO. Fazer testes em uma classe de negócio que dependa de uma outra que envia e-mail, por exemplo, ou adicionar uma nova funcionalidade a um pedaço que já esteja amarrado a uma implementação é triste demais. O Unity, um dos blocos da Enterprise Library (incorporado a partir da versão 4.0), foi criado para ajudar nessa tarefa injetando a dependência quando necessário. No entanto, é preciso avaliar o uso para não tornar seu software ainda mais acoplado

ASP.Net MVC: tome seu HTML de volta – Victor Cavalcante

Nesta palestra foi feita uma comparação entre o ASP.NET MVC e Web Forms, mostrando como ficamos como, com este último, muito presos à interface e fica difícil fazer testes enquanto que, com MVC separa a lógica da apresentação ficando mais flexível e testável. Por outro lado, MVC tem um preço, é necessário colocar a mão na massa, controlar o HTML, é necessário saber programar para web.

ORM – Sendo preguiçoso com NHibernate – Juliano Oliveira

No início da palestra o Juliano trocou o título para “Sendo produtivo com NHibernate”. Este que é um dos frameworks mais conhecidos para mapeamento de objeto relacional é de grande valor na hora de desenvolver seu sistema e diminui bastante a dor de cabeça com criação de tabelas, colunas, constraints, etc. na base de dados. Foi mostrado também o NHProf uma ferramenta comercial para que funciona como o Profiler do SQL Server.

Testes: garantindo que seu código faz o que você quer – Mauricio Aniche

Uma frase que eu tenho ouvido muito ultimamente, mas, graças a Deus, a grande maioria das vezes, só como ilustração “Tá pronto, só falta testar”, foi mencionada mais uma vez. E não é difícil ouvir isso nas empresas que ainda não adotam boas práticas de desenvolvimento. Foi feita uma bela apresentação de como os testes podem ajudar tanto a evitar bugs como na qualidade e na própria codificação, pois fica fácil entender a lógica e as regras de negócio fazendo testes. O uso de ferramentas de automatização de testes como o NUnit ou o Próprio MSTest do Visual Studio, o uso de frameworks de mock potencializam a produtividade.

Valeu muito a pena participar e já estou esperando o próximo.

No último post iniciamos nossa breve visita ao “Enterprise Library 4.0” com o “Cryptography Application Block”. Neste post vamos analisar o “Unity Application Block” que é uma novidade na versão 4 da biblioteca. O “Unity” é um container de inversão de controle baseado na biblioteca “ObjectBuilder2” do “Entreprise Library” e que foi lançado como uma alternativa às já tradicionais bibliotecas “Spring.NET” (uma versão da famosa biblioteca Spring do mundo Java), “Castle Windsor”, “StructureMap”, “ObjectBuilder” etc.

Quem já utilizava o “Enterprise Library” em alguma de suas versões anteriores deve estar familiarizado com a biblioteca “ObjectBuilder”. Ela atuava no núcleo do “Enterprise Library” cuidando do gerenciamento dos objetos e apesar de não ser um “cidadão de primeira classe” (já que não era promovido como um dos conjuntos de aplicação), podia ser referenciado e utilizado diretamente pelo usuário. Muitos reclamavam de questões relativas ao design e performance da biblioteca e, a partir do feedback dos usuários e observação dos projetos da comunidade, a Microsoft refez o código e lançou o “ObjectBuilder2”. Baseado nele, foi construído o “Unity Application Block” e a novidade é que apesar de fazer parte do “Enterprise Library”, pode ser baixado separadamente através do portal CodePlex.

Conforme mencionei, o “Unity” é apenas uma alternativa a outras bibliotecas. Dito isto, podemos esperar muitas funcionalidades parecidas, algumas inéditas e algumas que faltam. A intenção deste post não é fazer uma comparação entre todas as bibliotecas disponíveis, mas visitar algumas das funcionalidades básicas do “Unity” para que seja mais fácil explorar daí pra frente.

Usando o “Unity Application Block”

Após baixar e instalar o pacote do CodePlex, vamos criar um novo ConsoleApplication no Visual Studio 2008 e referenciar as duas bibliotecas principais do “Unity” que já estão registradas no GAC da máquina: Microsoft.Practices.Unity, Microsoft.Practices.Unity.Configuration e Microsoft.Practices.Unity.ObjectBuilder2.

Para iniciarmos com um exemplo, vamos imaginar uma aplicação simples onde queremos criar um log. Podemos ter várias implementações deste “logger”, por exemplo, uma que escreve as mensagens direto no console e outra que escreve em um arquivo texto. Se fizermos com que estes dois “loggers” implementem uma interface comum, ganhamos flexibilidade por podermos especificar através de um arquivo de configuração qual gostaríamos de usar.

Esta seria a interface em questão:

public interface ILogger
{
    void Log(string message);
}

Há apenas um método que recebe a mensagem que gostaríamos de escrever. Para ela, criamos duas implementações:

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

public class TextFileLogger : ILogger
{
    public void Log(string message)
    {
        using (StreamWriter streamWriter =
new StreamWriter("log.txt", true))
        {
            streamWriter.WriteLine(message);
        }
    }
}

Se utilizarmos apenas a interface ILogger, já podemos escrever o comportamento da nossa prova de conceito:

ILogger logger;

logger.Log("Aplicação foi iniciada.");
logger.Log("Aplicação foi finalizada.");

Falta apenas inicializar o objeto logger. Para isso, utilizaremos as classes do namespace Microsoft.Practices.Unity, de forma que o método Main fica assim:

static void Main(string[] args)
{
    UnityContainer unityContainer = new UnityContainer();
    unityContainer.RegisterType(typeof (ILogger),
typeof (ConsoleLogger));

    ILogger logger = unityContainer.Resolve<ILogger>();

    logger.Log("A aplicação foi iniciada.");

    Console.ReadLine();

    logger.Log("A aplicação foi finalizada.");
}

Vamos analisar passo-a-passo o que fizemos: em primeiro lugar, inicializamos o objeto unityContainer com o construtor padrão. Depois, configuramos programaticamete o Unity através do método RegisterType. Neste caso, criamos a associação dizendo que a interface ILogger deve ser associada à implementação ConsoleLogger. Ao rodar o programa, podemos ver que as mensagens são impressas na tela. Seriam impressas no arquivo log.txt se a associação da interface ILogger fosse com a implementação TextFileLogger.

A princípio, a menos que a intenção seja aproveitar o controle do ciclo de vida dos objetos que o Unity fornece (para encapsular nossa implemenação em um singleton, ou pedir uma instância por chamada), não há muito sentido em configurá-lo programaticamente. O código equivalente a este, mas com as configurações no App.config seria o seguinte:

static void Main(string[] args)
{
    UnityContainer unityContainer = new UnityContainer();

    UnityConfigurationSection unityConfigurationSection =
(UnityConfigurationSection) ConfigurationManager.GetSection("unity");
unityConfigurationSection.Containers.Default.Configure(unityContainer);

    ILogger logger = unityContainer.Resolve<ILogger>();

    logger.Log("A aplicação foi iniciada.");

    Console.ReadLine();

    logger.Log("A aplicação foi finalizada.");
}

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="unity" type=
"Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
Microsoft.Practices.Unity.Configuration" />
  </configSections>

  <unity>
    <typeAliases>
      <typeAlias alias="ILogger"
type="ConsoleApplication1.ILogger, ConsoleApplication1" />
      <typeAlias alias="ConsoleLogger"
type="ConsoleApplication1.ConsoleLogger, ConsoleApplication1" />
      <typeAlias alias="TextFileLogger"
type="ConsoleApplication1.TextFileLogger, ConsoleApplication1" />
    </typeAliases>
    <containers>
      <container>
        <types>
          <type type="ILogger" mapTo="ConsoleLogger" />
        </types>
      </container>
    </containers>
  </unity>
</configuration>

Com este exemplo iniciamos a utilização do Unity, mas ainda há muitos recursos a explorar. Na seção de links, ao final do post, há uma lista de blogs que possuem exemplos de aplicação que estendem o que já fizemos. Uma modificação imediata que poderíamos fazer seria especificar o nome do arquivo log.txt através do próprio arquivo App.config, bastando apenas passá-lo através de um construtor da classe ConsoleLogger.