Retornar ResultSet na classe abstrata.

Sugiro fortemente que você veja a implementação disso aí no Spring. Você vai se surpreender.

xdraculax wrote:Sim é POG? Explique porque ou isso é um "EU acho que é POG"?
Não é POG, é divergência de opnião. E você não tem uma justificativa plausível, portanto, sem comentários.
Pra mim, repetir a mesma estrutura de código por n métodos de classes de persistência é que é POG. E foi o que você disse que faria.

Quanto a segurança, eu até entendo isso; mas quem vai escrever os SQL são programadores, e não "paes & mães".
O sistema não tem entradas inseridas por usuários, tudo é gerado por um Hardware. Então esse conceito de segurança, neste contexto, não faz sentido.
Se o programador é burro pra escrever um SQL desastroso, ele vai fazer isso em qualquer outra situação.

Você simplesmente leu que deve-se usar PS em todas as situações e acreditou. Nem se ocupou em fazer testes para ver se realmente faz sentido utilizá-lo em todas as situações.

minha humilde opnião? sim, é pog. Tanto é pog, que está gerando um problema pra vc, que não existiria se estivesse sendo utilizado corretamente.

conexões, statments, e resultsets são recursos de IO. vc abre, vc fecha. vc só tem que determinar em que ponto vc vai fazer isso, e essa regra tem que valer pra todo o sistema. não tem como fugir dessa estrutura quando se está trabalhando com jdbc:

o código pra fechar os recursos é um porre? é mesmo. mas basta criar métodos pra fechar esses recursos, como existe no DBUtils da apache.(close e closeQuietly, ver aqui).

o PreparedStatment não é só amis seguro, evitando sqlinjection,ele tbm é mais rápido, se vc for rodar aquiele comando mais de uma vez. e ainda reduz os problemas de ficar montando o sql com concatenações de strings, tipo problemas de aspas por exemplo.

This message was edited 1 time. Last update was at 19/02/2010 14:37:13

Quem acha que não tem como fugir dessa estrutura, veja o Spring.
E realmente é pog manter essa estrutura em todo lugar, eu concordo com o xdraculax. Embora ele realmente devesse usar o PreparedStatement, é realmente louvável a preocupação em não repetir código. Repetição de código é uma idiotice, um dos grandes males a serem evitados.

Java Ninja Membro desde: 12/01/2009 16:12:54 Mensagens: 286 Offline

Já vi o DBUtils da apche.
Mas como já tinhamos feito os métodos para liberar conexão, statements .... Não usei o DBUtils.

O que você falou é verdade, recursos IO devem ser abertos, utilizados e liberados; o que impede que isso seja feito na classe abstrata?
Só serve se for no método que você está vendo na sub-classe?

Repetir código é matar a Orientação a Objetos, piora manutenção, principalmente quando se usa os try... cath como "muleta de desenvolvimento".

Infelizmente não dá certo porque o modelo de leitura do ResultSet é conectado. Mas isso já resolvi usando outra implementação da interface.

Como eu disse, a segurança do PS nesse caso não é relevante pois o sistema não tem entradas de dados inseridas por usuários. Todos os dados são gerados por hardware.

O desempenho, bem, todo livro e documentação diz que é melhor, mas no frigir dos ovos, não vejo isso.

Não costumo acreditar nos rótulos, prefiro testar é ver se realmente é a "Coca-Cola toda".

Mas tudo bem, se todo mundo acha que é gambiarra, fazer o que.
Eu vou continuar fazendo assim, pois acredito que não é POG. Mesmo assim, obrigado.

ViniGodoy wrote:Quem acha que não tem como fugir dessa estrutura, veja o Spring.
E realmente é pog manter essa estrutura em todo lugar, eu concordo com o xdraculax. Embora ele realmente devesse usar o PreparedStatement, é realmente louvável a preocupação em não repetir código. Repetição de código é uma idiotice, um dos grandes males a serem evitados.

Sinceramente eu não vi, não posso falar. Vc ta se referindo ao código que controla o JdbcTemplate?

