Análise de portabilidade para migrar para o .NET Core

Já estamos próximos da versão 2.0 do .NET Core. Se você ainda está na versão Full (.NET Framework 4.x), já é hora de começar a pensar em uma migração. Talvez não para agora, mas é importante preparar um planejamento para 1 ou 2 anos, para essa migração.

A Microsoft disponibiliza uma ferramenta interessante para essa tarefa. É o .NET Portability Analyser. 

É uma extensão do visual studio que você pode usar na versão 2015 ou 2017. Depois de instalado, você pode configurá-lo através do menu Analyze > Portability Analyzer Settings.

Nesse exemplo eu vou analisar a compatibilidade dos meus projetos com o .NET Core 2.0 e o .NET Standard 2.0.

Para fazer a análise, clique com o botão direito sobre a sua solution (ou projeto se preferir), e escolha a opção Analyze Assembly Portability.

Ao término, a seguinte janela irá aparecer, a partir da qual você poderá acessar o relatório da analise realizada. Note que nesse exemplo eu optei por gerar um relatório em Excel.

Na primeira planilha desse arquivo você vai encontrar um resumo indicando o % de portabilidade de cada um dos projetos da sua solução, para os Targets selecionados.

Na segunda planilha do arquivo você encontrará uma lista detalhada de todas as incompatibilidades encontradas. Note que você poderá filtrar por projeto, e que em alguns casos já existe uma orientação do que você deve fazer para conseguir portar para o target desejado.

E por fim, na terceira planilha do arquivo você pode ver a lista de assemblies que está utilizando, e que ainda não estão na API do .NET Portability Analyser, e portanto ainda não existe uma análise com relação à essas bibliotecas:

Essa ferramenta será muito útil no processo que você irá enfrentar ao migrar suas aplicações para o .NET Core.

DDD - A Grande Bola de Lama

Anterior

Se você observar o Mapa do DDD, na parte mais abaixo, irá notar que um dos elementos é chamado de Big Ball of Mud, ou a Grande Bola de Lama. 

No mapa esse elemento aparece para ilustrar a ideia de que um Mapa de Contexto bem feito, serve para organizar a bagunça que podemos ter em domínios que contém uma grande quantidade de conceitos.

Mas afinal, o que é a Grande Bola de Lama?

Aposto que você já se deparou com ela em algum projeto por aí. Eu já encontrei várias, e algumas delas produzidas por mim mesmo. 

Um dos lugares mais fáceis de se ver uma bola de lama é em um diagrama de Entidades e Relacionamentos, muito comum nos anos 90 e início dos anos 2000.

Mas o habitat natural dessas bolas continua sendo o código mesmo, onde elas são mais comumente conhecidas como código espaguete. Veja abaixo uma de suas manifestações:

Mas a razão para a grande bola de lama aparecer no mapa, é que um dos principais motivos do DDD é justamente evitá-las em nosso projeto, sejam elas grandes ou pequenas.

DDD - O Mapa

Anterior

O Evans em seu livro, sugere esse mapa para demonstrar e explicar os principais elementos do DDD. Podemos dividir esse mapa em duas partes para entendê-lo melhor. Para isso, parta do elemento Model-Driven Desing e divida o mapa em duas partes: os elementos abaixo do model-driven design, e os elementos à cima.

Na parte de baixo do mapa, temos os elementos mais arquiteturais do DDD. Em DDD nós basicamente partimos de um Domínio, que é divido em Subdomínios, que serão implementados individualmente através de um Bounded Context. Teremos alguns Subdomínios especiais, como o Core Domain e o Shared Kernel. E tudo isso deve ser organizado através de um Mapa de Contexto, e sempre respeitando a tal da linguagem ubíqua (ou onipresente).

Na parte de cima temos os principais elementos e padrões utilizados na modelagem de um domínio. São as práticas mais próximas do nosso código. Através de uma arquitetura de camadas, modelamos nosso domínio com o uso de Entidades, Objetos de Valor e Agregações. Armazenamos e recuperamos dados através de Repositórios, e implementamos nossas regras de negócio com o uso de Serviços, Factories e Eventos.

Esse Mapa serve como um guia, e nos ajuda a entender como todos os conceitos sugeridos pelo DDD se relacionam. Cada um desses elementos é um capítulo à parte no DDD, e aos poucos pretendo abordá-los aqui nesse blog.

Próximo

Publicação MANUAL de WebApi no IIS

Nesse artigo vou mostrar como fazer um Deploy MANUAL de uma API feita com o ASP.NET Web.API, em um IIS (Internet Information Services) de um Servidor Windows 8 ou superior,

Hoje muito se fala de Deploy Automático, Continuous Integration, entre outros termos, que na prática se resumem na automação do processo de publicação de aplicações em geral.

