Implementando o padrão CQRS em aplicações .NET

O padrão CQRS está sendo cada vez mais utilizado para o desenvolvimento e modelagem de aplicações que necessitam de expressividade no domínio, integrações com outras aplicações e um controle mais avançado sobre leitura e escrita de dados.

O conteúdo deste material está em vídeo, pois foi uma palestra online que realizei no Canal .NET e foi gravada ao vivo.

CQRS

O CQRS além de ajudar muito na expressividade do domínio e sobre as intenções de negócio também vai facilitar muito a implementação de uma arquitetura “Event Driven”, que está sendo cada vez mais utilizada em projetos de Microservices e em cenários de muitas integrações.

Caso não conheça o padrão CQRS além deste tutorial eu indico este post que escrevi:

CQRS – O que é? Onde aplicar?

O código fonte de exemplo é do meu projeto open-source chamado Equinox.

Espero que vocês aproveitem o material e qualquer dúvida estou a disposição.


Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

.NET Standard – Você precisa conhecer!

.NET Standard é a nova palavra do momento, quem acompanha de perto as novidades do mundo .NET com certeza já deparou com este novo conceito e é realmente muito importante que você compreenda bem o que ele significa.

O .NET Standard é um conceito essencial para compreender a unificação das plataformas .NET sendo que atualmente podemos entender como 3 plataformas:

.NET Standard

Por que precisamos de um padrão?

O .NET Framework foi lançado em meados de 2002 no formato de um framework único para desenvolvimento na plataforma Windows. Com o passar do tempo ganhou suporte para Web, Silverlight, WCF, WPF, etc…

Após o lançamento do .NET surgiram outros frameworks como Mono, Unity, etc. Que são implementações open-source do .NET Framework e aceitam a linguagem C#, pois implementam os padrões ECMA do C# e o CLR do .NET.

E para finalizar ainda temos o .NET Core o mais recente “sabor” de .NET Framework 100% open-source e multi-plataforma.

Problemas a vista

  • Sendo que todos estes “sabores” de frameworks suportam a linguagem C#, seria possível escrever um único código e rodar em qualquer plataforma?
  • Posso escrever uma biblioteca em .NET 4.6.1 e utilizá-la como referência no .NET Core?
  • É possível garantir que o código não irá quebrar ao trocar a versão do framework?

Não! Sempre existiram diversas limitações. Tanto no suporte das funcionalidades de cada versão quanto no número de APIs suportadas em cada framework.

Para que o .NET continue evoluindo rapidamente é necessário evitar a fragmentação entre tantas versões de frameworks e proporcionar a escrita de um código único para qualquer plataforma. A solução é implementar um padrão para que todas as versões dos frameworks suportem o mesmo conjunto de APIs.

Conceituando o .NET Standard

O .NET Standard não é mais um “sabor” de .NET, você não instala o .NET Standard na sua máquina e também não devemos considerar o .NET Standard uma nova tecnologia.

O .NET Standard é uma interface, uma espécie de contrato que define a lista de APIs que aquela determinada versão do .NET deve suportar. Para entender de forma muito simples o conceito do .NET Standard imagine o seguinte cenário:

.NET Standard Analogia

O David Fowler também criou uma analogia bem interessante sobre o assunto.

Entenda que o .NET Standard é uma espécie de interface que define as APIs que cada versão do .NET irá oferecer suporte. O código do .NET Standard não possui implementação de comportamento, apenas a declaração das classes e métodos. Através deste padrão único conseguiremos uma total compatibilidade de um código .NET Framework para .NET Core por exemplo.

Mas o PCL não serve para isto?

O PCL (Portable Class Libraries) resolvia isto mas de uma outra forma, uma forma bem menos eficiente e que limitava a entrada de novas plataformas. O .NET Standard substituiu o PCL.

Como o .NET Standard resolve esta questão?

O código será compilado para uma versão específica do framework .NET que é suportado em versões específicas do .NET Standard. Cada versão do .NET Standard suporta um número determinado de APIs.

.NET Standard Versões

O .NET Standard 2.0 suporta o .NET Core 2.0 e .NET Framework 4.6.1.
No futuro suportará também as novas versões do Mono, UWP e Xamarin.

Um ponto muito interessante é a evolução da versão 1.6 para a versão 2.0:

Versão #APIs Crescimento%
1.0 7,949
1.1 10,239 +29%
1.2 10,285 +0%
1.3 13,122 +28%
1.4 13,140 +0%
1.5 13,355 +2%
1.6 13,501 +1%
2.0 32,638 +142%

A versão 2.0 do .NET Standard suporta 142% mais APIs que a versão anterior. Um salto incrível no número de APIs suportadas.

Muita calma nessa hora!

Isto não significa que um código escrito para .NET Framework 4.6.1 seja 100% compatível com o .NET Core 2.0.
Existem muitas APIs no .NET Framework que não são implementadas pelo .NET Standard 2.0, logo também não serão suportadas no .NET Core 2.0.

A única compatibilidade entre versões .NET são aquelas cobertas pelo .NET Standard.

Como descobrir se o código está 100% coberto pelo .NET Standard?

Utilize o API Port para analisar se o código está 100% coberto por uma versão específica do .NET Standard. É possível rodar o analyzer via linha de comando ou via Visual Studio.

apiport analyze -f C:\src\mylibs\ -t “.NET Standard,Version=2.0”

Com .NET Standard é muito mais fácil!

O .NET Standard foi criado para que o compartilhamento e a reutilização de código entre várias plataformas .NET se tornem muito mais fáceis.

Desenvolver um Nuget Package será muito mais fácil, basta apontar o target da class library para uma versão específica do .NET Standard ao invés de distribuir uma versão específica para cada framework.

