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.

Delphi Array To Java Array

17/08/2013 at 18:32

Eis aqui enorme diferença entre as duas plataformas, pois em Java tudo é orientado a objeto nem que for através de métodos estáticos de uma classe base da API.

Array Dinâmico em Delphi

A linha 6 aloca quatro posições do tipo TMyOtherObject na memória para a variável “a” através da chamada ao método procedural setLength da unit system. A linha 7 atribui a nova instância de TMyOtherObject à posição zero do array. A linha 8 recupera aquela instância na variável “x”. A linha 9 escreve no console o conteúdo de TMyOtherObject.

 Array Dinâmico em Java

A linha 2 aloca quatro posições do tipo MyOtherObject na memória para a variável “a” através da chamada ao método estático newInstance da classe Array, é nele, no primeiro argumento que você indica o tipo do conteúdo do array e não na declaração da variável como no Delphi, e no segundo argumento o tamanho. A linha 3 atribui a nova instância de MyOtherObject à posição zero do array através da chamada ao método estático set da classe Array, cujo primeiro argumento é a variável do array, o segundo a posição, o terceiro é o objeto. A linha 4 recupera aquela instância na variável “x” através da chamada ao método estático get da classe Array, cujo primeiro argumento também é a variável do array e no segundo a posição. A linha 5 escreve no console o conteúdo de MyOtherObject.