não gosto de repetir código tbm, mas neste caso em especifico eu não conheço outra alternativa. Espero mudar conhecendo essa abordagem do spring.

Java Ninja Membro desde: 12/01/2009 16:12:54 Mensagens: 286 Offline

ViniGodoy wrote:Embora ele realmente devesse usar o PreparedStatement

Pois é, vou acabar usando pela "limpesa" no código; e também pelo fato de que concatenar String´s no Java é um problema de criação de novos objetos desperdíçando memória.

Repetição de código é uma idiotice,

Pois é

, isso é realmente um problema.

lógico que retornar object é ruim, mas é apenas uma idéia. assim vc não precisa ficar repetindo o código.

Java Ninja Membro desde: 12/01/2009 16:12:54 Mensagens: 286 Offline

Sim concordo que retornar object não é muito legal.

Mas o seu método resultSetToModel pode ser abstrato ou genérico, assim a sub-classe retornaria a lista de entidades no qual ela representa.
Mas essa não é a questão.

Como já tinham falado anteriormente, essa é uma boa idéia, e estou pensando se é possível colocá-la no código.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:Quem acha que não tem como fugir dessa estrutura, veja o Spring.
E realmente é pog manter essa estrutura em todo lugar, eu concordo com o xdraculax. Embora ele realmente devesse usar o PreparedStatement, é realmente louvável a preocupação em não repetir código. Repetição de código é uma idiotice, um dos grandes males a serem evitados.

Humm... tlv não estejamos falando do mesmo Spring. O que o Spring faz é exactamente o que o mario.fts falou. Esse padrão de tratamento é universal e a razão da sua existência é uma coisa chamada ACID

O codigo fonte está aqui

E o codigo é este:

public Object   execute(StatementCallback action) throws DataAccessException {
         Assert.notNull(action, "Callback object must not be null");

Connection   con = DataSourceUtils.getConnection(getDataSource());
         Statement   stmt = null;
         try {
             Connection   conToUse = con;
             if (this.nativeJdbcExtractor != null &&
                     this.nativeJdbcExtractor.isNativeConnectionNecessaryForNativeStatements()) {
                 conToUse = this.nativeJdbcExtractor.getNativeConnection(con);
             }
             stmt = conToUse.createStatement();
             applyStatementSettings(stmt);
             Statement   stmtToUse = stmt;
            if (this.nativeJdbcExtractor != null) {
                 stmtToUse = this.nativeJdbcExtractor.getNativeStatement(stmt);
             }
             Object   result = action.doInStatement(stmtToUse);
             handleWarnings(stmt.getWarnings());
             return result;
         }
         catch (SQLException   ex) {
             // Release Connection early, to avoid potential connection pool deadlock
 // in the case when the exception translator hasn't been initialized yet.
 JdbcUtils.closeStatement(stmt);
             stmt = null;
             DataSourceUtils.releaseConnection(con, getDataSource());
             con = null;
             throw getExceptionTranslator().translate("StatementCallback", getSql(action), ex);
         }
         finally {
             JdbcUtils.closeStatement(stmt);
            DataSourceUtils.releaseConnection(con, getDataSource());
        }
     }

O reaproveitamento e a abstração é conseguida pelo uso de classes utilitárias, callbacks e proxys. Tudo com exceções devidamente tratadas.
É tecnologia que permite que em apenas um método e com a estrutura clássica, muita coisas possa ser feita.

Já agora é interessante dar uma olhada no método query.

O ponto não é que não devemos consolidar tudo num método. O ponto é que existem formas certas e formas erradas de consolidar as coisas num método.
Para quem não gosta de pensar em certo e errado: existem formas acopladas e formas desacopladas de consolidar e abstrair.

This message was edited 2 times. Last update was at 19/02/2010 22:16:04

Então Sérgio. Esse código é exatamente o que o xdraculax estava propondo no início, embora o design dele ainda esteja muito atrás do design do spring, por desconhecimento do JDBC (como vc mesmo citou).

