No capítulo anterior, falei sobre como o ASP.NET Web Forms resolveu o problema de quem estava no Delphi e não podia abraçar um paradigma completamente novo de desenvolvimento, e sobre os problemas de manter uma abordagem semelhante ao Delphi no desenvolvimento HTTP. Como adenso muito em várias questões, decidi deixar o detalhamento das migrações do Web Forms para este derradeiro capítulo, que também é útil para quem quer sair do Web Forms e ir para o ASP.NET MVC.

O ano é 2017. Já não moro mais no Brasil. Entre alunos, exercícios, livros, clientes e uma porção de coisas que inclui minha nova vida (afinal, morar em outro país é morrer um pouco e renascer mais um pouco), eis que surge um aluno que já havia concluído o Módulo 1 do Coding Craft para ASP.NET MVC, com muita dificuldade de terminar os exercícios dos onze capítulos. Vindo do Delphi, disse que seria ótimo se houvesse uma forma de casar os aspectos do Delphi, dos quais ele é muito mais familiar, com os aspectos do ASP.NET MVC, estabelecendo os paralelos em comum.

Fui programador Delphi também. A passagem de um para outro não é simples, conforme visto nas duas partes anteriores. Disse a ele que uma série de artigos teriam que ser produzidos, primeiro para embasar toda a questão migratória, e possivelmente um curso só sobre isso. De fato, o assunto é muito mais abrangente do que minha primeira impressão. Aqui está o texto introdutório. Em seguida, escreverei o curso.

Antes de finalmente falar de MVC, preciso falar de Windows Forms, que é um padrão que basicamente copiou o Delphi, mas que o apelo foi menor e não decolou tão bem, apesar de ainda ter um ótimo suporte até hoje.

Windows Forms

Paralelamente ao Web Forms, a Microsoft desenvolveu o Windows Forms, que é apenas a continuação natural do Delphi no C#. O mesmo esquema de janelas, o mesmo esquema de componentes, apenas aumentando o número de fontes comuns de 2 para 3 (foi adicionado um arquivo de Resource por form). Tamanha é a semelhança que as empresas que faziam componentes para Delphi passaram a fazer também componentes muito semelhantes para o Visual Studio, como a DevExpress e a DevArt.

Houve uma migração de programadores também do Delphi para o Windows Forms, mas não foi a plataforma predominante de mercado no início dos anos 2000. Até cheguei a fazer alguns sistemas em Windows Forms de 2009 a 2012, mas eram sempre sistemas auxiliares, sem grande força comercial. O apelo ao mundo Web já era muito mais forte.

No entanto, a Microsoft jamais descontinuou o suporte ao Windows Forms, que, de certa forma, ajudou a Microsoft nos próximos passos: o WPF, e com o advento do Windows Phone, a UWP. Os componentes e bibliotecas usados no Windows Forms são, em grande parte, também suportados em WPF e UWP.

Já está previsto em algum módulo do Coding Craft um capítulo sobre as semelhanças de Delphi e Windows Forms, em que vou detalhar isso mais a fundo.

ASP.NET MVC

E finalmente chegamos ao estado estável das coisas até então: o ASP.NET MVC. Na data deste texto, a versão 5 é a mais estável.

Parei no texto anterior na parte que eu falava de endpoints e manutenção de estados, e que eu diria que são dois pontos que mudam radicalmente do Delphi/Windows Forms/ASP.NET Web Forms para o ASP.NET MVC.

Endpoints

Para falarmos de endpoints, primeiramente precisamos falar de REST, a tal Transferência de Estado Representacional. O que ela é?

Em resumo, uma arquitetura em que cada interação com os provedores de informações são requisições e respostas em que não há a manutenção do estado das informações. Melhor dizendo, cada requisição pode ser replicada com o mesmo conjunto de informações a qualquer momento, podendo ter uma resposta diferente.

