Criar e consumir Serviços REST com WCF

O que é  REST?




Representational State Transfer ou somente (REST) é uma técnica de engenharia de software para sistemas  distribuídos como a World Wide Web. O termo se originou no ano de 2000, em uma tese de doutorado escrita por Roy Fielding, um dos principais autores do protocolo HTTP.

Este conceito foi muito bem aceito e se espalhou mundialmente como uma alternativa mais simples que o protocolo SOAP e serviços baseados em WSDL. Uma evidência disso é o fato de empresas populares como o Google, Yahoo e Facebook terem adotado o REST para suas interfaces e serviços.


Antes de entender o REST, precisamos rever a essência da plataforma web. Ela é chamada assim pois a sua arquitetura disponibiliza um framework para criar e navegar através de uma rede de recursos. Um recurso pode ser qualquer coisa, um arquivo de imagem, vídeo, html ou um serviço que produza um output dinamicamente. A web possui uma arquitetura orientada a recursos.

Na web, cada recurso recebe um identificador unico, chamado URI (universal resource identifier). O tipo de URI mais comum usado na web é o URL (Uniform resource locator).
Já que um URI identifica um recurso, ele pode ser salvo para uso no futuro e para compartilhamento com outras pessoas. Por exemplo, posso enviar o URL de um site que eu gostei para meus amigos acessarem.
Agora o grande motivo para o nome WEB é o fato dos recursos conterem hyperlinks para outros recursos, criando desta maneira uma rede infinita de recursos interligados.

Quando você usa o browser para abrir um recurso da Web na verdade você está abrindo apenas uma representação daquele recurso. Ou seja, podem existir mais de uma representação para um determinado recurso. Existem muitos formatos usados na Web hoje em dia para representar recursos de uma maneira que todos os browsers sejam capazes de interpretar, entre eles podemos citar: (X)HTML, JPEG, GIF, WMV , SWF , RSS, CSS, JSON, JavaScript. Quando o browser receve uma destas representações ele a interpreta e renderiza o recurso em tela.

Conceitos Fundamentais do protocolo HTTP

O protocolo standard para web é o HTTP. Ele define um grupo padrão de métodos, status codes e cabeçalhos para permitir a interação com os recursos e as suas representações. A figura abaixo lista os métodos mais comuns

A imagem abaixo mostra os status codes do protocolo HTTP

O grande diferencial do REST é a sua enfase em uma interface uniforme entre os componentes. Sua teoria prega que generalizar e padronizar a interface dos componentes simplifica a arquitetura geral do sistema e permite mais visibilidade para as interações.
O REST define como usar essa interface uniforme através de restrições adicionais e como identificar cada um dos recursos e manipula-los através de suas representações.


Princípios do REST

Usar métodos HTTP explicitamente.
Não armazenar estado (Stateless).
Expor URIs com estrutura de diretórios.
Transferência XML, JavaScript Object Notation (JSON), ou ambos.

Como funciona?

Os serviços RESTful expoem recursos que  associados através de URIs, cujas chamadas são realizadas através de verbos HTTP.
O verbo utilizado na requisição indica para o serviço que ação deve ser realizada com o recurso, os verbos mais comuns para serem utilizados com o REST são GET, POST, PUT e DELETE

REST VS SOAP (COMPARATIVO)

Cenário Prático:

Vamos desenvolver um serviço REST para fazer o CRUD de administradores do sitema.

Passo 1 - Crie uma nova solution so seu projeto, crie uma camada Class Library para manipulação da persistência de dados (DataAccessLayer) e uma camada para definição dos modelos de objeto do dominio (DomainModelLayer).

Passo 2 - Clique na Solution e selecione Add new Project, Selecione Online Templates e faça uma pesquisa por "WCF".

Passo 3 - Selecione o projeto conforme exibido na figura abaixo e nomeie como WcfRestServicesLayer

Passo 4 - Crie um objeto no seu domínio, no nosso caso criamos a Entidade Administrador. Atenção para os marcadores [DataContract], [Serializable] e [DataMember]

Passo 5 - Agora vamos definir o contrato do nosso serviço . Na camada WcfRestServicesLayer, crie uma Interface IAdministradores com o código abaixo. Essa interface define quais métodos estarão disponpiveis no serviço e qual a URI e parâmetros necessários para cada método.

Passo 6 - Criar a classe que implementa a interface do serviço e realiza as operações de fato. Na mesma camada, crie uma classe Administradores com o código abaixo;

Lembre-se que cada um dos métodos definidos na interface IAdminstradores deve ser implementado.

Passo 7 - Registrando o serviço na aplicação. Na camada WcfRestServicesLayer,  abra o web.config e adicione o seguinte código:

Agora abra o arquivo Global.asax e adicione o código:

Consumindo o serviço.

Na sua aplicação WEB que irá consumir o serviço, adicione o seguinte código para implementar o padrão Abstract Factory para instanciar o serviço.

Agora para consumir, basta pedir a factory que forneça o serviço, por exemplo:

WCF REST com Characteres especiais na URI

Suponha uma aplicação que consome serviços WCF REST, e que por algum motivo, precisa passar como chave characteres especiais, por exemplo:

Serviço - http://servico.com/Produtos/{key1}/{key2}

Vamos chamar o serviço da seguinte maneira: http://servico.com/Produtos/Livro/SN#908762

Repare que o número de série do livro sendo pedido contém o character especial '#' .

