2017-09-20 4 views
0

Je crée une classe DAO qui utilise JDBC et MySQL. Je n'ai reçu aucune indication sur la façon de fermer les éléments énumérés dans le titre, mais j'ai lu que c'est une bonne pratique de le faire. Maintenant, je pensais que cela devrait être fait dans chaque méthode CRUD, mais la gestion des exceptions semble un peu artificielle et je suis indécis sur la façon de l'implémenter.Lequel de ces deux est le meilleur moyen de gérer les tentatives d'arrêt pour la fermeture de ResultSet, PreparedStatement et Connection dans une classe DAO qui utilise JDBC?

Premier exemple:

public boolean update2(Dto dto) { 
    assert dto != null; 
    if (readById(dto.getId()).getId() == 0) { 
     throw new RuntimeException("Row with this id doesn't exist"); 
    } 
    boolean flag = false; 
    try { 
     Connection connection = DAOFactory.createConnection(); 
     String sql = "SQL statement"; 
     try { 
      PreparedStatement ps = connection.prepareStatement(sql); 
      try { 
       // Some stuff with preparedstatement 
       ps.executeUpdate(); 
       flag = true; 
      } finally { 
       if (ps != null) ps.close(); 
      } 
     } finally { 
      if (connection != null) connection.close(); 
     } 
    } catch (ClassNotFoundException e) { 
     e.printStackTrace(); 
    } catch (SQLException e) { 
     e.printStackTrace(); 
    } 

    return flag; 
} 

Deuxième exemple:

public boolean update(Dto dto) { 
    assert dto != null; 
    if (readById(dto.getId()).getId() == 0) { 
     throw new RuntimeException("Row with this id doesn't exist"); 
    } 
    boolean flag = false; 
    PreparedStatement ps = null; 
    Connection connection = null; 
    try { 
     connection = DAOFactory.createConnection(); 
     String sql = "SQL statement"; 
     ps = connection.prepareStatement(sql); 
     // Some stuff with preparedstatement 
     ps.executeUpdate(); 
     flag = true; 
    } catch (ClassNotFoundException e) { 
     e.printStackTrace(); 
    } catch (SQLException e) { 
     e.printStackTrace(); 
    } finally { 
     if (ps != null) { 
      try { 
       ps.close(); 
      } catch (SQLException e) { 
       e.printStackTrace(); 
      } 
     } 
     if (connection != null) { 
      try { 
       connection.close(); 
      } catch (SQLException e) { 
       e.printStackTrace(); 
      } 
     } 
    } 

    return flag; 
} 

Dans le second exemple i besoin la gestion des exceptions en double. La première solution me semble plus intelligente, mais je ne suis pas sûr que ce soit plus lisible que le second.

Y a-t-il des conventions à adopter pour le design qui ne sont pas seulement subjectives?

Répondre

1

En supposant que vous utilisez Java 1.7 et supérieur, vous pouvez utiliser l'instruction try with resources pour simplifier la fermeture des ressources. A condition que les ressources à mettre en œuvre l'interface AutoClosable, ce qui est le cas pour Connection et PreparedStatement, vous pouvez réécrire votre code comme suit:

public boolean update2(String dto) { 
    assert dto != null; 

    if (readById(dto.getId()).getId() == 0) { 
     throw new RuntimeException("Row with this id doesn't exist"); 
    } 

    boolean flag = false; 
    String sql = "SQL statement"; 
    try (Connection connection = DAOFactory.createConnection(); 
     PreparedStatement ps = connection.prepareStatement(sql)) { 
     ps.executeUpdate(); 
     flag = true; 
    } catch (ClassNotFoundException e) { 
     e.printStackTrace(); 
    } catch (SQLException e) { 
     e.printStackTrace(); 
    } 

    return flag; 
} 
+0

Cette construction est beaucoup plus facile à lire et je ne le savais pas, je vous remercie beaucoup. Cependant, je n'ai pas compris si, pour les versions antérieures à 1.7, le choix revient au développeur ou s'il y a une convention à adopter. – TheItalianJobless

+0

Ensuite, utilisez la deuxième option; c'est ce que je préférerais parce que le code est un peu plus propre que le premier. – ujulu

+0

C'est une bonne réponse, mais je traiterais le 'ClassNotFoundException' et peut-être aussi' SQLException' de façon plus agressive, par exemple. les enveloppant dans une exception d'exécution, car ils sont presque toujours causés par des erreurs de déploiement/programmation (ou des problèmes avec data/DB) dont vous ne pouvez pas récupérer. –