Alexsander Rosa wrote: > Disclaimer: Eu sei que muita gente odeia mapeamentos e geradores de > código. :-) > > Normalmente se fala em Mapeamento Objeto-Relacional, que a grosso modo > consiste em pegar um modelo O-O (modelado talvez em UML) e gerar um > modelo E-R. A modelagem é feita pensando em objetos e quem modela a > camada de persistência que se vire depois pra encaixar tudo numa DDL. > > A idéia é fazer o caminho inverso: fazer o modelo de dados PRIMEIRO e > depois gerar um conjunto de classes. Cada tabela vira uma classe, cada > tupla vira uma instância, cada coluna vira uma propriedade. O objetivo > é facilitar a vida do programador para algumas tarefas simples e > repetitivas: carregar um objeto por sua(s) PK e depois atualizar ou > deletar este objeto, por exemplo. Os SELECT mais complexos continuam > sendo feitos em SQL, as VIEWs continuam sendo usadas normalmente. Não > seria uma O-O de verdade, mas apenas um wrapper para simplificar as > tarefas. > > O grande problema das camadas de persistência é que nunca se sabe a > qualidade do SQL gerado e é relativamente fácil para o programador > usar alguma classe de forma a gerar SQL ruim (ou mesmo péssimo). No > entanto, a maioria dos SQL usados pelas telas de cadastro em uma > aplicação comercial são simples. Nesses casos, um "SELECT <campos> > FROM cliente WHERE codigo = 1234" pode ser gerado automaticamente de > maneira eficiente. Da mesma forma, um "UPDATE cliente SET nome = > 'Zeca' WHERE codigo = 1234" ou um "DELETE FROM cliente WHERE codigo = > 1234" podem ser gerados automaticamente sem problemas. > > Escrevi em 2003 uma OPF e um Gerador de Código que faz exatamente isso > para Delphi e FPC. Até agora, as vantagens têm superado as > desvantagens com folga... :-) O programador não perde tempo com os SQL > triviais (que acabam sendo em grande volume), podendo dedicar mais > atenção aos códigos SQL e PL/pgSQL realmente importantes, mais > diretamente relacionados com as regras do negócio. > Também escrevi algo assim, para Delphi + JBoss. A nossa aplicação não tem código nenhum SQL. Tudo (quando digo tudo, é tudo mesmo) é gerado automaticamente. Para fazer a carga o usuário passa o ClientDataSet destino, tabela, campos e condição (entre outros que não vem ao caso) Para comitar, o usuário passa apenas o ClientDataSet que contém os dados e tabela destino. Automaticamente é feito uma varredura no cds, gerado um XML que vai para o JBoss, ao chegar, ele trata o XML e monta o IUD. Funciona muito bem a mais de 4 anos, tivemos alguns problemas com lentidão de XML que já foram resolvidos. Temos total controle sobre o SQL gerado, pois a geração é feito por código nosso, não usamos hybernate e derivados. Assim temos garantia de um bom SQL. Para facilitar temos um DMD que indica quais são os campos chaves, quais são as fks e dessa forma auxilia a criação das rotinas IUD.
Uma das vantagens é ter apenas um tipo de código (pascal) na aplicação cliente e a despreocupação com relação a acesso a banco. Hoje, se temos que adicionar um campo novo em um cadastro, apenas adicionamos no form e mais nada! O resto é tudo automático. A maior vantagens de todas é o fato do independência do Banco de Dados que a aplicação tem. Hoje, todos os nossos clientes utilizam PostgreSQL (graças a Deus =D ), mas caso algum venha a utilizar outros bancos, temos que mexer apenas na aplicação que está no JBoss, não na aplicação cliente, o q facilita muito. Não sei se fugi do assunto, mas é isso q utilizamos hj. Att Evandro _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