E o método faz exatamente o que você disse para ele não fazer, concentra todo tratamento num lugar só, evitando toda a repetição enfadonha que o JDBC impõe. Talvez você tenha se expressado mal, mas eu entendi que você falou que isso era POG, e que ele deveria reproduzir todo esse código de tratamento várias vezes. E foi isso que deixou o xdraculax de cabelo em pé.

Para um método ainda mais parecido com o que ele fez, veja a implementação do queryForRowSet.

Ok, como contra argumento você vai dizer que o Spring usa as abstrações certas. Entretanto, não dá para negar que o colega estava no caminho certo, e que essa abstração iria surgir cedo ou tarde, a medida que ele necessitasse de recursos mais avançados, como transações. Tanto que, ele mesmo já estava no caminho de copiar as respostas para um novo objeto, como o próprio Spring faz.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ViniGodoy wrote:Então Sérgio. Esse código é exatamente o que o xdraculax estava propondo no início, embora o design dele ainda esteja muito atrás do design do spring, por desconhecimento do JDBC (como vc mesmo citou).

E o método faz exatamente o que você disse para ele não fazer, concentra todo tratamento num lugar só, evitando toda a repetição enfadonha que o JDBC impõe. Talvez você tenha se expressado mal, mas eu entendi que você falou que isso era POG, e que ele deveria reproduzir todo esse código de tratamento várias vezes. E foi isso que deixou o xdraculax de cabelo em pé.

Para um método ainda mais parecido com o que ele fez, veja a implementação do queryForRowSet.

Ok, como contra argumento você vai dizer que o Spring usa as abstrações certas. Entretanto, não dá para negar que o colega estava no caminho certo, e que essa abstração iria surgir cedo ou tarde, a medida que ele necessitasse de recursos mais avançados, como transações. Tanto que, ele mesmo já estava no caminho de copiar as respostas para um novo objeto, como o próprio Spring faz.

O que eu disse foi

eu mesmo wrote:
só existe um problema com esse método : é POG.

"esse método" se refere ao método que foi apresentado. Eu não disse "esse conceito" , nem "essa ideia" , nem "qualquer tipo de método que encapsule o tratamento de statements"
Acho que a diferença é obvia e ha uma mal intrepretação vossa.

A minha objeção principal é colocar o método numa classe abstrata em vez de numa classe especializada. Essa é a principal POG aqui, por achar que colocando em classes abstrata e herdando dela estaria reaproveitando codigo. Não. Reaproveitamento acontece criando classes especificas e chamando-as. Que é o que o Spring faz, o Hibernate e o MiddleHeaven

Repare que o JDBCTemplate é usado por outras classes para executar sql, ele não é herdado.

Tb não referi nada em relação "ao caminho certo" em que ele estaria. Apenas no caminho errado que ele precorreu: o conceito de usar métodos em classes abstratas para reaproveitar codigo.

Java Ninja Membro desde: 12/01/2009 16:12:54 Mensagens: 286 Offline

Colocar o método na classe abstrata e chamá-lo nas especializações é exatamente o que eu faço, não há absolutamente nada de errado nisso. É exatamente o que o Spring faz pelo que estou vendo, e isso não é nenhuma novidade.

Quanto ao tratamento de exceções, não tem nada a ver o que o sergio falou. A questão abordada aqui não era o tratamento de exceções, e sim o problema com o ResultSet.
Sabe aqueles exemplos de livros que querem mostrar a declaração de uma variável e colocam 400 linhas de código para tal? Pois é... não era essa minha intenção; meu foco era o problema de chamada do método e liberação dos recursos IO.

Gostei do códgo do Spring. Lógico, meu código está pobre ainda, comecei a implantar esse conceito agora, por ver o problema de repetição de código, ainda tenho que amadurecê-lo muito.

Infelizmente ainda não consigo desenhar um sistema e codificá-lo de uma vez e nunca ter que melhorar uma linha de código.

o conceito ERRADO de usar métodos em classes abstratas para reaproveitar codigo.