Saiba mais

Documentação oficial
https://docs.microsoft.com/pt-br/dotnet/standard/net-standard

Explore quais APIs são suportadas em cada versão do .NET Standard
https://docs.microsoft.com/en-us/dotnet/api/?view=netstandard-2.0

Confira a FAQ do .NET Standard
https://github.com/dotnet/standard/blob/master/docs/faq.md

Acompanhe a atualização de versões do .NET Standard
https://github.com/dotnet/standard/blob/master/docs/versions.md


Caso esteja interessado em conhecer mais sobre ASP.NET, DDD, Padrões de Arquitetura e boas práticas de desenvolvimento não deixe de conferir as ementas dos meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

SOLID – OCP e Extension Methods

Extension Method é um recurso presente desde o C# 3.0 e que facilita bastante o uso do OCP – Open Closed Principle.

SOLID - Teoria e Prática

Os extension methods permitem que você adicione comportamentos em classes existentes sem precisar modificá-las. Os extension methods são um tipo especial de método estático, porém são chamados como se fossem métodos de instância na classe estendida.

Para o código escrito em .NET não há nenhuma diferença entre chamar um extension method ou os métodos realmente definidos em uma classe.

Como um recurso tão importante como este pode passar desconhecido por diversos desenvolvedores? É por este motivo que escrevi este artigo.

No SOLID os extension methods são perfeitos para aplicar OCP – Open Closed Principle de uma forma muito natural e proporcionando um código de baixo acoplamento.
Caso você não conheça todos os princípios do SOLID assista este tutorial completo.

Para demonstrar mais facilmente como utilizar os extension methods e aplicá-los ao OCP eu gravei um vídeo de 18 minutos onde rapidamente explico tudo.

* Assine meu canal no Youtube 🙂

O código fonte desta solução está disponível no GitHub

Referências


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

EF Code-First – Partindo de uma base existente

Utilizar o Entity Framework com Code-First a partir de uma base existente é possível e relativamente fácil, inclusive melhorando a nomenclatura da base.

Neste vídeo tutorial iremos acompanhar como funciona o processo de criação de um sistema novo partindo de uma base já existente e utilizando Entity Framework no modelo Code-First.

Entity Framework Code-First

Como apresentado no vídeo os modelos guiados por design e que geram EDMX estão obsoletos, geram muita dificuldade na manutenção e não serão mais suportados na próxima versão do Entity Framework (7).

Neste tutorial iremos aprender:

  • Diferenças entre Model-First, Database-First e Code-First.
  • Instalar o EF Power Tools.
  • Customização de templates T4 para geração de classes.
  • Fazer engenharia reversa do banco criando classes POCO e mapeamentos com Fluent API.
  • Melhorar a nomenclatura das classes e mapeamentos quando o banco de dados não possui padronização ou está num padrão não apropriado para nomenclatura das entidades na aplicação.
  • Atualizar o banco de dados com Migrations
  • Como atualizar o código quando houver alteração direta no banco de dados.
  • Resolver problemas comuns do processo de engenharia reversa.

Vídeo

* Assine meu canal no Youtube 🙂

Vamos continuar com a troca de experiências, deixe seu comentário abaixo.

Referências

SOLID – Teoria e Prática – Demo + Vídeo

SOLID – Teoria e Prática. É com certeza um dos temas mais debatidos no ramo de OOP, aprenda cada um dos princípios e como aplicá-los.

Este é um artigo complementar ao Orientação a Objeto – SOLID, neste primeiro artigo eu apresentei teoricamente o conceito do SOLID e seus benefícios.

SOLID – Teoria e Prática

Recapitulando

SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.

Os princípios SOLID deveriam ser aplicados por qualquer desenvolvedor, porém pouquíssimos profissionais preocupam-se em utilizá-los, para obtermos todos os reais benefícios da OOP é necessário atender aos 5 princípios do SOLID.

Lembrando também que além destes 5 princípios Uncle Bob também mapeou 3 outros princípios sobre Coesão e mais outros 3 sobre Acoplamento. Utilize este link para conhecê-los também.

SLIDES

VÍDEO (1h00)

* Assine meu canal no Youtube 🙂

SOURCE

Para visualizar o fonte e realizar o download do projeto clique aqui (GitHub)

Referências

Vamos continuar enriquecendo o assunto, poste aqui sua opinião ou dúvida.

O Futuro do ASP.NET vNext – MVC 6

Você já parou para pensar no futuro do ASP.NET daqui alguns anos? O futuro chegou e foi anunciado hoje! Quem acompanha já deve ter reparado no termo OWIN ou lido algo sobre Project Katana / Helios, etc. Hoje uma página de 12 anos foi virada para um novo tempo. Conheça aqui o ASP.NET do Futuro.

ASP.NET vNext

O artigo é extenso e foi utilizada uma linha cronológica para apresentar todo o processo da evolução do ASP.NET.

Um breve olhar no passado do ASP.NET

O ASP.NET desde seu lançamento foi criado originalmente para dois publicos em específico:

  • Desenvolvedores ASP Clássico
  • Desenvolvedores Windows

O resultado não podia ser diferente, a primeira versão do ASP.NET conhecida como Web Forms é uma combinação do desenvolvimento Windows (componentes ricos, desenvolvimento rápido, arrastar e soltar) com a plataforma Web.

Para suportar toda a riqueza de funcionalidades do Web Forms foi necessário implementar muitas classes no .Net Framework, este que por sua vez é mono-bloco, ou seja, muitas funcionalidades estão acopladas em um único assembly, o System.Web (núcleo de objetos HTTP e o próprio framework de WebForms).

