O BoxSQL, um novo framework para persistência utilizando templates SQL, fornece grande flexibilidade para projetos que utilizam banco de dados fragmentado ou mesmo para projetos onde a performance é obrigatória.
Na página do projeto pode-se encontrar um tutorial bem explicativo e mais detalhes sobre o framework, que está na versão 1.5.
Acesse http://boxsql.dev.java.net
Olá
Onde fica o link para download? Não achei na página do projeto.
[]s
Luca
Fica no link Documents & files
Aí você clica em versões e lá terá o jar do BoxSQL e o jar do Apache-DbUtils que é a unica dependencia do BoxSQL.
Tudo isso em mais ou menos 50KB.
Boa Sorte aí…
qual a diferenca desse seu framework para o suporte do novo JDBC 4 ?
Ao meu ver temos duas diferenças básicas:
O fato de o SQL ficar fora do código java, organizado em arquivos de templates que podem ser armazenados em pacotes, por temas relacionados por exemplo.
Outro fator interessante é que seus beans não terão nenhum acoplamento em relação ao banco de dados, mas não perderão o mapeamento automático que é feito por meio de reflection dentro do codigo do BoxSQL.
Você pode mandar inserir um objeto de qualquer classe, desde que os nomes dos atributos sejam iguais aos parâmetros do seu template de sql.
Isso é um mapeamento (quase) automático, pois você só precisará prestar atenção na convenção para JavaBeans e nos nomes do parâmetros.
Padronização no lugar de configuração.
QQ dúvida posta aí…
mas com o exemplo do JDBC que eu descrevi o beans tmb nao tem nenhuma relacao com o banco de dados… a carga deles / persistencia fica com encargo da interface que define isso com uma anotação…
Sei lá… nao consigo achar que anotações é um “vilão malvado” que vai misturar tudo… é apenas metadata…
Felipe, ao meu ver ele é um concorrente do Ibatis, certo ?
http://www-128.ibm.com/developerworks/websphere/techjournal/0510_col_barcia/0510_col_barcia.html
Qual seria a diferença do BoxSQL para o Ibatis ?
[]s
Douglas
Concordo com você sobre as anotações.
Inclusive existem plano para mapeamento recursivo usando annotations.
Porém os nomes dos campos da tabela, as próprias tabelas e seu banco de dados.
Acho que essa é a vantagem maior e não o fato de usar anotações ou não.
Outra facilidade é a organização dos templates SQL. Isso facilita a migração de um banco de dados para outro, ou até mesmo de um refactoring de banco de dados, sem precisar recompilar a aplicação.
[quote=douglasfs]Felipe, ao meu ver ele é um concorrente do Ibatis, certo ?
http://www-128.ibm.com/developerworks/websphere/techjournal/0510_col_barcia/0510_col_barcia.html
Qual seria a diferença do BoxSQL para o Ibatis ?
[]s
Douglas[/quote]
É sim douglas, porém sem a complicação do XML. O Código SQL fica bem mais limpo e flexível.
Acho que JPA é tão simples… fazer os exemplos que são decritos com o iBatis e com o boxSQL é simplesmente piada… vc define um XML com 3 linhas… um @Entity e pronto… tudo funciona…
Nao consigo entender pra que usar frameworks deste genero…
Tenta relacionar 4 tables, chamar funções específicas de um banco de dados, ou subconsultas utilizando o mapeamento da JPA…
Aí você já percebe a diferença do objetivo entre um e outro. Há também a qestão da performance do JPA não ser tão boa quanto a performance do BoxSQL, por se tratar de código JDBC encapsulado com reflection.
Imagine um sistema que acessa bancos de dados já prontos e esses banco de dados são tão fragmentados que é inviável criar uma classe para cada tabela. Com o JPA não seria tão fácil de fazer isso, isso se é que daria pra fazer isso. Mas mesmo conseguindo a produtividade não seria a mesma.
Além disso, são alguns MB (Implementaçoes da JPA) contra ± 50KB (jar do BoxSQL já com o fonte para facilitar o debug.)
Não digo que o BoxSQL é melhor que a JPA, mas digo que é diferente. Atende casos que a JPA não atende. É questão de analisar o sistema e ver qual das opções se encaixa melhor.
É claro que o BoxSQL ainda tem muito o que melhorar. Já temos várias sugestões e alguns issues pra resolver, mas acho que estamos num caminho bom.
JPA(obviamente o hibernate) tambem faz chamadas SQL nativas 
Mas legal sua colocação quanto aos sistemas legados… porem gostaria que os exemplos dados fossem tambem mais realistas… que realmente mostre para que o “boxSQL” veio… e nao o tradicional CRUD.
Com SQL dentro do código e seu sistema altamente acoplado à um Banco de dados.
Agora imagine um sistema em que 90% das tabelas são esse caso.
Pra que usar JPA se voce vai ter que digitar código Nativo em 90% dos casos?
Eu falo isso porque vivi uma situação dessas num projeto recente.
Quanto aos exemplos, realmente os tutoriais que estão no site são básicos do tipo CRUD, porém isso é bomo para o publico menos experiente entender o funcionamento e também serve para o publico mais experiente.
Atualmente somos em 2 desenvolvedores realmente ativos, e isso nos impede de melhorar a documentação.
Há também a necessidade de mais testCases para situações diversificadas, o que fará surgir novas idéias e mais robustez.
Enquanto não der tempo de construir um exemplo mais complexo e melhor, os desenvolvedores terão de usar o BoxSQL para ver a real flexibilidade do produto.
PS.: Também estamos abertos a contribuições em relação a documentação.
Vamos fazer mais um projeto brazuca alcançãr o mundo. 
eu poderia usar nammedquerys e quardar essas querys nativas dentro de anotações em uma unica classe
agora… prq usar JPA ? prq JPA faz isso e MUITO MAIS…
pra que aprender 30 mil frameworks diferentes ?
Já disse… acho muito legal esse tipo de proposta… mas esses novos “falicitadores” devem estar mais alinhados com o que existe de novo no mercado… senao cai na premissa “mais do mesmo”
Dê um exemplo de como alinhar esse framework com o que há de novo (subentende-se JPA).
Dessa forma talvez consigamos melhorar o BoxSQL.
Esquecer esses .sql seria uma ótima… usando anotações…
Acho que talvez colocar as duas opções seria uma saida para esse caso. Só não vejo nenhuma vantagem em se usar anotações para armazenar SQL.
Se for pra criar uma classe só para conter templates, poderíamos usar constantes ao invés de anotations.
Além disso se um sistema tiver muitas queries que devam ser utilizada como nesse caso (300 por exemplo), quantas classes de templates criaríamos?
E a organização do código SQL?
Ah, e a concatenação do SQL (caso ele seja muito grande)?
E as famosa confusão das aspas que são motivos de muitos bugs em sistemas que utilizam SQL no código java?
Tudo isso pra que? Pra usar annotations e ficar na moda?
Sou a favor das annotations sim, como já falei, mas para casos onde elas são necessárias.
PS.: Alguma opinião diferente da nossa? Só pra enriquecer a discussão?
Olá a todos,
Só para lembrar, uma das futuras versões do BoxSQL, vai ser exatamente o recurso de anotações para gerar automaticamente os códigos SQL mais simples e diminuir a necessidade dos arquivos SQL.
Porém, digamos que o BoxSQL, reúne o melhor de 2 mundos, pois ele nasceu em um ambiente de aplicação, onde havia milhares de registros, várias tabelas, e um forte requisito de performance, por isso, era importante ter a possibilidade de usar querys otimizadas apartir de planos de execução (coisa de DBA’s), e como não queria deixar o SQL no próprio código Java, criei esse framework com o objetivo de ser simples, de fácil configuração, leve, que valoriza-se o uso de bons códigos SQL e favorece-se a criação de códigos java simples com forte adoção de padrões e boas práticas de programação.
E desde então, o BoxSQL vem evoluindo, de maneira simples, sem grandes pretensões e agradando um púplico seleto em outros projetos pelo Brasil.
Por isso, sabedores que muito temos a evoluir, aceitamos sugestões, que visem melhora-lo ainda mais.
Grato,
Manoel Pimetel
[quote=douglasfs]Felipe, ao meu ver ele é um concorrente do Ibatis, certo ?
http://www-128.ibm.com/developerworks/websphere/techjournal/0510_col_barcia/0510_col_barcia.html
Qual seria a diferença do BoxSQL para o Ibatis ?
[]s
Douglas[/quote]
Olá,
Pelo o que conheço do iBatis, uma das principais diferenças, é que ele usa arquivos XML para conter os códigos SQL e fazer os mapeamentos em cada classe.
E o BoxSQL, usa o conceito de “convenção ao invéis de configuração” , por isso, temos apenas um arquivo .properties para centralizar as configurações de acesso ao banco(JDBC ou JNDI). e os arquivos SQL que seão usados pela aplicação.
Grato,
Manoel Pimentel
manoelpimente.blogspot.com
Olá
Meu pitaco sobre a questão porque fazer isto se já existe aquilo.
Quando surgiu o hibernate o iBatis já existia (ou vice versa) e o JDO também. Quando surgiu sei lá o que outro sei lá o que já existia.
Depois de recentemente ler o livro The Miths of Innovation, aprendi que é melhor não encarar muito negativamente coisas novas.
Se vai pegar, se é melhor do que o que já existe e se promete ter a mesma evolução do que o que já existe é uma outra história. Antes de detonar, o momento ainda é de tentar entender para que serve e quais vantagens deste tal de BoxSQL que eu por exemplo ainda não percebi claramente.
[]s
Luca