Bem, uso classes abstratas para o que elas foram feitas: representar abstrações. Abstrações reutilizáveis entre as implementações, por consequência: reuso de código.

E sim, o sergio disse que reutilizar a mesma estrutura de códgo na classe abstrata era POG (primeira página, msg 14).

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

xdraculax wrote:Colocar o método na classe abstrata e chamá-lo nas especializações é exatamente o que eu faço, não há absolutamente nada de errado nisso. É exatamente o que o Spring faz pelo que estou vendo, e isso não é nenhuma novidade.

Não. Veja com mais atenção. O método do spring é publico e a classe não é abstrata nem é feita para ser herdada.

o conceito ERRADO de usar métodos em classes abstratas para reaproveitar codigo.

Bem, uso classes abstratas para o que elas foram feitas: representar abstrações. Abstrações reutilizáveis entre as implementações, por consequência: reuso de código.

É exactamente esse conceito que estou dizendo que está errado. Vc está equivocadamente associando "abstração" com "classe abstrata". Não é assim que OO funciona.
Uma "abstração" é a identificação de um conceito ou mecanismo que pode ser tratado como uma unidade em si mesmo. Por exemplo, Cliente é uma abstração. usuário é uma abstração. Contudo, as classes que os representam não são abstratas.

Reuso de codigo não é conseguido via herança. É isso que estou lhe dizendo. Vc usa herança para categorizar (organizar) as ideias, não para reaproveitar codigo.

E sim, o sergio disse que reutilizar a mesma estrutura de códgo na classe abstrata era POG (primeira página, msg 14).

A palavra chave ai é "na classe abstrata". Esse é o problema.

Basicamente vc quer fazer um esquema tipo template method. mas vc não precisa disso e isso não é flexivel. é muito mais simples vc criar uma classe especializada em executar pesquisas JDBC ( como o Spring faz) e depois injetar essa classe nas classes que precisam desse serviço.

É uma questão do design OO e o uso indevido de herança para reaproveitar codigo.

Java Ninja Membro desde: 12/01/2009 16:12:54 Mensagens: 286 Offline

Entendi.

Realmente abstração (AbstractPersistence) não é usada em nenhum lugar realmente como uma abstração.
Ou seja, ninguém declara um tipo AbstractPersistence e usa-o sem sabe qual sua implementação.

Mas qual a principal vantagem de não herdar e usar uma classe "utilitária"?

Obs: (Injetar a classe utilitária nas classes de persistência realmente seria uma ótima decisão, mas não usamos Spring, pelas restrições que citei no inicio do post).

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

xdraculax wrote:Entendi.

Realmente abstração (AbstractPersistence) não é usada em nenhum lugar realmente como uma abstração.
Ou seja, ninguém declara um tipo AbstractPersistence e usa-o sem sabe qual sua implementação.

Mas qual a principal vantagem de não herdar e usar uma classe "utilitária"?

Várias vantagens mas a principal vantagem é desacoplamento.

Primeiro vc não vai usar o recurso de herança. Isso significa que vc pode herdar de outra coisa qq.
O recurso de herança é bala unica. se a usar uma vez, ja´era , portanto tem que se manter afastado de a usar o mais possivel.

Depois, herança tem a ver com categorias. Colocar um cara herdado AbstractPersistance não o categoriza realmente, mas do ponto de vista do java
sim. Faz sentido se vc tem algo como AbstractPersistance e depois herdando dele algo como XMLPErsistance, DBPersistance, CachePersistance. Vc está definindo um categoria de formas de persistencia. Mas fazer ProdutoPersistance, ClientePersistance, etc... não está categorizando nada, e pior, vc não consegue injetar mecanismos diferentes para a persistencia de produto, cliente, etc...

Obs: (Injetar a classe utilitária nas classes de persistência realmente seria uma ótima decisão, mas não usamos Spring, pelas restrições que citei no inicio do post).

A injeção é um principio que não depende de ferramentas ou containers. Passe o objeto no construtor do outro e pronto.

Notícias, artigos e o maior fórum brasileiro sobre Java