Devido a isso o ASP.NET sempre esteve fortemente acoplado ao .Net Framework e dependente de um específico Web host, o Internet Information Services (IIS).

O ASP.NET Web Forms foi a única forma conhecida de ASP.NET durante muitos anos.

Evolução da plataforma ASP.NET e suas dificuldades

Quem desevolve com ASP.NET desde seus primórdios sabe que antigamente era necessário muito tempo (ordem de anos) para que fosse liberada uma nova versão do ASP.NET, e isso nunca foi bom, pois as outras plataformas avançavam muito mais rápido, muitas novas tecnologias surgiam e o ASP.NET precisava se manter competitivo para atender as novas necessidades.

O grande ponto é que o ASP.NET sempre precisou crescer numa velocidade muito maior do que o .NET Framework cresce, porém ambos sempre estiveram muito acoplados através do System.Web que faz parte do .NET Framework, ou seja, muitas vezes para a implementação de um simples recurso no ASP.NET poderia haver algum impacto no .NET Framework e que por sua vez poderia demorar anos até receber a atualização para suporte a tal recurso.

Além do problema do alto acoplamento, por mais que o ASP.NET e o .NET Framework recebessem novas funcionalidades a adoção era demorada demais, o motivo maior é que as empresas não atualizam o .NET Framework de imediato, é necessário todo um processo de validação, revisão de plataforma, homologação e etc, até hoje em 2014 boa parte dos servidores de hospedagem não trabalham com a versão 4.5 do .NET Framework.

O desenvolvedor muitas vezes precisava esperar anos e anos para utilizar um novo recurso da plataforma.

Como resolver isso?

Solução número 1 – Separar

O ASP.NET MVC foi introduzido em 2007-2008 sendo que é distribuido separadamente do ASP.NET clássico, ou seja, isso aumentou a velocidade da entrega de novidades para o ASP.NET as versões do MVC foram entregues como complemento através de novas versões do Visual Studio, via NuGet ou via o aspnetwebstack do ASP.NET, onde é possível utilizar as versões dos build noturnos, código ASP.NET que foi desenvolvido a menos de 24 horas.

Quem desenvolve com ASP.NET há algum tempo vem nos últimos anos presenciando muitas mudanças, além do ASP.NET MVC ainda vieram o Razor, Web API, SignalR, SPA, ASP.NET Identity e todos foram distribuidos separadamente.

Existe a sensação que a Microsoft esta com grande foco em evoluir a plataforma ASP.NET, atualmente em média de a cada seis meses é liberada uma nova versão ou novas funcionalidades / tecnologias agregadas ao ASP.NET. para que ela se mantenha altamente competitiva entre as demais de mercado, e isso já é fato, analisando a produtividade em utilizar ASP.NET com Visual Studio e todas as vantagens que o ASP.NET oferece, fica muito claro o motivo pelo qual cada vez mais empresas e profissionais adotam o ASP.NET como plataforma oficial de desenvolvimento Web.

Para um maior detalhamento assista meu vídeo da palestra Novidades do ASP.NET MVC 5.x

Mesmo com a separação do ASP.NET MVC em relação ao ASP.NET clássico ainda existe uma forte dependência com o System.Web e por sua vez a necessidade de utilizar IIS como única opção de Host.

Quando iniciamos um projeto em ASP.NET MVC, por mais que seja um simples “Olá Mundo!” pode ser que não tenha reparado, mas as dependências com o System.Web estão lá, o System.Web provê suporte a envio de e-mail, controles do Web Forms, sessão e etc… Você não precisa disso? Não importa, vai ter que usar, pois se tirar o System.Web de suas referências seu projeto simplesmente não vai funcionar.

O outro problema é que por mais que o ASP.NET MVC tenha capacidade de ser uma plataforma leve e performática ela sofre uma boa perda devido ao fardo do System.Web que precisa estar presente para fazer o pipeline com o IIS.

Solução número 2 – Quebrar as dependências.

Em 2012-2013 surgiram o ASP.NET SignalR e ASP.NET WebAPI, estes dois componentes ASP.NET não possuem nenhuma dependência com o System.Web, foram desenvolvidos para levar o ASP.NET a um novo patamar, a da independência de plataforma, pois tanto o SignalR como o WebAPI podem rodar em ambientes não Microsoft (Linux/OSx).

Essa foi a quebra da independência ao legado do System.Web, mas até então apenas estes dois componentes podiam rodar independente do IIS, System.Web e Windows.

Foi neste momento que a comunidade técnica conheceu o OWIN.

Apresentando o OWIN

Desde meados de 2009 o ASP.NET se tornou open source e devido a este fato a comunidade técnica pode se juntar ao time de engenheiros da Microsoft para conhecer e implementar melhorias e sugestões. Foram os próprios membros da comunidade técnica que baseando-se no design do Node.js e do Rack da comunidade Ruby, criaram uma especificação chamada OWIN (Open Web Interface for .NET).

O OWIN define uma interface padrão entre servidores Web e aplicações .NET.
O objetivo da interface OWIN é desacoplar o servidor e a aplicação, incentivar a criação de módulos simples para o desenvolvimento em ASP.NET, e, por ser um padrão aberto, estimular o ecossistema open source de ferramentas .NET de desenvolvimento Web.

Resumidamente o OWIN é uma camada de abstração entre o server e a aplicação.

O objetivo do OWIN é que novos componentes possam ser facilmente desenvolvidos e consumidos, porém de forma agnostica, ou seja, que possam rodar em outras plataformas como Unix (Mac/Linux) e que possam ser portados de uma plataforma para outra sem necessidade de recompilação.

  • É um “standart” uma especificação.
  • Não existe exatamente como código ou componente.
  • É a descrição de como idealmente o comportamento de sua implementação deve funcionar.