Usamos o código abaixo para consumir o serviço:

public void BuscarProduto()
{
               var factory = Services.Factory.Produtos();              
                factory.Get(p.Tipo, p.ID);
}

public static class Factory
    {
        private static  string GetUri(string serviceKey)
        {

            return  System.Configuration.ConfigurationManager.AppSettings[serviceKey];
        }
        public static IProdutos Produtos()
        {
            string uri = GetUri("RESTServiceProdutos");
            var factory = new WebChannelFactory<WcfRestServicesLayer.Administrativo.Usuarios.IProdutos>(new Uri(uri));

            return factory.CreateChannel();
         
        }
    }

 Se algum dos charcteres %,&,*,:,<,>,+,#, /, ?,\  estiver contido na chave no momento em que o método factory.Get for executado, o ASP.NET retorna um erro 400 Bad Request ou 404 Not Found

Existem vários motivos para isso acontcer, mas o motivo principal é a politica de segurança do asp.net.  O asp.net está na verdade se defendendo de possíveis tentativas de injeção de código e ataques ao seu serviço. 

Permitir estes characteres nas chaves é possível sim, mas não é recomendado pois deixaria o seu serviço vulnerável.

Para permitir os characteres especiais temos os passos abaixo:

Para permitir os chars %,&,*,:,<, e > insira no arquivo web.config:

<httpRuntime requestPathInvalidCharacters="" requestValidationMode="2.0"/> 
<pages validateRequest="false"/>

Para permitir o char +  adicione

<system.webServer> 
  <security> 
    <requestFiltering allowDoubleEscaping="true" /> 
  </security> 
</system.webServer>

Para liberar o char #, ?, / e \ é necessário escrever alguma espécie de Parser (conversor)

 e adicioná-lo ao construtor do seu serviço e depois modificar o web.config

