Recentemente conheci um framework chamado Butler.
Achei muito interessante a ideia…
Procurei na internet referências e opiniões sobre o conceito nele usado de Table Oriented Programming, ou seja, orientar uma aplicação de banco de dados (considere qualquer aplicação que persista dados) ao database-metadata.
Isso traz enormes benefícios porque integra a interface-regra de negocios-dados sem criar uma dependencia entre as camadas.
Porque com que temos aí no mercado você não possui integração direta.
Ex:
Você cria uma classe Funcionario e persiste via hibernate.
Cria a view em JSP e controla a navegação e a distribuição das informações com Struts.
Você coloca o campo código da classe funcionário em várias JSPs.
Um belo dia você muda o tamanho do campo código de 5 para 7 posições.
O que acontece?
Replace em tudo…
Isto é apenas um simples exemplo de tamanho de campo.
É lógico que existem vários generators da vida, mas isso não conta.
Gostaria da opinião de vocês…
Cometário de um preguiçoso que só passou os olhos no artigo e no tutorial.
Belo framework para quem quer programar para o SGBD. Eu acredito que sistemas são muito mais que
lê-do-banco-joga-na-tela-le-da-tela-joga-no-banco
, e este tipo de framework me parece divulgar exatamente isso.
Cadastro simples? PHP, perl, etc. Uma linguagem de script com acesso ao banco de dados é muito mais produtivo.
O banco de dados não deve ser a chave do seu sistema (nem mesmo em sistemas procedurais). Ok, os dados o são (na maioria das vezes em sistemas de empresas), mas não o SGBD. Persistir dados é vencer uma limitação do computador (espaço em memória principal pequeno e reboots), os mecanismos lindos e maravilhosos de indexação e tratamento de dados num SGBD servem apra isso, não para criar um sistema de informação ali dentro (ok, fabricantes de SGBD gostam e apoiam isso).
Um sistema pode ser feito apenas usando recursos de um SGBD assim como eu posso dizer para você que um cadastro simples eu faço no Access ou em VBA no Excel. É a mesma coisa numa escala maior.
[]s
Pelo que me parece o projeto vai mais álém disso, do que simples telas de cadastro.
Pelo que eu entendi ele integra inerface-negocio-dados sem criar dependencia.
As telas refletem mudanças no modelo.
Mas não precisam ser telas simplórias.
Possue componentes data-aware para swing e jsp tags para web (você pode continuar usar outro framework MVC).
A unicas coisas que me parecem contra:
- Você não aproveita os recursos type-safe do java que a persistencia de objetos tem, pois você tem referência a campos e tabelas (que me parece que não precisam ser as tabelas do banco e sim uma ponte para elas)
- mesmo que se tenha uma independencia do banco, a unica forma de dependencia seria os bancos de dados relacionais.
Mas qual outra forma de persistencia efetiva existe hoje em dia ?
Será que vale a pena abrir mão da produtividade por simples puritanismo ?
Ahhhhhhhhh…o velho conceito relativo da produtividade.
Notícia triste: Java não foi feito para ser produtivo, se o que você chama de produtividade é atropelar toda e qualquer regra de manutenção de um sistema e boas práticas.
Notícia boa: Você encotnra este tipo de produtividade em ASP, PHP, VB e (quando mal usado) Delphi. Todos se integram com bancos de dados pereitamente e você pdoe trabalhar com quantas camadas quiser.
A única razão para alguém produzir uma aplicação data-driven deste jeito (além de um protótipo) é uma aplicação tão simples e/ou tão descartável que simplesmente não vale a pena fazer o treco do melhor jeito.
É claro que “a equipe pode não dominar a tecnologia de objetos”. Se não se mexer, não dominará nada mais que o que sabem hoje nunca.
Persistência efetiva? Um bom SGBD com um mapeamento descente quebra qualquer galho em 99% das aplicações. XML, Prevalência, serialização…tantas outras possibilidades…