Katana Project

É uma implementação Microsoft da especificação OWIN no ASP.NET.

A Microsoft apostou na proposta do OWIN e o implementou nos projetos ASP.NET SignalR e ASP.NET WebAPI, essa implementação recebe o nome de Katana Project. Mais tarde o ASP.NET Identity surgiu implementando bibliotecas do Katana Project também.

Além da Microsoft, outros projetos implementam OWIN como NancyFx, FubuMVC, NOWIN etc.

Confira no vídeo abaixo mais detalhes sobre arquitetura OWIN – Katana Project.

Project Helios

A implementação do OWIN atrávés do Katana Project proporcionou a criação de componentes ASP.NET muito mais leves, performáticos, independentes de plataforma e SelfHost, porém caso seja necessário contar com alguns recursos que o Host ASP.NET clássico (IIS) provê, tudo isso fica a cargo do desenvolvedor da aplicação.

O IIS apesar de trabalhar apenas no pipeline do ASP.NET clássico (System.Web) possui uma série de benefícios que nem sempre podem ser deixadas de lado:

  • IIS lida com gerenciamento da vida útil aplicação.
  • Ele pode suspender (em vez de encerrar) processos que estão ociosos para ajudar a equilibrar os recursos disponíveis do sistema.
  • IIS oferece um cache de modo de usuário embutido e pode comprimir automaticamente o conteúdo dos responses se for o caso.
  • IIS suporta filtragem de requests e transient worker process identities.
  • Mais de 10 anos de implementações e melhorias de segurança.
  • No cenário do Self Host você é responsável por muitas das responsabilidades que o IIS toma conta, além disso ele já existe para isso por que não utilizá-lo?

São esses os motivadores do Project Helios, porém devido à necessidade do IIS trabalhar no pipeline no System.Web muita performance seria perdida, por isso o Project Helios trabalha apenas com o “Core” do IIS o utilizando como uma espécie de API, o “Core” do IIS é extremamente rápido e poderoso, pois disponibiliza apenas as suas funcionalidades sem depender do pipeline do ASP.NET clássico (System.Web).

O Project Helios oferece suporte aos projetos desenvolvidos em Katana (OWIN), porém não é dependente dele para ser utilizado, é possível desenvolver uma aplicação baseada apenas em Project Helios que rodará apenas no padrão IIS e não terá opções de SelfHost e multiplataforma, em uma arquitetura de aplicações para Windows pode ser muito vantajoso, pois é pelo menos 96% mais rápido que o ASP.NET clássico. Na demo exibida no vídeo abaixo o resultado foi quase 6x mais rápido utilizando Helios.

Requerimentos mínimos para utilização do Project Helios

  • Windows 8 ou Windows Server 2012
  • .NET Framework 4.5.1
  • Visual Studio 2012 ou 2013

Resumo Cronológico

O ASP.NET desde seu lançamento sofreu com a grande demora de liberações de novas versões, algumas plataformas novas surgiram e passaram a frente devido uma evolução mais rápida, com a implementação do ASP.NET MVC esse tempo de liberações diminuiu, porém a plataforma ainda era limitada em relação às outras devido a herança historica do Web Forms (System.Web) em seu pipeline, impedindo que algumas melhorias fossem implementadas.

Com o surgimento do OWIN e os projetos Katana e Helios novas frentes se abriram e a engenharia do time de ASP.NET começou a trabalhar em uma nova versão, a maior e melhor mudança do ASP.NET em todo o seu período de existência, hoje o futuro chegou.

ASP.NET vNext – MVC 6

Foi anunciado dia 13/05 durante uma sessão do TechEd North America 2014 a nova versão do ASP.NET chamada vNext e que vai mudar tudo o que você sabe sobre ASP.NET, é um novo paradigma, um novo stack, tudo que os desenvolvedores Web mais maduros sabiam que era possível e torciam para que um dia fosse feito.

Todos os nomes que vimos como Katana, Helios e ASP.NET vNext provavelmente irão mudar, são nomes dados para projetos em execução, na versão final ganham um outro nome mais familiar.

Você desenvolvedor ASP.NET veterano, levante agora da cadeira e aplauda, você está diante a maior mudança do ASP.NET em seus 12 anos de existência. Você iniciante ASP.NET nem pense em Web Forms, caia direto nesse stack e comece a entender tudo como funciona daqui pra frente.

O que mudou

  • Web Pages, MVC, Web API agora é uma coisa só, chamado de MVC 6
  • Novas versões otimizadas para nuvem do MVC 6, SignalR 3 e Entity Framework 7
  • Acabou a dependência do System.Web, MVC 6 agora é um middleware, leve e performático, agora apenas o Web Forms depende (para sempre) do System.Web.
  • Versões otimizadas para nuvem do MVC, Web API, Web Pages, SignalR e Entity Framework.
  • Maior portabilidade, não existe dependência de assemblies do GAC facilitando o deploy em nuvem e em ambientes não Windows (Linux/OSx/Etc)
  • Possibilidade de hospedar sua aplicação no IIS ou em um processo self hosted
  • Injeção de dependência nativa dentro do framework
  • Suporte ao legado do Web Forms, MVC 5, Web API 2, Web Page 3 , SignalR 2 e EF 6
  • Deploy do runtime e framework com a sua aplicação, possibilitando rodar lado a lado 2 versões diferentes do framework
  • Arquivo project.json irá integrar o arquivo de projeto (.csproj), o packages.config e o Nuget specifications (nuspec);
  • Suporte ao Rosyln, ou seja, não precisa mais parar a aplicação para alterar uma classe, basta alterar salvar e dar F5 no browser, pronto! Muita produtividade!
  • Tudo é entrege via NuGet até o runtime!
  • Mais open source que nunca (foi para o GitHub) e faz parte do .Net Foundation.
  • Baixissimo consumo de memória
  • Completamente Multiplataforma!!! Rode ASP.NET onde quiser!

