Em dezembro de 2017 separei um notebook que não estava mais usando e tomei o caminho de instalar um linux para avaliar o quando seria possível viver sem Windows e sem uma máquina virtual (rsrs).
Como todos sabem, a principal ferramenta de trabalho que utilizo é o Delphi – então o desafio ficou imenso – já que sem uma máquina virtual e sem o windows é impossível utilizar o Delphi. Usando outro framework para substituir o Delphi não iria proporcionar emoção – então descartado frameworks na mesma linha.
Primeiro ponto, o que usar para desenvolver aplicativos ? Como bom delpheiro JAVA não estava nos meus planos, queria algo mais novo.

Primeira parada – se atualizar
Desktop, WEB, Mobile – são opções de plataforma de trabalho. Estacionei no item WEB, vamos procurar o que temos para explorar aí.
Já havia utilizado o Angular-JS a alguns anos para implementar algumas coisas, então vamos nos atualizar no que há de mais novo de Angular – Angular 5 (logo no início do ano veio o 6), tudo novo – esquece o Angular-JS – agora é Typescript.
Typescript é uma implementação feito utilizando como base o javascript – você escreve Typescript e o compilador gera código javascript para ser utilizada no Browser – nem tudo precisa iniciar do zero – legal.

No AngularIO, novas ferramentas de geração e compilação vieram no pacote:

  • o NG (a ferramento do AngularIO) agora gera compilações para serem publicadas no servidor do SITE
  • compila para teste local na máquina com um mecanismo de “Hot Load” muito eficiente – ficou muito bom
  • é muito produtivo para criação de páginas dinâmicas
  • com uso de NodeJS é possível escrever servidores para publicar serviços (ex: busca em banco de dados)

Ferramentas
Para trabalhar com AngularIO, não é preciso ter um windows rodando – Assim como no windows, no linux temos disponível o VS – Virtual Code Studio da MS que faz o trabalho com perfeição, primeira etapa concluída – já é possível seguir o trabalho diário sem Windows.

Preparação de Infra-estrutura
Primeiro passo a resolver é fazer a integração do código Typescript para consumir os serviços de REST em produção escritos em DELPHI. Para isto utilizei o ODataBr (parte do pacote MVCBr – vários artigos aqui no blog – MVCBr).

  • Criado uma camada base de comunicação com o servidor – a parte de http, autenticação, tradução de protocolo, tratamento de “Future” ou respostas assíncronas
  • Criado camada de comandos com classe que tenham regrar de tratamento do protocolo OData
  • Criado camada de classes de acesso aos serviços do servidor utilizados pela aplicação

Produtos com AngularIO

  • Criado um Dashboard para os aplicativos Delphi que estavam em fase de produção para lançamento em 2018
  • Treinamento de equipe para desenvolvimento em AngularIO
  • Implementação da plataforma NcConstruir – com portal de interação do logista com a plataforma – ver: Nc Construir
  • Implementado uma experiência de venda de produto por Mobile rodando em WebView;

Segunda parada – Google Firebase
…. próximo

Tenho visto muitos videos que falam sobre como aplicar MVC com Delphi e sempre fiquei com a impressão que não é nada fácil. O que não é fácil se torna um desafio – é assim que nasceu MVCBr – Um desafio para elevar a organização do código a outro patamar.

A filosofia nativa vendida pelo fabricando do delphi, basta ver os diversos videos disponíveis na comunidade, é que a ferramenta suporta MVVM, ou seja Model View e View Model – talvez seja este o maior entrave em implementar um MVC.

1) O desafio

Sendo a IDE altamente produtiva é preciso que um projeto MVC não retire aquilo que há de melhor, mesmo assim, encontramos muitos que condenam a condição de “arrastar e soltar” utilizada deliberadamente ao longo dos anos, formando uma legião de arrastadores de componentes para a interface e quando precisa de um pouco mais de profundidade da engenharia de software – foi esquecida.

2) Onde encaixar o Controller (“o bobo da corte”)

O papel o Controller é fazer o meio de campo entre o VIEW e MODEL, o que já chamei antes de “bobo da corte”, ou seja, é o controle que faz a ponte entre os MODELs e as VIEWs. Quando uma VIEW precisa de alguma informação, ela pregunta para o CONTROLLER quem detém este dado – em existindo entrega a VIEW o MODEL que é responsável pelo informação.

3) A View – camanda de apresentação

É a VIEW que se encarrega de fazer a apresentação ao usuário – no caso de desktop o “FORM” – toda VIEW possui um controller associado a ela. Se o aplicativo rodar em um browser, a VIEW é a página de apresentação para o usuário…

Não é responsabilidade da VIEW saber como guardar informações;

4) O Model – onde tudo acontece

É no MODEL que as regras acontecem. Persistência, cálculos, DAO, ORM…

VIEWMODEL

No MVCBr ainda temos a figura do VIEWMODEL – o ViewModel é um artefato de MVVM e não de MVC, no entanto o seu uso pode ser bastante útil para não nos afastarmos muito da filosofia da ferramenta.

O que fazer com o VIEWMODEL ?

Com o ViewModel, pode-se adotar uma estrutura híbrida e delegar ao VIEWMODEL a validação do formulário. Sendo ele ao mesmo tempo um conector direto para o VIEW com funcionalidades de um MODEL, ou seja, ele pode receber validações do FORM ou mesmo guardar alguns estados ligados ao FORM (ou particulares ao VIEW).

 

O MVCBr

No MVCBr, a relação entre CONTROLLER  e  VIEW  é de 1 para  <=1 – Um Controller possui  no máximo  uma  VIEW, em alguns casos talvez nenhuma. Assim toda vez que se cria uma VIEW é preciso construir um controller para a VIEW.

Já o CONTROLLER pode possuir ligações para múltiplos MODELs do projeto. Sendo o MODEL um artefato que possui regras de negócio, um MODEL pode conter as regras de persistência de cliente enquanto outro MODEL possui regras de transação de cartão de crédito separando cada MODEL por finalidade.

Se um MODEL implementar uma NFe, ele dever saber lidar com o acesso ao cadastro de cliente, acessar cadastro de produto …. além de fazer persistência do conjunto de regras de NFe – Muitas vezes um MODEL poderá precisar de ajuda de outro MODEL;

O Assistente do MVCBr

Desafio lançado – código complexo. Precisamos de um assistente para nos ajudar a escrever código. Foi pensando nisto que o Assistente do MVCBr esta apto a criar o projeto com estrutura de MVC, VIEW, MODEL e CONTROLLER para a nossa aplicação;

Todo o projeto tem por base trabalhar com assinaturas publicadas em INTERFACEs visando eliminar ao máximo o acoplamento, implementadas em UNITs em separado dos seus “Object Factory”. Neste contexto, sempre que uma UNIT precisa de um recurso que se encontra em outra UNIT – deverá preferencialmente trocar informações pelas INTERFACEs.

Todo “Object Factory” public o seu THIS, uma espécie de SELF para o “Factory” onde permite facilmente fazer CAST de interfaces usando   “This. AsType<interface>” – claro que o “Factory” precisa conhecer e implementar a tal interface solicitada (ou retornará NIL).

 

Veja o Vídeo:  Criando um Projeto com FireDAC

Códigos:  MVCBr