WCF – Usando o MsmqIntegrationBinding

Há algum tempo eu mostrei neste artigo como podemos fazer o uso do Message Queue com WCF, e lá foi discutido todos os benefícios de se envolver uma fila na comunicação entre as duas partes. A exigência daquele modelo de utilização é que ambos os lados precisam utilizar a API do WCF para se comunicar com o Message Queue.

O problema é que as vezes já temos uma solução implementada e operante. Antes do WCF, a única forma que tínhamos para interagir com o Message Queue na plataforma .NET era através das classes contidas no assembly System.Messaging.dll. Além disso há outras soluções que recebem ou enviam mensagens para uma fila, escritas em outras tecnologias.

Para trabalhar com Message Queue no WCF, temos dois bindings: NetMsmqBinding e MsmqIntegrationBinding, onde o primeiro deles já foi esgotado naquele outro artigo. O segundo trata-se de um binding criado exclusivamente para interagir com filas em que as mensagens sejam postadas ou recebidas por outras tecnologias que não o WCF. A finalidade deste artigo é mostrar como proceder para utilizar este binding e interoperar com soluções que já estão em funcionamento.

Para exemplificar vamos interoperar com aplicativos que recebem e postam mensagens utilizando a API System.Messaging.dll, que existe desde a primeira versão do .NET Framework. Abaixo temos dois cenários distintos, separados em duas pastas: WCFNoCliente e WCFNoServidor. No primeiro cenário utilizaremos o WCF para enviar uma mensagem para a fila e o serviço irá extrair a mensagem de lá utilizando as classes contidas no assembly System.Messaging.dll. No segundo cenário, será o inverso, ou seja, utilizaremos as classes contidas no assembly System.Messaging.dll para enviar a mensagem, e utilizaremos o WCF no serviço para extrair a mensagem da fila e processá-la. A imagem abaixo ilustra a estrutura dos projetos de teste:

O primeiro passo é desenhar o contrato do serviço, que irá formalizar a comunicação. A ideia será ter um serviço que processa pedidos de algum comércio eletrônico. Sendo assim teremos duas classes: Pedido e Cliente, que são autoexplicativas. Cada uma delas tem propriedades que as descrevem, que também não precisam ser exibidas aqui. Uma característica de serviços que são expostos através do Message Queue, é que as operações eles devem ser sempre one-way, assim como já foi discutido anteriormente. Abaixo temos a definição do contrato que será utilizado como exemplo:

[ServiceContract]
[ServiceKnownType(typeof(Pedido))]
[ServiceKnownType(typeof(Cliente))]
public interface IComercioEletronico
{
    [OperationContract(IsOneWay = true, Action = “*”)]
    void AdicionarPedido(MsmqMessage<Pedido> mensagem);
}

Infelizmente por se tratar de um cenário específico, a nossa operação deverá ter apenas um único parâmetro, e ele deve ser do tipo MsmqMessage<T>, que está debaixo do namespace System.ServiceModel.MsmqIntegration, e representará o body da mensagem. Caso você precise de mais parâmetros, então o correto é que você inclua isso em uma mesma classe e a defina como o parâmetro genérico T da classe MsmqMessage<T>. É importante dizer que o contrato irá definir a estrutura da mensagem a ser enviada para a fila (WCFNoCliente) ou a mensagem a ser extraída da fila (WCFNoServidor).

um detalhe importante na criação do contrato é o uso do atributo ServiceKnownTypeAttribute, que é exigido para todos os elementos mencionados direta ou indiretamente no contrato. Isso é necessário para que o serializador conheça todos os tipos envolvidos, caso contrário, a mensagem não será recebida pelo WCF, e ao ligar o tracing, vamos nos deparar com a seguinte mensagem de erro:

System.ServiceModel.ProtocolException: An error was encountered while deserializing the message. The message cannot be received. —&gt; System.Runtime.Serialization.SerializationException: An error occurred while deserializing an MSMQ message’s XML body. The message cannot be received. Ensure that the service contract is decorated with appropriate [ServiceKnownType] attributes or the TargetSerializationTypes property is set on the MsmqIntegrationBindingElement.