Veja alguns screenshots

Assista ao vídeo da palestra – O Futuro do ASP.NET + Novidades do vNext – MVC 6

Acompanhe os slides da palestra

Assista esse vídeo exibindo como rodar a nova versão do ASP.NET vNext – MVC 6

Bons estudos!!!

Referências

Vamos continuar a troca de conhecimentos, escreva seu comentário abaixo 😉

Ebook – Guia .Net para Aplicações Corporativas.

Guia .Net para Aplicações Corporativas (título traduzido) é um e-Book gratuito com um conteúdo muito recente e atualizado, ideal para arquitetos e desenvolvedores que desejam ampliar os conhecimentos sobre abordagens e tecnologias disponíveis para construir aplicações corporativas modernas.

Guia .Net para Aplicações Corporativas

Fiz o download desde e-Book hoje, já li cerca de 40% e estou gostando o suficiente para compartilhar com vocês. Confira o conteúdo:

.NET Technology Guide for Business Applications

  1. Key takeaways
  2. Purpose of this guide
    • WHO SHOULD USE THIS GUIDE
    • HOW TO USE THIS GUIDE
  3. Overview
    • THE NET FRAMEWORK AND THE FUTURE OF DEVELOPMENT
  4. Emerging application patterns
    • DEVICES
      • Native applications for Windows devices
      • Web applications for any device
    • SERVICES
    • CLOUD AND HYBRID-CLOUD
    • END-TO-END SCENARIOS IN EMERGING APPLICATION PATTERNS
      • Scenario: Connected Native Windows Store Applications
      • Scenario: Modern Web Applications for Any Mobile Device (Tablets and phone)
  5. Established application patterns
    • BUSINESS APPLICATIONS SEGMENTATION BY PRIORITIES
    • SMALL AND MEDIUM-SIZED BUSINESS APPLICATIONS
      • Data-centric web business applications
      • Scenario: End-to-End Small/Medium Web Business Applications
      • Mixed approach for small/medium business web applications
      • Data-centric desktop business applications
      • Scenario: Small/Medium 2-Tier Desktop Application
      • Scenario: Small/Medium 3-Tier Desktop Applications
      • Modernizing desktop business applications
      • Modernizing applications based on RIA containers
    • CLOUD APP MODEL FOR OFFICE AND SHAREPOINT
      • Apps for Office
      • Scenario: Connected Apps for Office
      • Apps for SharePoint
      • Scenario: Connected Apps for SharePoint
    • LARGE, MISSION-CRITICAL BUSINESS APPLICATIONS
      • NET in large, mission-critical and core-business applications
      • Technology selection for large mission-critical and core-business applications
      • Scenario: Large, Core-Business Applications
      • Approaches and trends for long-term core-business applications
      • Loosely coupled architecture and the dependency-inversion principle
      • Architectural styles for core-business applications
      • Modernizing mission-critical enterprise applications
      • Scenarios for custom large, mission-critical applications
      • Scenario: Domain-Driven Subsystem (Bounded Context)
      • Scenario: CQRS Subsystem (Bounded Context)
      • Scenario: Communicating Different Bounded Contexts
      • NET Technology Guide for Business Applications
      • Scenario: Modernizing Legacy Mission-Critical Enterprise Applications
  6. Conclusions
    • Appendix A: Silverlight migration paths
    • Appendix B: Positioning data-access technologies

O download está disponível neste link. (PDF 6.02 MB)

Referencias

Boa leitura a todos!

ASP.Net Web API – Meu primeiro serviço REST

ASP.Net Web API é um framework que facilita a construção de serviços REST HTTP que alcançam uma grande variedade de clientes incluindo Mobile, Browsers e aplicações locais. É a plataforma ideal para construção de serviços REST baseados em .Net

Com o lançamento do ASP.Net MVC 4 em 2012 uma das novas features foi o ASP.Net Web API, entenda como funciona e aprenda a criar sua primeira aplicação HTTP REST.

Introdução

Serviços de internet são populares já faz um bom tempo, WebServices foram desenvolvidos e consumidos durante longos anos sendo uma tecnologia livre de plataforma, ou seja, aplicações .Net e Java se comunicam por WebServices sem dependência de tecnologias. Nos anos seguintes a Microsoft lançou o Remoting e por fim o famoso WCF que engloba (HTTP, TCP, MQ).

Apesar do Remoting e WCF serem tecnologias Microsoft o que WebServices, Remoting e WCF tem em comum? Todos eles são baseados em SOAP (Simple Object Access Protocol). O SOAP é baseado em XML e busca padronizar o conteúdo que é trafegado entre as pontas. O problema do SOAP é que algumas plataformas não conseguiram acompanhar sua evolução e a adoção se tornou complicada devido sua implementação, por este motivo começaram a surgir soluções alternativas mais simples.

Uma solução alternativa ao SOAP e altamente adotada é o REST (Representational State Transfer), baseado totalmente em HTTP e seus recursos. Para o melhor entendimento sobre ASP.Net Web API e REST sugiro conhecer um pouco sobre o protocolo HTTP.

Grandes empresas como Google, Facebook, LinkedIn, Netflix entre diversas outras já disponibilizam APIs Web para serem consumidas, todas elas são baseadas em HTTP com REST.

O ASP.Net Web API utiliza HTTP com REST e diferente do SOAP não depende de XML para trafegar as informações, o formato padrão para isso é JSON (Java Script Object Notation).