Não contesto a importância de um deploy automático, integrado ao seu repositório de código fonte, vinculado à um processo de Build, que quando bem feito, faz tudo de forma rápida e automática. Mas dedico esse POST aos Devs Old School, que no dia a dia acabam precisando fazer uma publicação esporádica, e o método Manual acaba sendo o mais fácil e rápido.

Vamos ao que interessa!

Dada uma API feita com o ASP.NET Web.API no Visual Studio, vá até a Solution Explorer, clique com o botão direito sobre o projeto Web.API e clique na opção Publish.

Logo em seguida irá aparecer uma tela com algumas opções de publicação, que temos no Visual Studio 2017. São elas:

• Microsoft Azure App Service: Para publicar diretamente em um Serviço no Azure
• IIS, FTP, etc: Para publicar via FTP ou se conectando diretamente em um servidor IIS.
• Folder: Também conhecida como "Deploy na MÃO", vamos usar essa opção
• Import Profile: Caso você tenha um perfil de publicação.
• Microsoft Azure Virtual Machines: Para publicar em uma máquina virtual no Azure.

Como dito, vamos fazer isso na mão. Sendo assim clique na opção Folder, e escolha uma pasta onde você quer gerar seus arquivos de publicação.

Veja que na janela output do Visual Studio você terá o resultado da sua publicação:

O resultado do deploy você vai encontrar na pasta selecionada. Antes de continuar, aqui vai um alerta. Quando fazemos um deploy manual como esse, é nossa responsabilidade garantir que todas as configurações sejam corretamente alteradas! Veja que nesse deploy temos um arquivo web.config, que nesse caso têm uma connection string. Essa connection string obviamente precisa ser modificada para apontar para o Banco de Dados de Produção. Atenção! É sua responsabilidade cuidar disso quando faz um Deploy Manual!

Caso você tenha outra configuração no web.config ou em algum outro arquivo, faça todas as alterações necessárias antes de prosseguir.

Uma das vantagens de um deploy automático é que esse processo de "troca da connection string" fica configurado, e o desenvolvedor não precisa realizá-lo. Mas, novamente, estamos falando de um processo Manual, onde iremos assumir todos os riscos.

Vamos agora, criar um WebSite no IIS, onde iremos publicar nossa API. Abra o IIS do seu servidor, clique com o botão direito sobre a pasta Sites e escolha a opção Adicionar Site.

Na Janela que abrir, informe o nome do seu site, o caminho físico onde ele vai ficar no servidor, e a porta em que ele será publicado. Lembre-se que estamos publicando uma API e não um WebSite, então é comum colocarmos em uma porta diferente da 80.

Clique em OK

Agora copie os arquivos gerados pelo nosso Deploy Manual, para o mesmo caminho físico escolhido aqui. 

Pronto! Sua API foi publicada manualmente. Agora, se você faz esse processo com frequência, pense seriamente em adotar alguma técnica de Deploy automatizado, para evitar qualquer erro durante a publicação das suas APIs.

DDD - Bíblia ou kamasutra?

Anterior

Nessa nossa área de Desenvolvimento de Software, temos o mau hábito de confundir tecnologias, linguagens e frameworks com religião. E com o DDD eu venho percebendo um pouco disso também, inclusive comparações do livro do Eric Evans com a Bíblia.

Se é para comparar o livro do Evans com algum outro livro, eu já prefiro compará-lo com o kamasutra. 

Explico:

Você não deve encarar o DDD como um conjunto de Regras a serem seguidas à risca, com penas que podem lhe levar ao inferno. Na minha opinião você deve encarar o livro do Evans, assim como qualquer outra referência do DDD, como um conjunto de boas ideias e práticas, para garantir a qualidade e o sucesso das suas aplicações.

Conforme você for estudando e adotando o DDD, irá notar que a maioria das ideias são válidas e perfeitamente aplicáveis. Porém, é bem possível que um ou outro padrão não faça sentido para o seu Domínio, ou precise de alguma adaptação para facilitar a implementação.

Próximo

DDD - Referências

Anterior

Depois do Lançamento do Livro da Capa Azul, diversas outras vertentes e interpretações sobre DDD foram surgindo. Segue abaixo algumas das referências que considero mais relevantes:

Esse primeiro é o livro da "Ponte", de Jimmi Nilson. Ele ganhou um grande destaque pois aplicou os conceitos do Domain Driven Design, em uma Aplicação desenvolvida em .NET Framework com C#.

Já esse livro do Vaughn Vernon, trás uma abordagem atualizada sobre o tema, demonstrando exemplos práticos e de fácil entendimento.

Uma das minha referências preferidas é esse curso no PluralSight. Julie Lerman e Steve Smith mostram em vídeo, a modelagem e o desenvolvimento de uma aplicação .NET usando os conceitos do Domain Driven Design.

