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.

C# 6.0 - using static

No C# 6.0 nós temos um novo recurso chamado using static. Esse recurso nos permite declarar o uso de classes estáticas da mesma forma que declaramos o uso de namespaces, veja o exemplo:

Note que diferente do using tradicional, onde declaramos um namespace, com o using static declaramos o uso de uma classe, nesse caso a classe Console. Com isso temos acesso direto à todos os métodos estáticos dessa classe.

Abraço!

C# 6.0 - Expression Body

Sabe aquelas propriedades e métodos onde temos apenas uma linha com o retorno de alguma expressão?

No C# 6.0 agora temos uma forma bem mais simples de declarar essas propriedades e métodos:



Esse recurso é chamado de Expression Body.

Abraço!

C# 6.0 - Inicialização de Propriedades

A partir do C# 6.0 nós temos a possibilidade de inicializar propriedades da classe na própria declaração das mesmas, assim como fazemos com atributos, veja:

Abraço!

C# 6.0 - Interpolação de Strings

Concatenação de strings todo mundo conhece:



Também podemos trabalhar com formatação de strings, usando o método estático Format da classe String. Veja que a "concatenação" é feita através de parâmetros indexados e posicionados com chaves.



No C# 6.0 temos o recurso de Interpolação de strings. Veja que para interpolar precisamos de um $ antes da string. Isso funciona como um template, sendo que o que está dentro das chaves é compilado para formar a string:



Certamente uma forma muito mais simples de trabalhar com strings!

Abraço!

C# 6.0 - Propagação de NULL

Antes do C# 6.0, para evitar as tão temidas NullReferenceException, era comum esse tipo de código:

Veja que estamos verificando se o parâmetro cliente é diferente de null, antes de verificar o Limite de Crédito. Isso é necessário porque se o parâmetro for null, teremos uma exceção do tipo NullReferenceException ao tentar acessar a propriedade LimiteCredito.

Com o C# 6.0 temos o recurso de Propagação de null (null Propagation), e o nosso código pode ser simplificado assim:

Note que para acessar a propriedade LimiteCredito do objeto cliente, estamos usando o operador ? antes do ponto. Esse é o operador que permite a propagação de null.

Isso significa que se o parâmetro cliente for null, esse null será propagado para a propriedade LimiteCredito em vez de estourar a exception. Como essa propriedade é do tipo decimal que não permite null, o valor "propagado" será o valor default do decimal, que é 0.

Com isso evitamos as NullReferenceException de uma forma muito mais simples e elegante.

Grande Abraço!

Exibindo Caracteres de Espaço e TAB

Para visualizar os caracteres de espaço e TAB no editor de código do Visual Studio, basta utilizar as teclas de atalho: Ctrl-R, Ctrl-W

Esse recurso é bastante útil para visualizar as linhas de indentação do código. Se quiser parar de exibir os caracteres de espaço/TAB, basta repetir as mesmas teclas de atalho.

Abraço!

WinRT

O Windows 8 apresenta uma mudança significativa no sistema operacional da Microsoft, principalmente para nós desenvolvedores.

Agora o Windows tem "duas dimensões". A dimensão desktop, que se parece muito com o Windows 7 e seus antecessores, e a "nova dimensão" que foi inicialmente chamada de Metro, mas que hoje é chamada simplesmente de Windows 8.

É fundamental entender que apesar de ser um único sistema operacional, em cada uma dessas dimensões do Windows 8 roda um runtime diferente. 

No modo Desktop temos o .NET Framework 4.5, e assim como no Windws 7, aqui podemos desenvolver toda a sorte de aplicações Desktop (Console, Windows Forms ou WPF).

Já no novo modo temos o WinRT (Windows runtime), que é um subset do .NET Framework. Veja na figura a seguir como a Microsoft estruturou essa arquitetura do Windows 8.

Aplicações que rodam no WinRT devem seguir uma série de guidelines da Microsoft, e irão executar num contexto muito mais seguro e controlado. A começar, as aplicações deste lado do Windows só poderão ser instaladas pela Loja da Microsoft, em um modelo muito similar da loja de aplicativos da Apple.

Alias esse é o grande motivo do Windows estar tomando essa nova cara. A partir dessa versão o Windows passa a ser um sistema operacional bem mais amigável e compatível com os Tablets.

Desenvolver aplicativos para WinRT exige uma mudança de paradigma. A nossa vantagem é que O Visual Studio 2012 nos dá todo o suporte necessário para a criação destes tipos de aplicativos. Temos até uma edição Express do Visual Studio, exclusiva para o desenvolvimento de aplicações para o WinRT.

Grande Abraço e até a próxima!

Go To Line

Quando temos que lidar com classes grandes, um recurso muito útil é o "Go To Line". É uma janela que nos permite navegar rapidamente até uma determinada Linha do Código. 

A tecla de atalho para acessar a janela "Go To Line" é o CTRL+ G

Grande Abraço e até a próxima!

Seleção de Colunas pelo Teclado

No Visual Studio 2010 nós ganhamos a funcionalidade de seleção de colunas.

Basta segurar a tecla ALT, clicar no inicio do texto e arrastar até formar o bloco que deseja selecionar. Isso é extremamente útil na edição de determinados tipos de código, como por exemplo uma lista de propriedades automáticas de uma classe.

Você pode colar texto nessas seleções, remover e até digitar um texto que será replicado em todas as linhas que fazem parte da seleção.

Agora, se  você não quiser usar o mouse, é muito simples. Basta segurar o SHIFT e o ALT juntos, e com as setas do próprio teclado formar o bloco de texto que deseja selecionar.

Grande Abraço e até a próxima!

Atalhos para Indentação de Código

A indentação é uma ótima prática para manter o seu código legível. Com ela o código fica organizado com espaçamentos, e fica fácil de identificar os diferentes membros ou blocos de código.

Muitas vezes, principalmente em código html, é difícil manter o código bem formatado nesse sentido. O Visual Studio tem dois atalhos que facilitam muito essa tarefa. São eles:

Ctrl+K, Ctrl+D - para formatar a indentação de todo o código do arquivo aberto.

Ctrl+K, Ctrl+F - para formatar a indentação do trecho de código que estiver selecionado.

Note que isso não vale apenas para classes. Você pode utilizar esses atalhos em qualquer arquivo de código onde se usa identação, como por exemplo código HTML, XML, ASPX, XAML, etc

Grande Abraço e até a próxima!