JSON é um formato amplamente utilizado em qualquer plataforma (não apenas .Net),  é um subconjunto da notação de objeto de JavaScript, mas seu uso não requer JavaScript exclusivamente. Isso proporciona um potencial muito grande para os serviços HTTP, pois é um formato intercambiável, leve e livre de plataformas.

É possível retornar XML com Web API ao invés de JSON ou outros formatos como CSV. Também é possível criar um formato próprio para retornar os dados, tudo fica a critério do desenvolvedor.

Mão na massa

Vamos iniciar a construção do nosso serviço REST com ASP.Net Web API, para isso este exemplo irá utilizar o Visual Studio 2012. Crie um novo projeto Web ASP.Net MVC 4.

ASP.Net Web API

Escolha o Template do ASP.Net Web API.

ASP.Net Web API

Espere seu projeto ser criado e será exibida esta tela inicial (clique para expandir).

ASP.Net Web API

Note que apesar de ser um template para construção de serviços o projeto não deixa de ser ASP.Net MVC, no caso da criação de um projeto MVC + Web API não é necessário ter dois projetos na mesma solution, utilize apenas o template ASP.Net Web API.

Rodando pela primeira vez a aplicação (F5).

ASP.Net Web API

Uma Web Application no layout padrão do ASP.Net MVC 4 foi criada, você pode utilizar este site para criar a documentação e apresentação de sua Web API.

Com o projeto configurado a proposta é construir um serviço de consumo do cadastro de clientes, o serviço irá realizar consultas no modelo de dados que iremos criar.

Na pasta Model adicione uma nova classe chamada Cliente.

public class Cliente
{
    public int ID { get; set; }

    public string Nome { get; set; }

    public string Email { get; set; }

    public bool Ativo { get; set; }
}

Na sequência crie uma Controller para trabalhar com a classe de Clientes (clique direito na pasta Controller > Add > Controller)

ASP.Net Web API

Observe que nesse exemplo está sendo utilizada uma opção de Scaffolding para criar uma Controller de Web API vazia, porém com as actions de leitura e escrita, caso estivéssemos utilizando Entity Framework a opção acima da selecionada já criaria uma estrutura com o CRUD e etc…

Com a Controller criada eis o código gerado.

using System.Collections.Generic;
using System.Web.Http;

namespace MeuServicoWebAPI.Controllers
{
    public class ClienteController : ApiController
    {
        // GET api/cliente
        public IEnumerable Get()
        {
            return new string[] { "value1", "value2" };
        }

        // GET api/cliente/5
        public string Get(int id)
        {
            return "value";
        }

        // POST api/cliente
        public void Post([FromBody]string value)
        {
        }

        // PUT api/cliente/5
        public void Put(int id, [FromBody]string value)
        {
        }

        // DELETE api/cliente/5
        public void Delete(int id)
        {
        }
    }
}

Total semelhança com MVC certo? Digo inclusive que é mais fácil construir uma Web API do que uma WebApp com MVC.

Como diferenciar uma Controller MVC de uma Controller Web API?
Uma Controller Web API herda de ApiController enquanto uma Controller MVC herda de Controller. Essa é a forma mais fácil de identificar.

Um ponto importante, o MVC assim como o Web API possuem rotas pré-definidas, no template de projeto a rota do MVC fica no arquivo RouteConfig.cs enquanto a do Web API fica no arquivo WebApiConfig.cs, ambas na pasta App_Start.

Observe as duas rotas.

// Rota Web API
config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );

// Rota MVC
routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
            );

Existem algumas diferenças, mas a que é mais importante de entender é que no caso da rota MVC a sequencia padrão será {controller}/{action}/{id} já na rota Web API a sequência é api/{controller}/{id}, sendo que “api” é um valor hard coded e não temos uma action configurada para ser chamada na URI.

Sendo assim como a rota do Web API sabe qual método está sendo chamado?

É um ponto muito importante a entender, por convenção do ASP.Net Web API os nomes dos métodos expressam a ocasião em que eles serão chamados. Dado os métodos da Controller acima:

  • Get
  • Post
  • Put
  • Delete

Estes são os nomes dos métodos e também são alguns dos verbos aceitos pelo HTTP, falando em HTTP para os verbos listados teríamos os seguintes comportamentos:

  • Get = Select
  • Post = Insert
  • Put = Update (ou Insert)
  • Delete = Delete

Ou seja, através do HTTP quando for realizado um GET via URI o Web API retornará o resultado do método Get, um POST via formulário o Web API fará uma inclusão através do metodo Post, PUT via formulário uma alteração através do método Put e DELETE via URI uma exclusão através do método Delete.

Vale lembrar que isso é uma convenção e podemos fazer de outras formas, por exemplo, o método Get poderia ser GetClientes, funcionaria da mesma forma, pois inicia com Get.
Se um método for criado como RetornarClientes seria necessário especificar qual verbo HTTP este método aceita, uma vez que o Web API não reconheceria sozinho qual dos métodos executar, nesse caso ficaria assim:

// Definindo qual o verbo o método aceita.
[AcceptVerbs("GET")]
public IEnumerable RetornarClientes()
{
    return new string[] { "value1", "value2" };
}

Especificando o tipo de verbo aceito no método podemos definir livremente a nomenclatura a ser utilizada sem depender da convenção padrão.

Atenção, cuidado ao definir os verbos aceitos, pois se um método tiver a mesma estrutura (mesmo verbo aceito e mesmo tipo de parâmetros recebidos) irá resultar em uma exception, pois o Web API não saberá qual dos métodos deverá executar.

Partindo da estrutura da Controller gerada faremos ela trabalhar com o modelo de dados da classe Cliente.