O Livro da Capa Azul tem uma edição traduzida em Português. Confesso que ainda não li, mas está na minha lista de leitura. Assim que tiver uma opinião a respeito, coloco minhas impressões em um novo post nesse blog.

Próximo

O Livro da capa Azul

Anterior

O termo DDD (Domain Driven Design) surgiu nesse livro da Capa Azul:

O livro é um épico da arquitetura de Software. É uma daquelas poucas referências que vai sobreviver ao tempo, e servirá de base para muita coisa no futuro. Porém, definitivamente não é um livro fácil. Eric Evans é o Tolkien do desenvolvimento de Softwate, ele meio que escreve em parábolas. :)

Brincadeiras à parte, o que tenho a dizer sobre O livro é que você precisa ler! Mas essa não deve ser a sua primeira leitura sobre DDD. Se você está começando agora, não comece pelo livro da capa azul, ele vai te trazer mais dúvidas do que certezas, e possivelmente poderá te desmotivar à entrar no mundo do DDD.

Comece por esse livro aqui:

Esse livro da InfoQ, escrito por Abel Avram e Floyd Marinescu, é considerado um Resumo do Livro do Evans, mas mais do que isso, eles conseguiram captar a essência do DDD e expor de uma forma simples e fácil de entender. Se você não tem nenhuma experiência em DDD, deve definitivamente começar por esse livro.

Outro motivo para começar por aqui é que o livro no formato PDF, é GRATUÍTO!! Então não tem desculpa, é só baixar e ler. 

Ahh, mas é em Inglês, como faço?

Bem... nesse caso só tenho uma a dizer:

Aprenda a Ler e Ouvir em Inglês o mais rápido possível! Esse é o requisito número 1 para quem quer ser um programador. As melhores referências (livros, vídeos, artigos, etc) são em Inglês. 

Para usar um termo do DDD (que veremos em um artigo futuro), o Inglês é a Ubiquotous Language do Software!

Próximo

O que é e porque devo me preocupar com DDD?

DDD significa Domain Driven Design, ou em português: Desenvolvimento Dirigido ao Domínio. A ideia é orientar todo o processo de arquitetura e modelagem do software, única e exclusivamente ao Domínio do negócio ao qual o software deverá atender. 

Ou seja, o DDD te força a manter o foco no Problema à ser resolvido, e não na forma como será implementada a Solução. Domain Driven Design é uma filosofia. 

O termo DDD e as principais ideias que o permeiam, foram cunhadas por um sujeito chamado Eric Evans, no livro Domain Driven Design – Atacando a complexidade no coração do software.

 

Esse livro está para a Orientação à Objetos assim como o livro Análise Estruturada Moderna de Edward Yourdon, esteve para Análise e Desenvolvimento de Sistemas nas décadas de 70, 80 e 90. Décadas que antecederam à popularização das Linguagens Orientadas à Objetos.

Se existe uma forma correta de arquitetar e modelar software com a Orientação à Objetos, é através do Domain Driven Design. Eric Evans sugere o seguinte Mapa para expor os elementos do DDD, e como eles se relacionam:

Não vou entrar nos detalhes do DDD nesse artigo, isso ficará parar os próximos. Mas tem uma coisa que é importante deixar claro aqui: 

Porque devo me preocupar com DDD? 

Tenha em mente que o objetivo do DDD é elevar ao máximo a tempo de vida da sua aplicação, e garantir a qualidade do código que deu origem a ela.

Pense no DDD como a melhor forma para preservar o código que você escreve, para que ele sobreviva o máximo possível ao tempo, às novas tecnologias, aos requisitos que não foram previstos, e à uma das variáveis mais impactantes no tempo de vida do software, você!

Próximo

C# 7 - Pattern Matching

Uma das novidades do C# 7 é o chamado Pattern Matching.

Veja o código do método QualTipo. Ele identifica o tipo do objeto, e já declara de forma inline uma variável do tipo identificado no matching.

Essa funcionalidade se torna ainda mais interessante quando utilizada em um switch:

Note que além de identificar o tipo do objeto, também é possível aplicar condições através da clausula when, para fazer um matching mais específico. 

C# 7 - Declaração inline de Variáveis out

Uma das novidades do C# 7 é a possibilidade de declarar as variáveis para os parâmetros out, de forma "inline".

O que antes tínhamos que fazer assim:

Agora, podemos fazer assim:

Note que a variável out, que deveria ser declarada antes da chamada do método com o parâmetro out, agora pode ser declarada na própria chamada, através do conceito de declaração inline do C# 7.0. Isso, com certeza torna o uso de parâmetros out muito mais fluído em nosso código.