Por exemplo, suponha que você está no seu site de compras favorito e você está buscando por um determinado produto. Ao pesquisar por este produto, você preencherá alguns parâmetros em tela e enviará um comando para pesquisar no site com base naquelas informações. Se você salvar a página de resultado da pesquisa como Bookmark (favorito) e voltar nela outra hora, as informações dos filtros de pesquisa que você preencheu serão as mesmas. Os resultados podem mudar (como um produto sair de estoque, outro produto aparecer ou os preços e modelos do produto mudarem, mas a pesquisa é a mesma).

Note que numa tela de Delphi é impossível fazer isso, a não ser que seja implementado um mecanismo de salvar pesquisas dentro da aplicação (o que, aliás, era bastante comum). Você precisa entrar no sistema, fazer login, abrir uma tela principal, achar a tela de pesquisa, preencher os parâmetros para só depois disso de comandar a pesquisa obter os resultados. Para isso, o usuário teve que passar por vários estados da aplicação: tela de pesquisa fechada, tela de pesquisa aberta sem parâmetros, tela trabalhando em pesquisa, tela exibindo pesquisa.

É por isso que o uso de Sessions em ASP.NET MVC pode ser considerado como uma má prática: como o estado não é mais necessariamente mantido, ou seja, como qualquer tela pode ser acessada a qualquer momento, a manutenção de informações em memória de servidor é contraproducente.

A tradução de endpoint é "ponto de extremidade", mas é um nome estranho para o Português. Prefiro ponto de informações, e vou usar este termo.

Pensando no REST, um ponto de informações é acessado por um cliente. Seu navegador de Internet, como o Mozilla Firefox ou o Google Chrome são clientes. Seu aplicativo de celular também é, mas consumindo endpoints RESTful, que é assunto para outro texto. Ao acessar este blog na primeira página, seu navegador de Internet pede informações ao ponto de informações padrão (ou raiz). Como este blog é implementado em cima da arquitetura MVC, a requisição será usando o padrão REST e o protocolo HTTP. A programação do blog é feita para trazer os cinco artigos mais recentes que escrevi, no ponto de informações raiz. O retorno disso é um documento HTML com texto, fotos, folhas de estilo e, de vez em quando, até recursos multimídia, como música e vídeo.

Agora, suponha que você quer ler um artigo específico, como a parte 2 dessa série de artigos. Ao clicar para ler o texto, você verá o seguinte no endereço:

https://codingcraft.com.br/2017/04/17/como-sair-do-delphi-para-o-net-parte-2/

Repare que, entre barras após o endereço, temos algumas informações, como o ano, o mês, o dia e o título do texto. Essas informações são recebidas pelo ponto de informação raiz, que pesquisa pelo texto em banco de dados e o retorna, além de mais alguns recursos.

Se eu clicar uma centena de vezes no link ou acessar o endereço através de outros navegadores, o resultado deve ser mais ou menos o mesmo, dependendo do tamanho da tela do dispositivo que está acessando o site, até porque não pretendo mais editar esse texto. Independente do tamanho de tela, a massa de informações do texto é a mesma para qualquer dispositivo.

Há, ainda, outros pontos de informações, como por exemplo uma pesquisa por tags: http://www.codingcraft.com.br/tag/cursos-em-csharp/, ou ainda por autor: http://www.codingcraft.com.br/author/leonel/. Cada um desses endereços são pontos de informações diferentes, com identificadores de informações e valores também diferentes.

No MVC, cada ponto de informações está contido em um Controlador (ou Controller). O Controller contém toda a lógica necessária para orquestrar os diversos componentes da aplicação para estruturar uma informação que um ponto de informações irá devolver.

Cada elemento de dados é representado por um Modelo, ou Model. O Model contém as informações de cada registro, as informações de relacionamento com outras entidades e o comportamento de intercâmbio de informações, bem como alguns aspectos de validação.

Por mim, o que o Controller retorna ao usuário é uma massa estruturada de informações por meio de um componente de apresentação, chamado de Visão ou View. A View cadencia toda a informação numa distribuição espacial bem como coordena todo e qualquer comportamento visual que a tela terá quando receber a massa de informações do ponto de informações.

Cada requisição é feita por um método, ou verbo. O verbo para clicar em um link ou pressionar Enter na sua barra de endereços do navegador é chamado de GET. Gosto do nome verbo, então vai ser ele que vou usar.