Abaixo segue um exemplo de parser escrito pelo Peter Tian (http://social.msdn.microsoft.com/profile/peter%20qian%20-%20msft/?ws=usercard-hover)

Ele própio não recomenda a utilizção deste código, é apenas uma prova de conceito e pode danificar seus servidores de produção.

public Produtos()

{

    string uri = HttpContext.Current.Request.Url.OriginalString; 
    StringBuilder replaceUri = new StringBuilder();

    bool inquote = false; 
    for (int i = 0; i < uri.Length; ++i) 
    { 
        switch (uri[i]) 
        { 
            case '\'': 
                replaceUri.Append(uri[i]); 
                inquote = !inquote; 
                break; 
            case '#': 
            case '\\': 
            case '/': 
            case '?': 
                if (inquote) 
                { 
                    replaceUri.AppendFormat("%{0:X}", (int)uri[i]); 
                } 
                else 
                { 
                    replaceUri.Append(uri[i]); 
                } 

                break; 
            default: 
                replaceUri.Append(uri[i]); 
                break; 
        } 
    }

}

<configSections> 
    <section name="uri" type="System.Configuration.UriSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> 
</configSections> 
<uri> 
    <schemeSettings> 
        <add name="http" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/> 
        <add name="https" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/> 
    </schemeSettings> 
</uri>

Antes de tentar aplicar os work-around mencionados acima, você deveria rever a arquitetura da sua aplicação. A recomendação é que não existam characteres especiais na URI, por medidas de segurança.

Design Patterns - Lazy Load

Neste post irei discutir um dos padrões EAA mais comuns hoje em dia em aplicações orientadas a dados, o padrão "Lazy Load".

Carregar dados do seu banco de dados para a memória e montar um objeto parece ser uma coisa muito simples. Quando trazemos os dados para memória, supostamente teremos um ganho na performance da aplicação.

Parece simples, mas não é. Hoje em dia a maioria das aplicações trabalham com objetos complexos, classes que contém tipos complexos dentro de si, ou seja objetos dentro de objetos. Isso gera uma cadeia de dados enorme dependendo do design do seu modelo.

Geralmente quando carregamos um objeto a partir do banco de dados,  todos os objetos relacionados a ele também são carregados em memória. Do ponto de vista do DBA esta é uma boa prática pois evita múltiplos acessos a base de dados. Do ponto de vista do programador esta prática facilita o desenvolvimento, pois quando ele for usar o objeto não vai precisar carregar todos os objetos explicitamente.


Quando pensamos no ponto de vista do administrador do servidor de aplicação, esta prática pode trazer mais problemas do que benefícios. Ao adotá-la estaremos alocando em memória objetos que, na maioria das vezes, não serão utilizados. Quando pensamos em aplicações multi-thread esta memória desperdiçada pode se tornar um problema enorme.


O padrão Lazy Load consiste em interromper este processo de carregamento dos objetos por um momento, deixando um marcador na estrutura do objeto que indicará que seus dados devem ser carregados. Esta carga só ocorrerá quando o objeto for utilizado de fato.


Existem 4 variações principais do padrão Lazy Load.
1- Lazy Initialization : Usa um marcador especial para indicar que o campo não foi carregado. Cada acesso ao campo vai checar o marcador e carregar o campo caso necessário.
2- Virtual Proxy:  Um objeto que implementa a mesma interface do objeto real. A primeira vez que um de seus métodos é chamado ele carrega o objeto real e delega.
3- Value Holder: Consiste um criar um método GetValue() no objeto. O cliente irá chamar o método e ele se encarrega de carregar o objeto na primeira chamada.
4- Ghost: É o objeto real, sem os dados preenchidos. A primeira vez que você chamar algum método, o objeto é carregado.


É comum vermos este padrão em algumas ferramentas de persistência como o LINQ to SQL e o Entity framework. Inclusive é possível definir quais propriedades devem aplicar este padrão em cada um dos seus objetos. No exemplo abaixo setamos a partir da propriedade Delay Loaded em um diagrama ORM do LINQ to SQL.

Neste exemplo de código abaixo temos o Lazy Loading aplicado no Entity Framework.  Nele, temos 10 contatos dos quais o usuário do programa irá selecionar um. Iremos carregar os pedidos do contato selecionado. Se o Lazy Loading não estivesse habilitado, nenhum dos pedidos seriam carregados pro contato.

Fontes:


http://msdn.microsoft.com
http://martinfowler.com

Aplicando os padrões "Repository" e "Unity of Work"

No último post, abordei uma maneira de construir aplicações persistentes usando o entity Framework Code First Library. Hoje irei mostrar como podemos aplicar os padrões "Repository" e "Unity of Work" nestas aplicações, mesmo que não tenhamos o modelo do banco pré-definido.

O Padrão Repository:


Media as camadas de domínio e mapeamento de dados usando uma interface de coleção, para acessar objetos do domínio. Utilizado para atingir um ou mais dos seguintes objetivos:

·         Maximizar a quantidade de código que pode ser testada com  automação e isolar a camada de dados para suportar os testes.
·         Você pode acessar a fonte de dados de diversas localidades e deseja aplicar gerenciadores centrais, regras de acesso consistentes e lógica.
·         Implementar e centralizar uma estratégia de cache para a fonte de dados.
·         Melhorar a manutenção do código e a legibilidade.
·         Usar entidades fortemente tipadas para que você possa identificar os problemas em tempo de compilação em vez de em tempo de execução.
·         Associar um comportamento com os dados relacionados. Por exemplo, você deseja calcular campos ou impor relações complicadas ou aplicar regras de negócios entre os elementos de dados dentro de uma entidade.
·         Você deseja aplicar um modelo de domínio para simplificar a lógica de negócios complexos.



O Padrão Unity Of Work:


Um dos padrões de design mais comuns em EAA, este padrão "mantém uma lista de objetos afetados por uma transação e coordena a escrita de alterações e a resolução dos problemas de concorrência.".

Este padrão aparece em quase todos os frameworks de persistência mais comuns no mercado de hoje. Por exemplo: a interface ITransaction em NHibernate, a classe DataContext no LINQ to SQL, e a classe ObjectContext no Entity Framework.

Se você fosse construir o seu próprio Unity of Work, seria provavelmente algo parecido com esta interface:
public interface IUnitOfWork {
  void MarkDirty(object entity);
  void MarkNew(object entity);
  void MarkDeleted(object entity);
  void Commit();
  void Rollback();
}
Sua classe deve conter métodos para marcar entidades como alteradas, novas ou excluídas e para confirmar ou reverter todas as mudanças.
De certa forma, você pode pensar no Unit of Work como um lugar para despejar todo o código de manipulação de transação.
As responsabilidades da Unidade de Trabalho são:
Gerenciar as transações.
Ordenar as inserções de banco de dados, exclusões e atualizações.
Impedir duplicação de atualizações.



Aplicação Prática:
Desta vez vamos construir um projeto que será desenvolvido por uma equipe. Vamos usar o team Foundation System como controlador de versão do nosso código.

01 - Abra o Visual Studio 2010, clique em File > New > Team Project.

02 - Escolha um nome para o projeto e o template de desenvolvimento (Agile ou PMP).
03 - Escolha "Create an empty source control folder" e clique em Finish.

04 - Abra seu projeto no Source Control Explorer
05 - Crie as pastas para controle de branching. Eu sempre crio as seguintes pastas:
Dev: Contém os branchs criados para desenvolvimento.
Main: Conttém o Trunk Principal da aplicação
QA: Sempre que o código é promovido para o ambiente de homologação criamos um novo branch nesta pasta e dividimos em Original e Fixes.
Prod: Sempre que o código é promovido para o ambiente de produção criamos um novo branch nesta pasta e dividimos em Original e Fixes.

06 - Crie uma pasta com a data atual dentro do folder Dev e mapeie o diretorio raiz do projeto para um folder local.
07 - Crie uma nova "Empty Solution" neste folder, no meu caso escolhi o nome PeopleOrganizer
08 - Adicione a solution recém criada um projeto "Class Library" com o nome DataAccessLayer.
09 - Crie no projeto DataAccessLayer os seguintes diretórios:
DataContexts
Model
Repositorios
UnityOfWork
10 - Adicione a referência a biblioteca Microsoft ADO.NET Entity Framework Feature CTP5 (ver post anterior)
11 - Adicione ao diretório UnityOfWork uma classe Base.cs, ela será responsável por fornecer uma classe base para implementação do padrão Unity Of Work em N datacontexts. Ela deve conter  o seguinte código:

12 - Adicione ao diretório Repositorios um novo diretório chamado Base.
13 - Neste diretório adicione uma classe IRepositorio.cs, ela será responsável por definir o contrato básico de todos os repositórios do projeto. Ela deve conter  o seguinte código:

14 - Ainda no mesmo diretório adicione uma classe Repository.cs, ela servirá como classe base para nossos repositórios,  implementando IRepository e um DataContext genérico através da injeção de dependência no construtor. Segue o código abaixo:

15 - Agora vamos criar uma classe POCO que representa uma entidade no nosso modelo. Dentro da pasta Model, crie uma sub-pasta chamada Core e dentro desta uma pasta chamada Autenticacao.

16 - Adicione uma referência a System.ComponentModel.DataAnnotations ao projeto.

17 - Dentro da pasta Autenticacao, crie uma classe Usuario.cs com o seguinte código

18 - Agora vamos criar um repositório para a entidade Usuario. Dentro da pasta Repositorios, crie uma pasta Core, dentro desta pasta crie uma classe Usuarios com o código abaixo.

19 - Agora vamos criar nosso Contexto e a unidade de trabalho responsável por administra-lo. Dentro da pasta DataContexts, crie uma pasta Core e dentro dela uma classe Context.cs com o seguinte código

20 - Crie agora uma classe UnityOfWork.cs  , que será responsável por administrar todas as operações feitas no contexto Core. Segue abaixo o código.

21 - Podemos criar o método de testes abaixo para validar nosso modelo. (Crie um App.config para informar a connection string)

22 - Após executar o teste, vemos o resultado positivo e o registro incluido no banco de dados recém criado pelo EF.

A estrutura final do projeto deve ficar parecida com a imagem abaixo:

Entity framework - Code First Development

O Entity Framework - EF, é um conjunto de tecnologias da ADO .NET que permite aos desenvolvedores a criação de aplicações persistentes através da programação direcionada a um modelo conceitual ao invés da programação direcionada diretamente a um banco de dados relacional, eliminando a maioria do código de acesso a dados que os desenvolvedores precisam escrever em suas aplicações.

O Entity Framework possui portabilidade para os mais variados bancos de dados, concorrendo diretamente com o NHibernate. Ele tem como diferencial as várias ferramentas visuais e recursos nativos do Visual Studio, sendo a referência da Microsoft no contexto do mapeamento objeto/relacional.

Principais benefícios:

• Aplicações podem ser construídas com base no modelo conceitual, incluindo tipos com herança, membros complexos e relacionamentos entre si.
• Aplicações não dependem mais de códigos e estruturas presentes na camada responsável pelo armazenamento de dados.
• Os mapeamentos entre o modelo conceitual e o schema de armazenamento pode ser modificado sem que o código da aplicação precise ser alterado. 
• Desenvolvedores podem trabalhar com um modelo de objetos consistente que pode ser mapeado para vários schemas de armazenamento e implementado em banco de dados diferentes.
• Multiplos modelos conceituais podem ser mapeados para um único schema de armazenamento.

Uma das abordagens de design mais comuns nas aplicações de hoje é a divisão da aplicação em 3 partes: modelo conceitual, modelo lógico e modelo físico.

1. Modelo Conceitual: Define as entidades e relacionamentos no sistema. 
2. Modelo lógico: Consiste em normalizar as entidades e relacionamentos em tabelas e chaves em um banco de dados relacional. 
3. Modelo físico: Aborda as capacidades de um engine de banco de dados em particular, especificando detalhes de armazenamento, tais como particionamento e indexação.

O modelo físico geralmente é gerenciado pelos DBAs, no intuito de melhorar a performance do banco de dados, os progamadores no entanto limitam-se a trabalhar na definição do domínio e do modelo lógico, escrevendo querys e stored procedures.

Muitas equipes de desenvolvimento preferem, ao invés de criar o modelo conceitual primeiro, começar o desenvolvimento a partir do modelo lógico, criando as tabelas e chaves no banco de dados. O maior problema desta abordagem é que não existe na aplicação nenhum tipo de controle que garanta que as modificações feitas no modelo conceitual serão refletidas no banco de dados.



Quando o Entity Framework foi lançado com o SP1 do .NET 3.5, os desenvolvedores passaram muito feedback sobre melhorias e correções. A microsoft recebeu este feedback e trabalhou muito para melhorar o Entity Framework no .NET 4, uma dessas melhorias será discutida neste artigo:  POCO SUPPORT (PLAIN OLD CLR OBJECTS)

POCO vem do termo POJO - Plain Old Java Object - utilizado pela comunidade Java. São classes que não implementam interfaces específicas de um framework, mas podem implementar métodos e comportamentos. O problema das classes possuírem dependências de algum framework específico é a dificuldade em testá-las e dar manutenção, torna-se muito complicado utilizar estas classes em outros projetos. Com a utilização de classes POCO esse tipo de problema não ocorre.

O desenvolvimento "Code-First" traz para os desenvolvedores os seguintes benefícios:

• Para definir os objetos de modelo, basta escrever classes simples, sem a necessidade de classes base
• Permite a persistência de banco de dados sem que seja necessário configurar nada explicitamente 
• Opcionalmente, substituir a persistência baseada em convenção e usar uma API de código fluente para personalizar completamente o mapeamento de persistência.

Para habilitar o "Code-first" no Entity Framework você precisa fazer o download de uma biblioteca a parte ( http://www.microsoft.com/en-us/download/details.aspx?id=18116 )

Agora vamos a um pequeno exemplo prático do funcionamento das classes POCO e da biblioteca System.Data.Entity.CTP:

Vamos criar um projeto chamado CodeFirstSolution e adicionar uma camada chamada DataAccessLayer que contém as classes listadas na imagem abaixo:

Repare que o nosso modelo contém 2 entidades: Livro e Autor.  Existe um relacionamento de 1 para N entre as duas.

Além das nossas duas classes POCO definidas (Livro e Autores), vamos criar uma classe para adiministrar a persistência dos objetos no banco de dados. Vamos chamar a classe de "Contexto". Repare que ela é herdeira da classe base DbContext.
As classes DbContext e DbSet usadas fazem parte da biblioteca Code-First. Você precisa adiconar uma referência a dll  System.Data.Entity.CTP que foi instalada no diretório" \Arquivos de Programas\Microsoft ADO.NET Entity Framework Feature CTP5\Binaries" para referenciar essas classes.  Após adicionar a referência, inclua a diretiva “using System.Data.Entity” na sua classe.

Agora vamos adicionar uma nova camada, um projeto do tipo Console Application, para testar o nosso modelo conceitual e verificar a criação do banco de dados a partir do código.

Após adicionar a camada ConsoleTests, adicione um arquivo app.config que contenha uma connection string apontando para o servidor do banco de dados. Repare que a connection string deve ter o mesmo nome da nossa classe "Contexto" (padrão do entity framework).

Adicione as propiedades "Trusted_Connection=False;Persist Security info=True;" a sua connection string caso você receba o seguinte erro: "".This operation requires a connection to the 'master' database. Unable to createa connection because the original database connection has benn opened and credentials have been removed from the connection string."

Agora vamos escrever um programa para inserir um novo livro na base de dados. No nosso caso, o banco de dados nunca foi criado, quando executarmos a aplicação o Entity framework vai se encarregar de gerar o schema do banco de dados com base na connection string informada.

Após executar o programa, podemos verificar o banco de dados criado automaticamente:

Repare que o Entity Framework além de criar as duas tabelas que definimos com as classes POCO, também criou a tabela EdmMetadata, responsável por manter o registro dos modelos usados para gerar o banco de dados. Caso haja alguma modificação nos modelos, o entity framework saberá com base nos dados desta tabela.
As chaves necessárias para estabelecer o relacionamento entre nossas entidades também foram criadas automaticamente:

Nas grandes empresas, os processos de desenvolvimento são o que garantem a sincronia entre a aplicação e o banco de dados. Geralmente o desenvolvedor precisa preencher algum tipo de formulário que será encaminhado ao DBA para que este possa realizar a alteração necessária.  Agora imagine que por algum motivo, a alteração feita e testada no ambiente de desenvolvimento só recebeu autorização para ser publicada em produção um ano depois.  É preciso que o DBA tenha acesso ao mesmo formulário enviado pelo programador um ano atrás, caso contrário os requisitos da alteração não podem ser atendidos.

Como podemos estabelecer um controle entre a versão do modelo lógico gerado automaticamente e o modelo conceitual que definimos na nossa aplicação? O EF é capaz de apontar qualquer alteração feita no modelo conceitual desde que o banco de dados foi gerado pela última vez, a partir da tabela EdmMetadata.

Para verificar este controle, vamos voltar ao exemplo e modificar a classe Autor para incluir a propriedade Cpf, como mostra a figura abaixo.

Quando executarmos nossa aplicação receberemos o seguinte erro:

A mensagem nos diz basicamente que temos as seguintes opções:

Atualizar o banco de dados manualmente.
Excluir o banco para que ele seja recriado pela aplicação.
Deixar que o Entity Framework seja responsável pelas atualizações necessárias.

Vamos alterar o código do nosso programa para fazer com que o EF atualize o banco de dados automaticamente. Adicionamos apenas uma linha de código, como mostra a figura abaixo.

Quando executarmos o programa, o método System.Data.Entity.Infrastructure.DataBase.SetInitializer() vai atualizar o banco de dados com base nas modificações existentes no modelo. A figura abaixo mostra a tabela Autores atualizada após a execução.

Fontes:

http://www.macoratti.net
http://msdn.microsoft.com
http://weblogs.asp.net/scottgu

Padrão Service Locator

Conforme prometido no post anterior (http://levyfialho.blogspot.com.br/2012/07/inversao-de-controle-dependency.html), este artigo pretende demonstrar como funciona o padrão Service Locator, suas vantagens e desvantagens.

Vamos supor um cenário onde temos uma loja que recebe pedidos de seus clientes, valida os dados do pedido e solicita a entrega.

Temos uma classe Loja no projeto. Para manter a coesão da classe iremos isolar as regra de negócios para validar o pedido e também a regra responsável pela entrega do pedido.

Iremos criar dois serviços diferentes:

ValidatorService : Responsável por fazer toda a validação do pedido.

ShippingService : Responsável por fazer a entrega do pedido.

Repare que esta estrutura faz com que existam duas dependências na nossa classe loja, conforme mostra a figura abaixo:

Esta situação tem os seguintes problemas:

• Para substituir ou atualizar as dependências  você precisa alterar o código da classe Loja.
• As implementações das dependências tem que estar disponíveis em tempo de compilação.
• Suas classes são difíceis de testar de forma isolada, porque eles têm referências diretas a dependências que não podem ser mockadas.
• Suas classes contem código repetitivo para criar, localizar e gerenciar suas dependências.

Para resolver a situação acima podemos aplicar o pattern Service Locator. Entre os principais motivos para aplicarmos este pattern, podemos citar:

• Você quer separar a classe Loja de suas dependências para que essas dependências possam ser substituídas ou atualizadas com alterações mínimas no código.
• A implementação concreta das dependências não é conhecida em tempo de compilação.
• Você quer ser capaz de testar as suas classes de forma isolada.
• Você não quer que a classe Loja seja responsável por localizar e gerir as dependências.

Aplicando o Service Locator..

Este padrão consiste na criação de uma classe chamada Locator que funciona como um repositório de serviços. Quando a classe Loja precisa solicitar um serviço, ela acessa um método da classe Locator que inicializa o serviço caso seja necessário e retorna um objeto que implementa a interface necessária. É comum termos Service Locators que inicializam serviços em tempo de execução, de acordo com os parâmetros passados pelo solicitante, ou através de arquivos de configuração.

Segue abaixo um UML de exemplo:

 Seguindo o nosso exemplo, temos agora a classe Loja requisitando os serviços de validação e entrega do pedido através do service locator. Os itens do diagrama estão descritos abaixo.

IValidatorService e IShippingService: 
Estas interfaces definem o contrato das classes de serviços que as implementam. As classe Loja  usa estas interfaces para reduzir o acoplamento. Com isso você pode mockar objetos que implementam essas interfaces para gerar seus casos de teste.

ValidatorService e ShippingService: 
Estas duas classes são implementações concretas das  interfaces. Estes são os tipos de objetos que serão fornecidos pelo Locator.

Locator:
A classe Locator é responsável por armazenar referências aos serviços instanciados pelo Starter e fornecer estes serviços quando forem requisitados pela classe Loja que acessa os métodos GetValidator e GetShipper. A classe tem outros membros que implementam o padrão de projeto singleton para garantir que exista sempre apenas um objeto instanciado.

ServiceStarter:
Esta classe é responsável por inicializar os objetos de serviço e armazená-los no localizador de serviços.

Loja:
A classe Loja é um consumidor das classes de serviço. Quando ela precisa acessar uma de suas dependências, recorre ao localizador de serviços.


Abaixo segue o código C# para implementação:

O exemplo acima demonstra um Service Locator estático. É possível também construir um locator que permita que você armazene qualquer tipo de serviço que você precise e faça as suas escolhas em tempo de execução. Neste caso, o Locator usa um mapa ao invés de campos para cada um dos serviços, e disponibiliza métodos genéricos para startar e retornar os serviços para o consumidor.

Service Locator vs Dependency Injection


Ambas as implementações fornecem desaclopamento da aplicação pois em ambos os casos o código da aplicação é independente da implementação concreta da interface do serviço. Como escolher entre os dois padões?

A diferença importante entre os dois padrões é como que o serviço é fornecido para a classe solicitante. Com o Service Locator a classe requisita explicitamente o serviço através de uma mensagem para o Locator. Com a injeção de dependência não existe requisição, o serviço simplesmente "aparece" na classe - daí a inversão de controle.

Inversão de controle é uma característica comum dos frameworks, mas é algo difícil de entender, principalmente em grandes projetos ou quando temos muitos desenvolvedores, e leva a problemas quando você está tentando debugar.

A principal diferença é que, com o Service Locator cada consumidor depende do localizador. O localizador pode esconder dependências para outras implementações, mas você precisa ver o localizador. Sendo assim, a decisão entre Service Locator e Dependency injection vai depender se esta dependência é um problema.

Geralmente, os desenvolvedores preferem usar injeção de dependência pois este padrão facilita o debug e os testes da aplicação, com injeção de dependência é mais fácil ver quais são as dependências do seu componente, principalmente nos casos de Contructor Injection.

Service Locator é um problema , se você está desenvolvendo um componente que será usado em aplicação de terceiros. O problema com o Service Locator é que ele esconde as dependências de uma classe, provocando erros em tempo de execução, em vez de em tempo de compilação.

 O padrão Service Locator torna o código mais difícil de manter porque você nunca sabe ao certo o nível de complexidade das alterações que você está fazendo(já que ele esconde as dependências). O compilador pode oferecer muita ajuda  aos desenvolvedores  quando usamos injeção de dependência, mas praticamente nenhuma assistência está disponível para APIs que dependem de um Service Locator.

Fontes:

http://martinfowler.com
http://blog.ploeh.dk
http://msdn.microsoft.com
http://www.blackwasp.co.uk

Inversão de Controle - Dependency Injection

Hoje em dia é essencial para todo programador adotar boas práticas no processo de desenvolvimento de software. O mercado demanda cada vez mais qualidade enquanto os prazos e custos devem ser cada vez menores.

Usar padrões de arquitetura facilita o entendimento, o desenvolvimento e a manutenção do código. Devemos ter sempre em mente que nossas classes devem ter um baixo nível de acoplamento e um alto nível de coesão, mas como podemos definir isso?

 Acoplamento

• Acoplamento é o nível de dependência que pode existir entre duas ou mais classes;
• Uma classe com acoplamento fraco não é dependente de muitas classes para fazer o que ela tem que fazer;
• Uma classe com acoplamento forte depende de muitas outras classes para fazer o seu serviço;

Coesão

• A coesão Mede o quanto que uma classe e seus métodos fazem sentido;
• Uma classe com alta coesão possui responsabilidades bem definidas e são difíceis de serem desmembradas em outras classes;
• Uma classe com baixa coesão possui muitas responsabilidades, geralmente que pertencem a outras classes, e podem ser facilmente desmembradas em outras classes;

Neste artigo pretendo explicar através de alguns exemplos um dos padrões de desenvolvimento mais comuns atualmente: Inversão de Controle.

"Na engenharia de softwares, Inversão de controle é uma prática de progamação orientada a objetos aonde o controle de chamadas dos métodos é invertida em relação a programação tradicional, ou seja, o controle não é determinado diretamente pelo programador."

Muitas pessoas confundem Inversão de controle com injeção de dependência. Devemos observar que a inversão de controle é um conceito. Através da injeção de dependência, podemos atingir a inversão de controle, mas existem outras maneiras.

Para entender melhor o conceito de inversão de controle, precisamos de um exemplo. Antigamente, era muito comum encontrar programas do tipo:

print "Digite seu nome";
read nome;
print "Digite seu cpf";
read cpf;
SalvarDados();

Repare como o programa escrito controla as interações do usuário.
Para aplicar a inversão de controle em um programa como esse poderíamos fazer o seguinte:

when the user types in CAMPO1, read NOME;
when the user types in CAMPO2, read CPF;
when the user clicks SALVAR, call SalvarDados();

Ao utilizar os event handlers o controle da interação deixa de pertencer ao programa, e cabe ao usuário definir quando e em que ordem o programa deve salvar os dados.

"Early user interfaces were controlled by the application program. You would have a sequence of commands like 'Enter name', 'enter address'; your program would drive the prompts and pick up a response to each one. With graphical (or even screen based) UIs the UI framework would contain this main loop and your program instead provided event handlers for the various fields on the screen. The main control of the program was inverted, moved away from you to the framework." - Martin Fowler

Para atingir a inversão de controle podemos seguir dois passos básicos:

1 - Separar  a parte O QUE FAZER  da parte QUANDO FAZER
2 - Garantir que a parte QUANDO FAZER saiba o mínimo possível sobre O QUE FAZER e vice-versa.

Existem várias técnincas para cada um desses passos de acordo com a linguagem de programação sendo utilizada. Neste artigo iremos discutir uma delas:  Injeção de Dependência.

Exemplo ilustrativo:

Problema: Existe uma classe em seu projeto que possui dependências de serviços ou componentes  especificados em tempo de design. Neste exemplo, ClassA tem dependências em ServiceA e ServiceB.

Esta situação tem os seguintes problemas:

Para substituir ou atualizar as dependências (ServiceA e ServiceB, você precisa alterar o código de suas classes de origem (ClassA).
As implementações concretas das dependências tem que estar disponíveis em tempo de compilação.
Suas classes são difíceis de testar de forma isolada, porque eles têm referências diretas a dependências que não podem ser mockadas.
Suas classes contem código repetitivo para criar, localizar e gerenciar suas dependências.

Para resolver a situação acima podemos aplicar o pattern de Injeção de Dependência.

Conceito básico: Não instancie as dependências explicitamente em sua classe. Em vez disso, declare dependências em sua definição de classe e isole a implementação de um objeto da construção do objeto do qual ele depende. 


Podemos implementar a injeção de dependência das seguintes maneiras:

• Injeção via Construtor;
• Injeção via Propriedades;
• Injeção via Interface;
• Injeção via Framework;
• Injeção usando Unity Application Block (http://www.microsoft.com/en-us/download/details.aspx?id=19372 );

public class Livro

{

   private Autor _autor;

   public Livro()

   {

      _autor = new Autor();

   }

   public string NomeDoAutor(Pedido pedido)

   {

      return _autor.Nome;

   }

}

No cenário acima, a classe Livro possui uma dependência da classe autor. Repare que a classe livro implementa a construção da classe autor gerando um FORTE acoplamento entre as duas classes, ou seja qualquer alteração na classe autor irá afetar diretamente a classe Livro. Podemos aplicar a injeção de dependência de maneiras diferentes:

Constructor Injection:  Consiste em passar as dependências de um objeto para o seu construtor.

public class Livro
{
   private Autor _autor;
   public Livro(Autor autor)
   {
      _autor = autor;
   }
   public string NomeDoAutor(Pedido pedido)
   {
      return _autor.Nome;
   }
}

Nesta implementação a classe Livro não tem mais a responsabilidade de criar uma instância de Autor.Como a classe Autor é criada não importa mais, ela apenas recebe uma instância e utiliza.

Se a classe Autor for alterada,  a classe Livro fique imune a essas alterações pois depende apenas do objeto que foi injetado no seu construtor.

Uma da maiores desvantagens desta abordagem é o fato de que a classe Livro não pode ter um construtor padrão.

Para suportar a injeção de dependência sem precisar modificar o construtor da classe Livro, podemos usar a abordagem de injeção de dependência por propiedades (get / set).


Setter Injection:  Esta abordagem não força a dependência ser passada via construtor. Ao invés disso, as dependências são definidas em propiedades que podem ser acessadas publicamente através dos Getters e Setters.

public class Livro
{
   private IAutor _autor;
  
   public Livro()
   {
     //Construtor independente
   }
   


    public IAutor Autor {
    get {
            if (_autor == null) {
                 throw new Exception("Autor não inicializado");
             }
          return _autor;
          }
          set { _autor = value; }
     }
}

Este é o método mais comum  para implementar a injeção de dependência, ele permite a extensão de recursos ou serviços que serão criados o mais tarde possível e somente quando necessário.

A desvantagem desta abordagem é que os objetos são expostos publicamente e isso quebra a regra de encapsulamento da programação orientada a objeto.

Interface Injection: Utiliza uma interface comum que outras classes necessitam implementar para injetar a dependência.

Unity Application Block:  É um container de inversão de controle baseado na biblioteca “ObjectBuilder2” do “Entreprise Library” e que foi lançado como uma alternativa às bibliotecas “Spring.NET”, “ObjectBuilder” etc. Ele facilita a criação de aplicativos de baixo acoplamento e fornece aos desenvolvedores as seguintes vantagens:

• criação de objetos simplificados, especialmente para estruturas de objetos hierárquicos e dependências.
• abstração dos requisitos, o que permite aos desenvolvedores especificar dependências em tempo de execução ou por arquivos de configuração e simplificar a gestão de interesses transversais.
• aumento da flexibilidade, adiando a configuração do componente para o container.
• capacidade de localização de serviços, o que permite aos clientes armazenar em cache o  container.

Existe um ótimo exemplo de projeto utilizando o UAB, http://www.codeproject.com/Articles/42524/A-basic-introduction-to-the-Unity-Application-Bloc

Baseado neste projeto podemos descrever o seguinte exemplo:  Imagine que desejamos criar uma classe "Historico" que tem a capacidade de escrever linhas de texto através do método Escrever(string texto).

Este método irá receber o texto a ser escrito como parâmetro e escrever em 3 tipos de recipientes diferentes, de acordo com a implementação do escritor que ele contém. Os recipentes são: Console, Arquivo ou EventViewer

Existe uma dependência entre as classes "Historico" e "IEscritor", como podemos ver no código abaixo:
public class Historico
{


    private IEscritor _escritor;


    public Historico(IEscritor escritor)
    {
        _escritor = escritor;
    }


    public void Escrever(string msg)
    {
        _escritor.Write(msg);
    }
}

public interface IEscritor
{
    void Write(string msg);
}


Temos abaixo as classes que implementam a interface IEscritor, cada uma escreve em um tipo diferente de recipiente.

public class ConsoleWriter : IEscritor
{
     public void Write(string msg)
    {
        Console.WriteLine(msg);
        Console.ReadLine();
    }


   
}
public class FileWriter : IEscritor
{
     public void Write(string msg)
    {
        using (StreamWriter streamWriter = 
               new StreamWriter("c:\\TestUnity.txt",true))
        {
            streamWriter.WriteLine(msg);
        }
    }
  
}
public class EventViewerWriter : IEscritor
{
    public void Write(string msg)
    {
        EventLog.WriteEntry("TestUnity", msg, 
                            EventLogEntryType.Information);
    }
}


Repare que a classe "Historico" foi construída utilizando a abordagem Contructor Injection. Agora vamos modificá-la para usar o UAB.
public class Historico
{
    private IEscritor _escritor;


    [Dependency]
    public IEscritor Escritor
    {
        get { return _escritor; }
        set { _escritor = value; }
    }


    public void Escrever(string msg)
    {
        _escritor.Write(msg);
    }
}
Como podemos ver, a estrutura ficou semelhante a que conhecemos por Setter Injection porém temos a adição do atributo [Dependency].
Este atributo indica para o container do UAB qual classes/interfaces deverão ser criadas de acordo com a sua configuração.

Supondo que temos o ponto de entrada do nosso programa descrito da seguinte maneira:
class Program
{
    static void Main(string[] args)
    {
        IUnityContainer container = new UnityContainer();
        UnityConfigurationSection section = 
          (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
        section.Containers.Default.Configure(container);
        Historico _history = container.Resolve();
        _history.Escrever("Hello");


     }
}

Este programa escreve o texto "Hello" em um arquivo, event viewer ou console de acordo com o que indica o objeto UnitConfigurationSection. Neste caso a configuração está no arquivo App.config , repare que a propiedade "mapTo" indica um escritor do tipo Console.

<configuration>
    <configSections>
      <section name="unity" 
         type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, 
               Microsoft.Practices.Unity.Configuration" />
    </configSections>
    <unity>
      <containers>
        <container>
          <types>
            <type 
               type="MyApp.BLL.IEscritor,MyApp.BLL" 
               mapTo="MyApp.BLL.ConsoleWriter,
                      MyApp.BLL" />
          </types>
        </container>
      </containers>
    </unity>
</configuration>

A solução acima demonstra o padrão que conhecemos por injeção de dependência, que envolve três elementos básicos:

1. Objeto que consome o serviço/componente do qual é dependente (Historico)
2. Declaração das dependências do objeto definidas através de Interfaces (IEscritor)
3. Injetor/Provedor/Container responsável por criar instâncias das classes que implementam as interfaces (ConsoleWriter, FileWriter e EventWriter)

A classe Historico descreve quais componentes ela depende para executar o seu trabalho. O container decide qual classe satisfaz os requerimentos do objeto Historico e gera um objeto desta classe para injetar no objeto.

A grande vantagem de delegar esta tarefa ao container é que ele consegue decidir em tempo de execução qual objeto satisfaz os requerimentos. Várias implementações de um único componente podem ser criados e injetados em um código de testes por exemplo. O código de teste pode testar todos os componentes sem se importar com como foram implementados.

Este padrão é muito usado para mockar objetos de teste e para localizar plugins componentes e serviços em tempo de execução.         

           
No próximo post estarei abordando outra maneira de aplicar a Inversão de Controle, o padrão Service Locator.

Fontes:
http://msdn.microsoft.com
http://www.macoratti.net
http://www.martinfowler.com