Utilizando o WCF no Servidor

Como será um serviço WCF que irá extrair as mensagens da fila, o primeiro passo aqui é a implementação do contrato na classe que representará o serviço. Aqui tudo é muito parecido com um serviço WCF tradicional, mas com uma pequena diferença que está na operação. Como a classe MsmqMessage<T> representa a mensagem que está dentro da fila, ela é muito mais do que a instância da classe Pedido, ou seja, temos outras propriedades que estão relacionadas ao protocolo.

Entre as várias propriedades expostas pela classe MsmqMessage<T> temos a propriedade Body, que retorna um object que representa a instância da classe que foi serializada no corpo da mensagem pelo cliente, que no nosso caso é a classe Pedido. Abaixo temos a implementação do serviço com o processamento da mensagem:

public class ServicoDeComercioEletronico : IComercioEletronico
{
    [OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
    public void AdicionarPedido(MsmqMessage<Pedido> mensagem)
    {
        Pedido pedido = mensagem.Body as Pedido;

        if (pedido != null)
        {
            Console.WriteLine(“—- Processando o Pedido: {0}”, pedido.Codigo);
            Console.WriteLine(“—- Cliente: {0}”, pedido.Cliente);
            Console.WriteLine(“—- Valor: {0:N2}”, pedido.ValorTotal);
            Console.WriteLine(“—- Data: {0:dd/MM/yyyy HH:mm}”, pedido.Data);
            Console.WriteLine();
        }
    }
}

Note que decoramos a operação com o atributo OperationBehaviorAttribute definindo as propriedades TransactionScopeRequired e TransactionAutoComplete para True, pois utilizando o binding MsmqIntegrationBinding não temos o controle explícito das transações, que para isso exige que o binding suporte sessões, e não é o caso do MsmqIntegrationBinding.

Depois da implementação definida, agora chega o momento de configurar o serviço. Como já sabemos, vamos recorrer ao binding MsmqIntegrationBinding. Para uma fácil interoperabilidade, o endereço em que o serviço é exposto deve utilizar o scheme msmq.formatname ao invés do net.msmq, que permite entre vários modelos, o acesso direto a fila (através de format-name), sem a necessidade de contatar o Active Directory (AD). Abaixo temos a configuração declarativa do serviço:

<system.serviceModel>
  <services>
    <service name=”Servico.ServicoDeComercioEletronico”>
      <endpoint address=”msmq.formatname:DIRECT=OS:.private$MinhaFila”
                binding=”msmqIntegrationBinding”
                bindingConfiguration=”bindingConfig”
                contract=”Biblioteca.IComercioEletronico” />
    </service>
  </services>
  <bindings>
    <msmqIntegrationBinding>
      <binding name=”bindingConfig”>
        <security mode=”None” />
      </binding>
    </msmqIntegrationBinding>
  </bindings>
</system.serviceModel>

Com o serviço criado, podemos agora inicializarmos a criação do cliente. Obviamente que não iremos referenciar o serviço, mesmo porque nem criamos o endpoint que expõe o documento WSDL. A ideia aqui será utilizar os tipos que estão dentro do assembly System.Messaging.dll para enviar a instância da classe Pedido para a fila, e utilizar o WCF do outro lado para processar.

Depois do assembly referenciado na aplicação, instanciamos a classe MessageQueue e informamos o caminho para a fila (via path-name). Depois instanciamos a classe Pedido e a configuramos com os dados do Pedido que foi realizado e, finalmente, enviamos a instância para a fila através do método Send. Neste momento, a instância da classe Pedido será serializada como o body da mensagem.

using (MessageQueue queue = new MessageQueue(@”.private$MinhaFila”))
{
    Pedido pedido = new Pedido();
    pedido.Codigo = 123;
    pedido.Data = DateTime.Now;
    pedido.ValorTotal = 1983.81M;
    pedido.Cliente = new Cliente() { Codigo = 39, Nome = “Israel Aece” };

    queue.Send(pedido, MessageQueueTransactionType.Single);
    Console.WriteLine(“Mensagem Enviada com Sucesso.”);
}

Observação: Como a fila é transacionada, precisamos definir o tipo da transação a ser utilizada pelo Message Queue no momento do envio da mensagem. Se o controle da transação está sendo controlada por um elemento externo, como é o caso do TransactionScope, então é necessário definir o MessageQueueTransactionType para Automatic, para que o envio da mensagem possa participar da mesma transação, criada previamente.

Utilizando o WCF no Cliente

Neste cenário inverteremos as tecnologias que utilizamos. Agora no serviço utilizaremos os tipos do assembly System.Messaging.dll e no cliente o WCF. Aqui criaremos a instância da classe MessageQueue com a finalidade de extrair a mensagem que lá foi postada, enviada por um cliente que utiliza o WCF. E para isso utilizaremos o método Receive, que da mesma forma que o método Send, também precisa estar protegido por uma transação.

O método Receive retorna uma instância da classe Message (namespace System.Messaging), que entre várias propriedades, temos a Body, que retorna um object representando a classe que foi serializada, e que no nosso caso é a classe Pedido. O código abaixo ilustra como fazemos para extrair a mensagem:

using (MessageQueue queue = new MessageQueue(@”.private$MinhaFila”))
{
    queue.Formatter = 
        new XmlMessageFormatter(new Type[] { typeof(Pedido), typeof(Cliente) });

    Pedido pedido = queue.Receive(MessageQueueTransactionType.Single).Body as Pedido;

    if (pedido != null)
    {
        Console.WriteLine(“—- Processando o Pedido: {0}”, pedido.Codigo);
        Console.WriteLine(“—- Cliente: {0}”, pedido.Cliente);
        Console.WriteLine(“—- Valor: {0:N2}”, pedido.ValorTotal);
        Console.WriteLine(“—- Data: {0:dd/MM/yyyy HH:mm}”, pedido.Data);
        Console.WriteLine();
    }
}

Da mesma forma que fizemos acima com o contrato do WCF, decorando-o com o atributo ServiceKnownTypeAttribute, temos também que mencionar quais sãos os tipos que compõem o body da mensagem que está na fila, e para isso podemos recorrer a instância da classe XmlMessageFormatter, e em seu contrutor informar um array contendo os tipos envolvidos.

Como não há referência do serviço no cliente, precisamos fazer com que o cliente conheça qual é o contrato do serviço, e justamente por isso que ele foi colocado em uma DLL a parte, chamada de Biblioteca. Utilizamos no cliente a classe ChannelFactory<TChannel> para criar a canal de comunicação entre a aplicação cliente e a fila.

Além do contrato, devemos também informar o binding que irá reger a comunicação, e que como sabemos, será o binding MsmqIntegrationBinding. Em seguida informarmos o endereço (format-name) da fila em que a mensagem será postada. Com a factory criada, agora podemos criar a instância do canal que é efetivamente o proxy:

using (ChannelFactory<IComercioEletronico> factory =
    new ChannelFactory<IComercioEletronico>(
        new MsmqIntegrationBinding(MsmqIntegrationSecurityMode.None),
        @”msmq.formatname:DIRECT=OS:.private$MinhaFila”))
{
    var proxy = factory.CreateChannel();

    Pedido pedido = new Pedido();
    pedido.Codigo = 123;
    pedido.Data = DateTime.Now;
    pedido.ValorTotal = 1983.81M;
    pedido.Cliente = new Cliente() { Codigo = 39, Nome = “Israel Aece” };

    proxy.AdicionarPedido(new MsmqMessage<Pedido>(pedido));
    Console.WriteLine(“Mensagem Enviada com Sucesso.”);
}

Note que depois da instância da classe Pedido criada e configurada, ela não é passada diretamente para o método AdicionarPedido. Como foi comentado acima, o contrato impõe que a classe Pedido seja envolvida por um wrapper (MsmqMessage<T>), que representará a mensagem dentro do fila, e a instância da classe Pedido será armazenada/serializada no body dela.

Assincronismo

Como sabemos, uma das características do uso do Message Queue é garantir o assincronismo, e permitir ao cliente enviar mensagens ao serviço mesmo que ele esteja offline, mascarando assim eventuais problemas que existam na comunicação entre as duas partes envolvidas.

Conclusão: No decorrer deste artigo vimos que podemos substituir a tecnologia que existe de um dos lados para uma tecnologia mais recente, como é o caso do WCF, e com isso tirar todo o proveito de seus recursos, mas tendo em mente que existem algumas poucas limitações e imposições.

UtilizandoMsmqIntegrationBinding.zip (20.48 kb)

Curso de WCF 4.0 em Campinas

wcf 4.0Dia após dia as aplicações estão cada vez mais conectadas. Essa interligação viabiliza novas oportunidades de negócios, agilidade e eficiência no processo de uma empresa, beneficiando assim todos aqueles que estão envolvidos.

Dentro da plataforma .NET da Microsoft, o WCF (Windows Communication Foundation) é o pilar de comunicação, que fornece uma infinidade de funcionalidades para expor, consumir e gerenciar serviços, sejam eles para serem consumidos em uma rede local ou através da internet.

Como essa necessidade está cada vez mais presente no dia a dia de cada desenvolvedor, o WCF possui cada vez mais espaço, já que ele substitui todas as tecnologias de aplicações distribuídas criadas pela Microsoft, incorporando em uma plataforma estensível e consistente, os principais modelos de comunicação que existem atualmente.

Tendo em vista todo esse cenário, eu vou ministrar um curso oficial de WCF 4.0, abordando desde os primeiros passos até cenários mais complexos, como roteamento, estensibilidade, segurança (incluindo claims), performance, etc. Abaixo estão listados os tópicos que serão abordados:

  • Módulo 1: Arquitetura Orientada à Serviços
  • Módulo 2: Introdução ao WCF
  • Módulo 3: Hospedagem de Serviços
  • Módulo 4: Contratos
  • Módulo 5: Endpoints e Behaviors
  • Módulo 6: Teste e Debug
  • Módulo 7: Segurança
  • Módulo 8: Tópicos Avançados (Estensibilidade, Processamento Assíncrono e Roteamento)

Como pré-requisitos para este curso, é necessário possuir familiaridade com a plataforma .NET, com o Visual Studio 2008/2010 e experiência em alguma linguagem .NET (C# ou VB.NET), incluindo conceitos relacionados a orientação à objetos.

O curso será ministrado na People Computação, na cidade de Campinas, em São Paulo, com toda infraestrutura fornecida por eles. A People é um centro oficial autorizado Microsoft, que ministra e aplica cursos e exames oficiais, e é onde eu ministro treinamentos desde meados de 2005.

Com 24 horas de duração, o treinamento será realizado toda terça-feira e quinta-feira, das 18:30 às 22:30 (sendo 4 horas por dia), iniciando em 23 de novembro até 09 de dezembro de 2010. A sala terá capacidade para apenas 12 alunos. Para maiores informações, valores e como se inscrever, entre em contato através do telefone (19) 3739-6400.

Substituindo ASMX por WCF no servidor

Os ASP.NET Web Services (ASMX) são baseados na especificação WS-I Basic Profile, gerando as mensagens na versão 1.1 do SOAP. Eles foram que foram introduzidos desde a primeira versão do .NET Framework, e mais recentemente foram substituídos pelo WCF.

Para manter a interoperabilidade, a Microsoft criou um binding chamado BasicHttpBinding, que possui as mesmas características dos serviços ASMX. Com isso, podemos substituir tanto o serviço quanto o cliente utilizando a API do WCF. Ao optar pela substituição do lado do serviço, precisamos nos preocupar com a SOAPAction.

A SOAPAction é um header que é incluído na requisição HTTP, e determina intenção da requisição SOAP. Esse header é representado por uma URI que não aponta necessariamente para um local válido na internet. O problema reside justamente aqui. Imagine que temos um serviço (ASMX), que disponibiliza apenas uma única operação:

[WebService(Namespace = “http://tempuri.org/&#8221;)]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Servico : System.Web.Services.WebService
{
    [WebMethod]
    public string Ping()
    {
        return “ping!”;
    }
}

Os clientes que o consomem devem enviar as requisições da seguinte forma:

POST /Servico.asmx HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.4952)
Content-Type: text/xml; charset=utf-8
SOAPAction: “http://tempuri.org/Ping&#8221;
Host: 127.0.0.1:51982
Content-Length: 288
Expect: 100-continue
Connection: Keep-Alive

<?xml version=”1.0″ encoding=”utf-8″?>
    <soap:Envelope …>
        <soap:Body>
            <Ping xmlns=”http://tempuri.org/&#8221; />
        </soap:Body>
</soap:Envelope>

Agora queremos substituir o serviço para o WCF. Optamos então por criar o contrato e, consequentemente, o implementamos em uma classe que representará o serviço. A interface do contrato está definida abaixo:

[ServiceContract]
public interface IContrato
{
    [OperationContract]
    string Ping();
}

O ponto mais importante é expor o serviço através do binding BasicHttpBinding, que não será abordado aqui. Se analisarmos o WSDL gerado pelo serviço, veremos que a SOAPAction gerada é: http://tempuri.org/IContrato/Ping. Como podemos perceber, ela leva o nome do contrato. Com isso, os clientes existentes não conseguirão mais enviar mais mensagens para o serviço, já que o WCF utiliza a SOAPAction para identificar a operação a ser disparada, e como ela é diferente, não a encontrará. Abaixo temos a descrição do erro que ocorre:

Unhandled Exception: System.Web.Services.Protocols.SoapHeaderException: The message with Action ‘http://tempuri.org/Ping&#8217; cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

Para resolvermos este problema, temos que recorrer a propriedade Action que é definida no atributo OperationContractAttribute, e lá colocarmos a mesma SOAPAction que os clientes estão enviando, mantendo assim a compatibilidade e não sendo necessária qualquer mudança por parte daqueles que o consomem.

[ServiceContract]
public interface IContrato
{
    [OperationContract(Action = “http://tempuri.org/Ping&#8221;)]
    string Ping();
}

Tomando este cuidado, podemos tranquilamente substituir serviços construídos em ASMX para WCF, sem afetar qualquer cliente que já consuma o mesmo. É importante dizer também que é possível consumir um serviço escrito em ASMX através da API do WCF do lado cliente, mas isso está fora do escopo deste artigo. E para finalizar, sempre se atente aos namespaces.

Visualizador para JSON

O JSON é um formato que temos para serializar informações, e que possibilita aplicações AJAX consumirem serviços de forma muito mais simples, dispensando todo o “overhead” do XML ou SOAP. É um formato relativamente simples, assim como podemos ver abaixo, onde temos um cliente e seus respectivos pedidos:

{“Codigo”:123,”Email”:”ia@israelaece.com”,”Nome”:”Israel”,”Pedidos”:[{“Codigo”:1,”Data”:”/Date(1282228004105-0300)/”,”Valor”:1000},{“Codigo”:2,”Data”:”/Date(1282228004144-0300)/”,”Valor”:129}]

Para facilitar a vida dos desenvolvedores, principalmente quando lidamos com a construção de serviços, que exigem a exposição de informações mais complexas do que essa mostrada acima, pode ser útil termos um visualizador para mostrar graficamente a estrutura do documento JSON. Para isso, podemos recorrer ao JSONViewer, uma ferramenta que não exige nenhuma instalação, e tudo o que você precisa fazer é rodá-la. Abaixo podemos ver a imagem do documento JSON acima, totalmente formatado e de forma gráfica.

Depois de baixar, com uma configuração simples, que você encontra no site do projeto, verá que podemos incorporá-lo ao Fiddler, para já monitorar serviços que retornam os resultados em formato JSON.

Feedback do Evento Codificando.NET

Como eu comentei aqui, eu palestrei no evento do Codificando.NET 2010 sobre a construção de serviços em WCF. O evento foi bem organizado, onde o Alexandre Tarifa, Andrey Sanches e o Diego Nogare se esforçaram para que o evento fosse um grande sucesso. Foi bom reencontrar esses amigos, que além deles, também falei com o Claudenir Andrade, Helio Sá Moreira, Alfred Myers e o Rodolfo Roim. Gostaria também de agradecer aqueles que ficaram para acompanhar a minha palestra, que se iniciou às 16:30hs. Para os interessados, o exemplo que montei pode ser baixado neste endereço.

Além deste evento, também aconteceu uma espécie de “micro-evento”, pois o Alexandre Tarifa forneceu um espaço para o pessoal do grupo do DotNetArchitects realizar uma reunião. Foi legal participar e poder conhecer alguns nomes importantes da comunidade, como é o caso do Fabio Margarito, Leandro Daniel, Daniel Castro, Victor Cavalcante e Vinicius Quaiato, onde em uma conversa informal foi discutido muitos assuntos pertinentes ao desenvolvimento de software.

QCon – Como unificamos nossa camada de autenticação?

O principal evento de arquitetos e desenvolvedores chega a América Latina. O QCon SP traz, dias 11 e 12 de Setembro, ícones internacionais e nacionais de diversas áreas, com apresentações de alto nível técnico. Com sistemas cada vez mais complexos, o QCon aborda não apenas uma única tecnologia ou aspecto: passa de Java, .NET e Rails até Arquitetura, Design, Cloud, Escalabilidade, Replicação, Cache e casos de sucesso.

Neste evento, eu fui convidado para compor juntamente com alguns ícones do mundo .NET (tais como Thiago Cruz Soares e Fabio Galuppo), o grupo de palestrantes focados em tecnologias Microsoft/.NET. A minha palestra tem como finalidade abordar o WIF – Windows Identity Foundation, que já falei bastante por aqui. Abaixo temos a descrição completa da palestra:

Título: Como unificamos nossa camada de autenticação?
Palestrante: Israel Aece
Descritivo: Autenticação e autorização são dois conceitos importantes que existem no desenvolvimento de software. A autenticação é a necessidade de saber quem o usuário é, enquanto a autorização é saber que direitos ele tem no software. Há uma grande complexidade em torno destes temas, pois cada aplicação precisa se preocupar em vários detalhes para garantir a segurança, tais como: um local seguro para armazenar as credenciais de acesso, definição de políticas para a criação e reutilização de senhas, etc. E como se isso não fosse o bastante, corremos um grande risco de termos a mesma infraestrutura repetida entre várias aplicações, dificultando a manutenção, segurança e a experiência de navegação dos usuários que as acessam. Essa palestra mostrará cenários típicos do nosso dia-à-dia, como SSO (Single Sign-On) e federação dentro da plataforma .NET.

Codificando.NET 2010 – Palestra sobre WCF

No próximo dia 19 de junho (sábado), acontecerá em São Paulo um evento chamado Codificando 2010, organizado pela comunidade Codificando.NET. Esse evento terá várias sessões focadas exclusivamente em desenvolvimento de aplicações utilizando a plataforma .NET, com especialistas de mercado. Para maiores detalhes sobre o evento em geral, consulte o site neste endereço.

Eu fui convidado pelo Alexandre Tarifa para falar sobre WCF – Windows Communication Foundation, que é a alternativa no ambiente Microsoft/.NET para construção de aplicações distribuídas e conectadas. É importante dizer que a palestra será de nível 100, abordando superficialmente algumas das principais funcionalidades e mudanças que aconteceram nesta nova versão da tecnologia, permitindo desmistificar os principais elementos que compõem a estrutura do WCF. Abaixo temos a descrição da palestra:

Título: Distribuindo Componentes com WCF
Palestrante: Israel Aece
Descritivo: O WCF é o pilar de comunicação da plataforma .NET, e que está presente desde a versão 3.0. Através dele podemos construir serviços que podem ser consumidos pela própria empresa ou por parceiros de negócios, para que seja possível criar aplicações inteligentes e conectadas. A finalidade desta palestra é mostrar um overview sobre o WCF, abordando superficialmente as funcionalidades incluídas na versão 4.0, com exemplos práticos de sua utilização.

Evento de Tecnologia em Hortolândia

No próximo dia 01 de junho (terça-feira) acontecerá um evento na UNASP Hortolândia (Centro Universitário Adventista de São Paulo), na cidade de Hortolândia. Para quem é de Campinas e região, este evento acontecerá na sede da universidade, localizada na Rua Pr. Hugo Gegembauer, 265, Parque Hortolândia, à partir das 19:45. Eu palestrarei sobre o Visual Studio 2010 e o .NET Framework 4.0. É importante dizer que a palestra será de nível 100, que além de abordar superficialmente algumas das principais funcionalidades desta nova versão, falaremos um pouco também sobre algumas tecnologias que já existem e estão à disposição desde as versões anteriores. Abaixo temos a descrição da palestra:

Título: Visual Studio 2010 e .NET Framework 4.0
Palestrante: Israel Aece
Descritivo: Esta palestra tem a finalidade de exibir um “tour” sobre a plataforma .NET, e a principal ferramenta que utilizamos para desenvolver aplicações para ela, que é o Visual Studio. A ideia é demonstrar rapidamente a história e a evolução do .NET Framework até a versão 4.0, incluindo assuntos como as linguagens de programação (C# e VB.NET), acesso à dados e aplicações para internet (WebForms, MVC e Silverlight). Logo após, vamos analisar de forma superficial as novidades que estão sendo incluídas na IDE do Visual Studio 2010 e que dão suporte ao desenvolvimento de qualquer tipo de aplicação sobre a plataforma .NET.

O Português e o Software

Artigos, preposições, pronomes, verbos, entre várias outras classes de palavras, são características de vários idiomas ao redor do mundo. Cada uma delas desempenha um papel importante, e ficaria difícil montarmos orações sem uma delas, pois coisas básicas como determinar e conectar elementos, expressar ações, etc., são por elas especificadas, e que impõem suas regras de construção.

Quando estamos criando um software, é importante que se nomeie os seus membros de forma à expressar exatamente como temos no mundo real. Isso facilita muito durante o levantamento, desenvolvimento e, principalmente, na manutenção do código, permitindo que pessoas que não conheçam exatamente os detalhes de uma linguagem de programação, olharem para o código e entenderem o que está acontecendo ali. Justamente por isso é importante que você tente manter – também – durante a criação de classes, métodos, propriedades e variáveis, os mesmos elementos gramaticais que são utilizados no mundo real.

Em um artigo anterior eu já havia comentado sobre a utilização do idioma português ao invés do inglês. Se você está criando um código de infraestrutura, como por exemplo, um repositório de logs, classes que facilitam o acesso ao registry do Windows, etc., então você pode manter isso em inglês, pois fica até mais fácil encontrar nomes mais coerentes. Já quando estamos construindo as regras de negócio, onde vamos utilizar algum modelo para o desenvolvimento (DDD, TS ou AR), devemos sim utilizar o português e nos atentarmos para manter as classes de palavras do idioma, para expressar com exatidão o negócio no mundo virtual.

Ao criar variáveis, eu considero o uso das preposições como sendo extremamente importante para conectar uma parte da variável à outra. Se vamos criar uma váriavel que irá armazenar o nome do cliente, ao invés de utilizarmos nomeCliente, é muito mais intuitivo chamarmos de nomeDoCliente. Acredito que nomear a variável como nomeCliente acaba sendo uma má interpretação do inglês, por exemplo, se fossêmos criar a mesma variável em inglês, nomearíamos para customerName, mas lembre-se de que a tradução para customer name é nome do cliente. Para elencar mais alguns exemplos práticos:

DateTime dataDeNascimento = DateTime.Now;
decimal valorTotalDoPedido = 1000.00M;
decimal? taxaDeJuros = null;
bool permiteContinuarCasoEncontreFalhasNoProcessamento = true;
Action<decimal> calculoDeSalario = (salario) => { };

O mesmo vale para métodos. O que temos em mente é que métodos devem ser representados por verbos. Isso continua sendo válido, mas você deve nomeá-lo exatamente de acordo com a sua finalidade. Geralmente você utiliza o verbo em primeiro lugar e o restante complementa de acordo com a tarefa que ele desempenha, por exemplo:

RepositorioDeClientes repositorioDeClientes = new RepositorioDeClientes();

Cliente cliente = new Cliente();
cliente.Nome = “Israel Aece”;
cliente.Salario = 1000.00M;

this.CalcularLimiteDaContaCorrente(cliente);
repositorioDeClientes.Adicionar(cliente);

Depois do limite calculado, eu estou adicionando o cliente recém criado no repositório. Note que o método Adicionar é nomeado como Adicionar e não como AdicionarCliente. Como eu já estou em um repositório de clientes, eu já sei que ali eu só posso adicionar clientes. Não precisa “ratificar” isso no método. Além de desnecessário, complica a leitura.

Outro detalhe importante é quando você vai criar sobrecargas (overloads) de métodos. Na maioria destes casos, são os parâmetros (tipo e quantidade) que determinam a diferença entre as várias versões e não o nome, pois os nomes serão sempre os mesmos. Por exemplo, você tem uma classe que efetua a simulação de empréstimos pessoais, onde é necessário informar o valor a ser financiado e o CPF do cliente. Só que o cliente pode não estar com o CPF, mas tem ele na CNH ou no RG. Então você pode criar versões do método Simular, onde cada um utiliza um documento específico.

public class SimuladorDeEmprestimosPessoais
{
    public void Simular(decimal valor, RG rg)
    {
        CPF cpf = ExtrairCPFDoRG(rg);
        Simular(valor, cpf);
    }

    public void Simular(decimal valor, CNH cnh)
    {
        CPF cpf = ExtrairCPFDaCNH(cnh);
        Simular(valor, cpf);
    }

    public void Simular(decimal valor, CPF cpf)
    {
        //efetua a simulação
    }
}

Acima vemos um exemplo prático e expressivo, que olhando para os seus métodos, somos capazes de efetuar a simulação dado qualquer um dos documentos suportados (RG, CNH ou CPF) pela classe.

Como eu disse acima, com esse tipo de código é possível que pessoas que nem conheçam detalhes do C#, olhem para ele e consigam extrair e entender grande parte das funcionalidades que ele executa. Essa técnica tornará o seu trabalho e dos demais membros da equipe muito mais simples, principalmente quando precisamos efetuar algum tipo de manutenção em um código já escrito há algum tempo. A ideia é tentar praticar o que Martin Fowler já falou há algum tempo: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”.

Community Launch em Campinas

No próximo dia 20 de março acontecerá um evento chamado de Community Launch. Esse evento será espalhado por todo o Brasil, onde cada região criará o evento e abordará os principais produtos da Microsoft que estarão sendo lançados neste ano de 2010, a saber: Visual Studio 2010, Windows Server 2008 R2SQL Server 2008 R2.

Para quem é de Campinas e região, este evento acontecerá na Universidade UNIP, localizada no bairro Swift, à partir das 09:00 da manhã. Caso você não saiba exatamente onde ela está localizada, consulte este endereço para saber como chegar até lá. Entre as várias palestras, eu sou o responsável por falar sobre Visual Studio 2010 e .NET Framework 4.0. É importante dizer que a palestra será de nível 100, que além de abordar superficialmente algumas das principais funcionalidades desta nova versão, falaremos um pouco também sobre algumas tecnologias que já existem e estão à disposição desde as versões anteriores. Abaixo temos a descrição da palestra:

Título: Visual Studio 2010 e .NET Framework 4.0
Palestrante: Israel Aece
Descritivo: Esta palestra tem a finalidade de exibir um “tour” sobre a plataforma .NET, e a principal ferramenta que utilizamos para desenvolver aplicações para ela, que é o Visual Studio. A ideia é demonstrar rapidamente a história e a evolução do .NET Framework até a versão 4.0, incluindo assuntos como as linguagens de programação (C# e VB.NET), acesso à dados e aplicações para internet (WebForms, MVC e Silverlight). Logo após, vamos analisar de forma superficial as novidades que estão sendo incluídas na IDE do Visual Studio 2010 e que dão suporte ao desenvolvimento de qualquer tipo de aplicação sobre a plataforma .NET.

IMPORTANTE: Apesar do evento ser gratuito, para poder participar é necessário efetuar o cadastro aqui.