Verbos

Cada ponto de informações pode interpretar vários verbos de formas diferentes.

O verbo GET, por exemplo, é o que chamamos de "verbo nulipotente", ou seja, a capacidade de manipulação de informações dentro de um sistema é muito pequena, sem poder, sem efeitos colaterais. Sua principal função é a de retorno simples ou filtrado de informações, como telas de apresentação, pesquisa, detalhamento, e assim por diante.

Há também os verbos POST, PUT e DELETE e mais alguns, mas deixarei a explicação desses para outro texto. Navegadores de Internet implementam apenas GET e POST, mas isso está mudando porque, por muito tempo, foram os únicos verbos necessários dentro do protocolo HTTP. POST é um verbo que recebe informações de um formulário e há manipulação de dados em sistema. Diferentemente de GET, é um verbo que exige uma cadência de eventos para ser aceito, como ter um formulário estruturado preenchido e enviado através de um comando específico, possibilitando ao navegador de Internet (ou cliente) algum saneamento de informações antes do envio. POST é usado para incluir, atualizar e, dependendo, excluir informações de um sistema. Por isso, pode ser considerada uma má prática usar GET para manipulação de dados em sistema.

Atualmente, POST está perdendo, pouco a pouco, as funções de atualização e exclusão, em favor de PUT para atualização e DELETE para exclusão.

Ou seja

Aqui acho que fica claro porque manter Sessions é uma má ideia. Pode surgir a pergunta sobre como um usuário é autenticado em um sistema ASP.NET MVC, mas isso também é assunto para outro texto, ou para o curso.

O que muda do Delphi

Bom, a função visual que o Delphi tinha é feita hoje em dia por JavaScript, a linguagem que manipula o comportamento dos clientes, como aplicativos de celular e navegadores de Internet. Por sorte, muitos frameworks hoje em dia implementam suporte a eventos de tela de forma semelhante, mas, basicamente, toda construção de tela envolve a linguagem de marcação HTML e JavaScript.

Voltando ao que eu falei na primeira parte, o que o ASP.NET Web Forms faz é basicamente gerar esse HTML e JavaScript para o programador, mas isso deixou de compensar à medida que novos componentes são desenvolvidos e os desenvolvedores precisam ter controle total sobre o comportamento da tela do dispositivo. "Componentizar" foi prático num primeiro momento, mas com o advento de frameworks mais poderosos em JavaScript, bem como uma maturação forçosa da linguagem, a prática perdeu força.

Além disso, não há mais a dependência a um ambiente. As telas dos dispositivos suportam vários tamanhos, lançando à comunidade o conceito de responsividade, ou seja, um sistema que se adequa à tela do dispositivo sem perder qualidade visual. Há diversos tipos de interface. Teclados, mouses, canetas stylus, ou as boas e velhas pontas dos dedos sobre a tela. A transferência de estado entre telas cai em desuso aos poucos, em favor dos eventos assíncronos que atualizam porções parciais da tela em uso.

Em resumo, o que deve ser entendido pelos programadores Delphi na hora de lidar com o ASP.NET MVC?

1. Acessos ao sistema podem ser feitos a qualquer momento, de qualquer lugar para qualquer ponto de informação;
2. O retorno de informações ao cliente pode ser HTML, JSON, XML, YAML, imagens, vídeos, entre outros;
3. Caixas de texto, Drop Downs, grupos Radio, grupos de Checklist, áreas de texto e outros componentes de entrada são feitos por formulários. Grids são feitas usando tabelas e JavaScript;
4. Ao contrário de sistemas Delphi, em que cada sistema está o tempo todo conectado a um servidor, uma aplicação Web raramente está conectada o tempo todo ao servidor. A exceção são para requisições de protocolos Web Socket;
5. A autenticação e controle de usuários pode ser feita a qualquer momento, em qualquer ponto de informações.

O restante mencionarei nos futuros cursos que estou escrevendo para orientar programadores interessados em aprender mais em .NET vindos do Delphi. Entre em contato para mais informações.