Em 10/11/2015 21:59, "Fabrízio de Royes Mello" <fabri...@timbira.com.br> escreveu: > > On 10-11-2015 20:35, Guimarães Faria Corcete DUTRA, Leandro wrote: > > 2015-11-10 20:32 GMT-02:00 Flavio Henrique Araque Gurgel < fha...@gmail.com>: > >> > >> http://www.jooq.org/ > > > > Tem alternativa livre? > > > > Conforme consta em [1] para bancos "open source" eles tem uma > alternativa utilizando a "Apache Software License 2.0". > > Att, > > [1] http://www.jooq.org/download/ > > -- > Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ > PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento > > >
Eu gostava muito do padrão data table gateway do Zend framework 1. Criava a classe e apontava pra uma tabela no banco. Usava as abstrações pra insert, update e delete. Só! Eu não precisava escrever sql na mão pra fazer insert toda hora. E na hora do SELECT, fazia manual e colocava cada select dentro de um método, retornando sempre array de array. Era produtivo pra caramba e me dava uma flexibilidade sem igual. Mas há quem vai dizer que isso não é mapeamento objeto relacional. E até concordo, eu prefiro usar os objetos da linguagem pra abstrair os comportamentos e não as informações. Para os dados, eu prefiro trabalhar o mais próximo possível do modelo físico. Resumindo, eu tinha as classes de controller, por exemplo. Mas não tinha a classe de pessoa. Eu tinha a classe pessoaGateway que inseria, atualizava, apagava, e fazia as consultas na tabela de pessoa. Sempre retornando vetores de vetores. Como programador (de fato eu não sou dba), minha primeira preocupação é com a governança dos dados. A aplicação não vale nada, se os dados se perderem, ou não servirem para gerar informação. Por isso, na medida do possível eu fujo de orm. E um detalhe, vejo uma falácia sendo repetida diversas vezes, use orm e mude o SGBD quando quiser. Se você vai começar um projeto e não conseguir definir o SGBD, seu projeto já fracassou. Ah mas, a aplicação tem que rodar com o SGBD A e se o usuário quiser com o B. Recomendo estudar essa necessidade e analisar bem as diferenças. _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
