Java 9 ao Socorro do Delphi – REPL

28/06/2017 at 00:07

Introdução

Para quem ainda não sabe as novidades do Java 9, aqui vai uma delas e embora ele ainda não tenha sido lançado, já é possível testá-lo.

Se você alterna muito entre linguagens e plataformas deve se deparar sempre com o dilema de algumas regras cruciais quando demora muito para voltar, ou se você é iniciante.

Read-Eval-Print-Loop (REPL)

Esse mecanismo é muito parecido com o que utilizamos ao acessar banco de dados pelos seus utilitários nativos que funcionam em modo texto, tais como:

  • Firebird: isql-fb;
  • PostgreSQL: psql;
  • MySQL: mysql;

Em que você entra, conecta e executa comandos e recebe a resposta no próprio prompt.

JShell

Então é disso que se trata o utilitário de linha de comando jshell que esta na pasta bin do Java 9, para acessar basta executá-lo no prompt do seu sistema operacional.

Com ele é possível tirar dúvidas básicas que do contrário você teria que compilar e instalar sua aplicação só para testar e depois utilizar algum breakpoint para ficar testando aquilo que você não tem certeza como funciona. Por exemplo, em Delphi o comando copy de uma string não é zero based, mas listas e arrays são, procurar na internet nem sempre é tão rápido, ou as operações XOR, MOD, DIV, etc, como é que seria o resultado disso mesmo? Sei lá é tarde da noite você está cansado, não precisa ficar lendo várias páginas do Stackoverflow, basta abrir o jshell e começar a fazer os testes. Segue o exemplo abaixo.

higor@home:~> cd Java/jdk-9/bin
higor@home:~/Java/jdk-9/bin> ./jshell 
|  Welcome to JShell -- Version 9
|  For an introduction type: /help intro

jshell> String requestURI = "/ci/entidade/dash.xhtml";
requestURI ==> "/ci/entidade/dash.xhtml"

jshell> String[] uri = requestURI.split("/");
uri ==> String[4] { "", "ci", "entidade", "dash.xhtml" }

jshell> String pagename = uri[uri.length];
|  java.lang.ArrayIndexOutOfBoundsException thrown: 4
|        at (#3:1)

jshell> String pagename = uri[uri.length-1];
pagename ==> "dash.xhtml"

jshell>

 

Personagens Java vs Personagens Delphi

15/12/2013 at 00:16

Introdução

Programadores Delphi estão acostumados a escrever regras de negócio direto no .pas do form, botões de incluir, alterar, excluir e salvar são casos recorrentes de eventos com regra de negócio. Isso faz sentido para o Delphi, pois não se considerava programação distribuída nem balanceamento de carga, disponibilidade ou escalabilidade horizontal, apenas vertical. Não era esse o objetivo dos softwares a serem desenvolvidos. O Delphi atraiu (propositalmente) no fim da década de 1980, início da década de 1990, programadores Clipper que atuavam em pequenos CPDs de indústrias, comércio e escritórios construindo aplicações monolíticas, maravilhados pela programação visual com drag/drop e SQL. Alguns programadores apostaram alto ao usarem Delphi em aplicações corporativas acreditando nas promessas da Borland/CodeGear/Embarcadero, e no contagiante RAD – Rapid Application Development, acarretando em alto débito técnico.

Bem, se você está aqui, provavelmente se deu mal como eu. Mas nem tudo está perdido, abaixo vou traçar um paralelo didático dos personagens dessas duas plataformas.

Personagens em Paralelo

Considerando apenas J2EE, ou seja, aplicações corporativas predominantemente web, e como exemplo os arquivos Uni1.dfm e Uni1.pas de um novo form Delphi:

  • O Unit1.dfm do Delphi está para a página html
    a diferença é que em Delphi escrevenos o DFM sempre com drag/drop.
  • O Unit1.pas está para o ManagedBean.
  • Os EJBs são como as classes que você implementa no DataSnap
  • A JPA está para o DataModule
    a diferença é que não se escreve SQL mas sim JPQL – Java Persistence Query Language.
  • Uma classe Java anotada com Entity é como se fosse o FieldList do DataSet do Delphi
  • Hibernate, EclipseLink, TopLink, etc., estão para o DBExpress, ADO, BDE, etc., ou seja, é o componente de acesso a banco de dados (relacional ou não)
  • TForm do Delphi não tem nada a ver com a tag form do html, prefiro dizer isso pela pouca semelhança que têm e pela grande confusão que causam quando comparados

Ciclo completo básico

O ciclo completo que a aplicação Java EE com JSF percorre no clique de um botão, p.e., é basicamente:

  • O usuário clica no botão rendezidado em html
  • O ManagedBean responde com um método público que invoca algum método do EJB
  • O EJB processa conforme as regras de negócio e realiza acesso a dados se necessário invocando a camada de acesso a dados que pode ser o Hibernate por exemplo

Importante

O mais importante é vencer o hábito e não implementar regra de negócio no ManagedBean, lugar de regra de negócio é no EJB. Pense sempre que a camada visual pode ser substituída por um WebService, ao fazer isso o ManagedBean não será utilizado, apenas os WebMethods SOAP ou Paths dos EndPoint RESTFul.

Ou seja, @ManagedBean (JSF), @WebService (SOAP) e @Path (REST), nunca devem conter regra de negócio, eles são apenas as classes de interface da sua aplicação, digo interface no sentido de fachada. Essas três classes apontam/usam os mesmos EJB que agregam as regras de negócio num único lugar.

Existirão casos em que essas três classes apenas repassam chamadas para os EJBs, tornando-as aparentemente inúteis, mas isso não é verdade, essa repetição de código é um preço barato a se pagar pela flexibilidade. Lembre-se você está construindo uma aplicação corporativa, pense sempre que ela vai crescer muito e se tornar complexa.

Outro conceito importante, para quem tem afinidade com UML, consideramos a realização do caso de uso como sendo o diagrama de sequência, pois bem, aquela primeira classe do diagrama que recebe os estímulos do ator é o ManagedBean ou o WebService. Portanto em casos de telas complexas o ManagedBean não é uma das classes mais bonitas ela pode ser caótica, o importante é construir e manter os EJBs com bom design de classes, eles são a API, o kernel da aplicação, código puro, nenhum acoplamento com camada visual, de forma que se possa realizar testes unitários inclusive.