using System.Linq;
using System.Web.Http;
using MeuServicoWebAPI.Models;

namespace MeuServicoWebAPI.Controllers
{
    public class ClienteController : ApiController
    {
        private readonly Cliente[] Clientes = new Cliente[]
                {
                    new Cliente { ID = 1, Nome = "Eduardo Pires", Email = "[email protected]", Ativo = true },
                    new Cliente { ID = 2, Nome = "Bill Gates", Email = "[email protected]", Ativo = true },
                    new Cliente { ID = 3, Nome = "Aleister Crowley", Email = "[email protected]", Ativo = false }
                };

        // GET api/cliente
        public Cliente[] Get()
        {
            return Clientes;
        }

        // GET api/cliente/5
        public Cliente Get(int id)
        {
            var clientes = Clientes;

            return clientes.SingleOrDefault(x => x.ID == id);
        }

        // POST api/cliente
        public void Post([FromBody]string value)
        {
        }

        // PUT api/cliente/5
        public void Put(int id, [FromBody]string value)
        {
        }

        // DELETE api/cliente/5
        public void Delete(int id)
        {
        }
    }
}

*Para os métodos diferentes de Get (Post, Put, Delete) seria necessária uma estrutura de gravação de dados que não será abordada nesse exemplo.

Executando a aplicação testaremos a chamada do serviço ASP.Net Web API.
Primeiramente será chamado o método Get para testar se o serviço retornará toda a lista de clientes. Observe a URI no browser.

ASP.Net Web API

O serviço funcionou e respondeu sendo chamado pelo browser, o retorno foi em XML, pois o browser não interpreta JSON, por padrão o Web API está configurado para responder JSON sempre que possível.

Para testar com mais detalhes usaremos uma ferramenta chamada Fiddler (recomendo fortemente o conhecimento e uso desta ferramenta).

Nesse exemplo será chamado o método Get que aceita o parâmetro Id e retornará um dado de cliente específico através de uma pesquisa executada no método. Primeiramente chamaremos o serviço Web API através da aba Composer, note que o verbo escolhido é o Get e que agora está sendo informado o valor do Id do cliente na URI do serviço. Clicando no botão Execute será feita a chamada.

ASP.Net Web API

Na coluna da direita é possível observar que a consulta foi feita e o retorno dela é o código HTTP 200 (OK). Clicando no item desta coluna observe o retorno em JSON que será exibido pela ferramenta.

ASP.Net Web API

O serviço retornou um dado de cliente específico para esta consulta. Para ter uma visão completa do retorno clique na aba Raw, localizada ao lado da aba JSON.

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?RDpcTGFic1xNZXVTZXJ2aWNvV2ViQVBJXE1ldVNlcnZpY29XZWJBUElcYXBpXGNsaWVudGVcMg==?=
X-Powered-By: ASP.NET
Date: Thu, 11 Jul 2013 03:58:17 GMT
Content-Length: 71
{"ID":2,"Nome":"Bill Gates","Email":"[email protected]","Ativo":true}

A última linha é o retorno JSON da consulta em texto puro sem a formatação da ferramenta, observe que é muito mais simples que XML.

O serviço Web API está funcionando e retornando uma lista de clientes ou um cliente específico através de seu ID, basta agora ser consumido por qualquer tipo de aplicação.

Para aprender mais

Recentemente o Israel Aece lançou um e-Book gratuito sobre ASP.Net Web API, faça o download dele aqui. Recomendo a leitura.

O site oficial do ASP.Net Web API também possui diversos exemplos e tutoriais essenciais no aprendizado.

Resumo

Podemos observar que é muito simples criar um serviço REST HTTP utilizando ASP.Net Web API e para quem está habituado com ASP.Net MVC é mais simples ainda.

A ferramenta Fiddler ajuda muito em testes, podemos observar com riqueza os valores retornados e os códigos de HTTP, muito útil no caso de uma análise.

Continue acompanhando os posts da série, no próximo sobre Web API abordarei segurança com Autenticação e Autorização e exemplos de um site consumindo o retorno em JSON do serviço Web API.

Referências

Gostou do artigo? Comente e compartilhe suas impressões nos comentários abaixo 😉

ASP.Net MVC 5 – O que há de novo?

O ASP.Net MVC 5 foi anunciado no Microsoft Build Developer Conference 2013 (25/06 -28/06), onde foram também anunciadas ótimas novidades para o ASP.Net em geral em conjunto com o novo Visual Studio 2013.

ASP.Net MVC 5

ASP.NET MVC 5

One ASP.Net
Os templates de projeto ASP.Net MVC 5 integram-se em uma nova experiência de uso chamada One ASP.Net. Agora é possível customizar o template MVC e configurar o tipo de autenticação durante o processo de criação do projeto através do Wizard.
Todo projeto ASP.Net MVC 5 agora é uma Web Application padrão e não possui um próprio project GUID.

ASP.NET Identity
Os templates de projeto ASP.Net MVC 5 foram atualizados para utilizar o ASP.NET Identity para autenticação e gerenciamento das identidades.
Conheça mais sobre o ASP.Net Identity:
Introducing ASP.NET Identity – A membership system for ASP.NET applications

Bootstrap
Os templates de projeto ASP.Net MVC 5 foram atualizados para utilizar o Bootstrap, proporcionando um visual elegante e responsivo.
Conheça o Bootstrap

Authentication Filters
Authentication Filters são um novo tipo de filtro no ASP.NET MVC 5.
São executados antes dos filtros de autorização no pipeline ASP.NET MVC e permitem que você especifique uma lógica de autenticação “per-action”, “per-controller” ou globalmente para todos os controllers.

Authentication Filters processam credenciais durante um request e também podem adicionar “challenges” de autenticação em resposta à solicitações não autorizadas.

Filter Overrides
Agora é possível sobrescrever os filtros que se aplicam a uma determinada action ou controller especificando um conjunto de tipos de filtros que não devem ser executados em um determinado escopo (action ou controller).

Isso permite que sejam configurados os filtros que se aplicam globalmente, porém em seguida excluir determinados filtros globais da aplicação em actions ou controllers específicos.


Assista ao anuncio das novidades do ASP.Net feitas por Scott Hanselman

Resumo

Eu sempre considerei o ASP.Net MVC 4 uma versão excelente e completa, podemos notar que não foram anunciadas muitas novidades para a versão do ASP.Net MVC 5, afinal acredito que é difícil melhorar o que já era ótimo.

As mudanças em conjunto com o Visual Studio 2013 vão proporcionar mais facilidade e velocidade para criação de aplicações ASP.Net, as melhorias desta nova versão atendem diversas necessidades que eram contornadas de outras maneiras.

O Visual Studio 2013 com ASP.Net MVC 5 é um recente lançamento, pretendo abordar separadamente em artigos detalhados cada uma das novidades aqui listadas, continue acompanhado.

Referencias

Gostou do artigo? Compartilhe e deixe seu comentário abaixo 😉

ASP.Net MVC – Cuidado com links de exclusão “Delete” – Pode ser uma falha de segurança

ASP.Net MVC – Ao expor informações de um banco de dados, cuidado com o link do tipo “Delete”, siga essa dica para evitar uma falha de segurança em seu site.

Vamos supor que em nosso site ASP.Net MVC possuímos uma controller “FuncionarioController”, essa controller é responsável pelos métodos de CRUD da sua entidade Funcionario relacionada ao seu banco de dados.

Como o seu ActionResult de exclusão deveria estar escrito? Vamos observar este exemplo:

// GET: /Funcionario/Delete/5

public ActionResult Delete(int id = 0)
{
   Funcionario funcionario = db.Funcionario.Find(id);

   if (funcionario == null)
   {
      return HttpNotFound();
   }

   db.Funcionario.Remove(funcionario);
   db.SaveChanges();

   return RedirectToAction("Index");
}

Algo de estranho?
Teoricamente está tudo certo, o código está validando se o ID existe mesmo e caso não exista o usuário será redirecionando para uma página de erro, assim evitando em exibir mensagens de erro do banco de dados.

Mas nesse código habita uma grande falha de segurança, o ActionResult Delete é um método Get, ou seja, pode ser chamado diretamente de uma URL. O que aconteceria se alguém mal intencionado digitasse no browser a seguinte URL:

www.meusite.com.br/Funcionario/Delete/1

Provavelmente o registro de funcionário com o ID = 1 seria excluído certo?
“Ah, mas minha aplicação requer login e senha para esse tipo de ação.”

Isso não evita de receber um ataque, imagine que um usuário mal intencionado deseja deletar um registro e envia um e-mail para um usuário desse sistema com uma imagem “para parecer inofensivo” e nessa imagem contenha um link para a URL que citamos acima. Se o usuário que recebeu o e-mail e clicou estiver conectado (logado) no sistema naquele momento já seria o suficiente para concretizar a exploração dessa falha.

DICA

Nunca escreva seus métodos Get de exclusão realizando a exclusão direta da base.
A dica completa seria:
Nunca escreva nenhum método Get realizando alteração de informações do sistema.

Como resolver?

Vamos observar uma maneira indicada para evitar a falha citada:

    // GET: /Funcionario/Delete/5

    public ActionResult Delete(int id = 0)
    {
        Funcionario funcionario = db.Funcionario.Find(id);

        if (funcionario == null)
        {
            return HttpNotFound();
        }
        return View(funcionario);
    }

    // POST: /Funcionario/Delete/5

    [HttpPost, ActionName("Delete")]
    public ActionResult DeleteConfirmed(int id)
    {
        Funcionario funcionario = db.Funcionario.Find(id);
        db.Funcionario.Remove(funcionario);
        db.SaveChanges();

        return RedirectToAction("Index");
    }

Repare que existem dois métodos ActionResult para exclusão, o método Get Delete não realiza a exclusão do registro, apenas verifica se ele existe e redireciona o usuário para uma View de visualização e confirmação de exclusão:

ASP.Net MVC Exclusão

Ao realizar a confirmação dos dados e clicar em excluir a página será submetida via Post para o método DeleteConfirmed, que é responsável pela exclusão da base de dados.

Repare no código que um método chama-se Delete (Get) e o outro DeleteConfirmed (Post), repare também que existe um atributo ActionName(“Delete”) decorando o método DeleteConfirmed, isso significa que ele pode ser chamado como Delete, isso é necessário, pois o CLR (common language runtime) do .Net requer que haja apenas um método com a mesma assinatura, como os dois métodos recebem o mesmo tipo de parâmetro não seria possível possuírem o mesmo nome.

Utilizando o atributo ActionName(“Delete”)  faz que o roteamento do site aceite o método DeleteConfirmed como Delete quando uma URL que inclua o /Delete/ for acionada via Post.

Resumo

Essa técnica evita que de forma indesejável um registro seja manipulado e por mais que haja sucesso na tentativa do usuário mal intencionado o site resultará em uma página de confirmação, logo o usuário logado poderá intervir a essa tentativa de burlar o sistema.

Todas as controllers criadas automaticamente em projetos no Visual Studio, seja na criação do projeto ou via scaffolding já preveem essa técnica, caso você esteja criando suas controllers manualmente, lembre-se dessa dica 😉

Referência

Gostou do artigo, teve alguma dúvida? Deixe sua mensagem nos comentários abaixo.