MYSQL] Problème avec les exceptions SQL

Version imprimable

Bonjour à tous,

Je vais d'abord situer le contexte de ma demande.

je suis dans une entreprise qui code tout dans des pages JSP(je sais c'est sale :D) j'ai appris avec l'entreprise donc au départ ça me semblais normal puis je me suis vite rendu compte que non ^^, par la suite, je me suis formé(en partie ici) et j'ai appris la POO avec JAVA et surtout le TUTO "premier site avec javaEE"

bref, le but de tout ça est de faire évoluer mon travail dans l'entreprise et de mettre en place une vrai structure, le modèle MVC. tout se passais bien à sa mise en place jusqu'au accès à notre base de donnée.

Il faut savoir que actuellement nous avons une page JSP qui gère les erreurs et qui gère la connexion sql. ensuite cette page est "include" dans toute nos page JSP. je vous montre un petit exemple d'une requette dans une de nos page JSP :
Code:

1 2 3 4 String SQLREQUETE5="SELECT libelle_produit FROM produit WHERE ref LIKE 'toto' ; java.sql.Statement stat_pdt5 = adn_connection.createStatement(); java.sql.ResultSet res_pdt5 = stat_pdt5.executeQuery(SQLREQUETE5); if(res_pdt5.first()) { //suite code}
cette forme là est très pratique je trouve, aucun besoin de gérer les erreurs/exception sql et c'est facile à lire.

cependant lorsque je veux respecter le modèle MVC, je trouve ça très lourd de devoir écrire chaque exception ainsi que l'accès à la base.

ma question est donc : comment gérer l'accès à la base de donnée en gardant cette idée d'une page qui va gérer les erreurs/execptions ?

je précise aussi que dans un premier temps j'aimerais éviter la DAO qui me semble un poil compliqué, j'ai encore du mal à voir comment gérer mon code de façon "objet".

J’espère avoir été clair, je reste disponible pour plus d'infos

27/09/2016, 17h11
OButterlin

Je ne vois pas trop le rapport entre MVC et le code que tu montres qui, si je comprends bien, est dans la page JSP...

Le modèle MVC est des plus simple :
- le M représente les données liées à la page
- le V est la page JSP qui est sensée utilisée les données de M
- le C est un contrôleur qui fait le lien entre l'utilisateur/navigateur web et les données et la page (un chef d'orchestre en quelque sorte)

On peut bien sûr rajouter des couches, une couche dite "métier" étant souvent utilisée par le contrôleur pour charger les données.
C'est d'ailleurs dans cette couche que je mettrais la logique de récupération des données, sinon, elle devrait être dans le contrôleur.
En général, on n'accède pas à une page JSP directement, pour se protéger d'un accès direct, il suffirait de placer les pages sous /WEB-INF/.
Il faudra donc un accès par le contrôleur (une servlet dans la plus simple expression)
27/09/2016, 17h16
Zeckkk

Merci de ta réponse.

C'est exactement ce que j'ai mis en place, ma jsp est appelé par une servlet, j'ai cependant pas différencier les données et les actions(ma JSP ne me sert que de vu par contre, alors qu'avant elle faisais tout :D).

mon problème est que j'aimerais garder cette simplicité de code qui est de ne pas avoir a gérer les try/catch et les erreurs autour des requettes sql dans ma servlet. je sais pas si c'est clair, sinon je mets un exemple en montrant la différence ?

Alors, d'un point de vue conceptuel, je ferais une classe utilitaire qui se charge de créer des connexions à la base de données.
Accessoirement, on pourrait l'utiliser pour libérer les ressources proprement...
Par contre, il est à la charge de "l'utilisateur" de libérer les ressources utilisées, du coup, de mon point de vue, c'est à la servlet de libérer les connexions.
Je ferais un truc comme ça

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
public void service(HttpServletRequest request, HttpServletResponse response)...
{
    Connection connection = null;
    PreparedStatement pstmt = null;
    ResultSet rs = null;
 
    try
    {
        connection = MaClasseUtilitaire.getConnection();
        pstmt = connection.prepareStatement("....");
        rs = pstmt.executeQuery();
        while (rs.next())
        {
 
        }
    }
    catch (Exception e)
    {
        // on trace...
    }
    finally
    {
        MaClasseUtilitaire.close(rs);
        MaClasseUtilitaire.close(pstmt);
        MaClasseUtilitaire.close(connection);
    }
}

MaClasseUtilitaire ressemblerait à ceci

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
public class MaClasseUtilitaire
{
    public static connection getConnection()
    {
        try
        {
            return DriverManager.getConnection(...);
        }
        catch (Exception e)
        {
            return null;
        }
    }
 
    public static void close(Object object)
    {
        try
        {
            if (object instanceof Connection)
            {
                ((Connection)object).close();
            }
            else if (object instanceof Statement)
            {
                ((Statement)object).close();
            }
            else if (object instanceof ResultSet)
            {
                ((ResultSet)object).close();
            }
        }
        catch (Exception e)
        {
            // on trace si besoin...
        }
    }
}

merci ça commence à me plaire :D

à l'heure actuel voici le code qui instancie tout ça dans mes jsp :
Code:

1 2 3 4 5 6 7 8 9 10 11 /* initialisation de nos objects sql / connection */ adn.generic.Sql adn_sql = new adn.generic.Sql(adn_parameter_path); java.sql.Connection adn_connection = null; if (adn_sql.error == 0){ /* RECUPERATION OBJECT java.sql.Connection*/ adn_connection = adn_sql.getConnection(); if (adn_sql.error != 0) throw new Exception("<br>Manager Sql Connexion Error : "+adn_sql.descerr+"<br>"); }else{ throw new Exception("<br>Manager Sql Error : "+adn_sql.descerr+"<br>"); }
et à priori grâce à ça et l'objet qui est appelé, je n'ai pas besoin de gérer dans mes pages JSP la libération des ressources ainsi que les exceptions.
Dans le code que tu m'a écris, j'ai encore un gros bloc de try/catch que je n'ai pas besoin en JSP.
J'aimerais garder cette légèreté dans mes servlets et externaliser dans des classes toutes ces problématiques.

28/09/2016, 12h06
OButterlin

Si tu veux absolument limiter l'usage des blocs try catch finally dans la servlet, une approche simple consiste à encapsuler le code d'accès aux données dans une classe spécialisée (souvent appelée "métier").
Cette classe spécialisée aura une instance dans la méthode de la servlet (doGet, doPost ou service) puisque les servlets sont multi-thread.

Cette classe serait une approche très simple du pattern façade.
C'est également un pattern très intéressant dans les applications web, en gros, l'application cause avec une seule façade qui est le reflet de toutes les interactions entre l'utilisateur et le reste...
Bien sûr, rien n'empêche d'avoir un découpage derrière cette façade, avec des DAO par exemple, le truc étant que la façade de l'application s'occupera d'adapter les données à celles utilisées par l'application (sachant qu'une autre façade, d'une autre application, pourrait utiliser les mêmes données de base autrement)
28/09/2016, 12h28
Zeckkk

mes connaissances en POO sont limité, même si j'ai suivi des cours sur le net, je n'ai pas une grand pratique.

donc si je comprends, tu voudrais que je fasse mes accès à ma BDD et mon traitement dans la couche metier et plus dans la couche contrôleur ? donc obligé d'utiliser la DAO ? je suis pas à l'aise avec ça ^^
as-tu des doc ou des exemples que je me documente ? à part mon tuto que javais suivi sur un autre site, je manque d'exemples de code je pense, voir comment des sites web respectant MVC sont fait.
28/09/2016, 12h35
OButterlin

Je n'ai pas d'applications utilisant des servlets, les plus vieilles que j'ai sont en Struts1, les dernières sont en JSF2...
Dans tous les cas, j'utilise des EJB3, l'idée reste la même mais il y a des mécanismes un peu différents.

Le plus proche d'une servlet serait Struts1, tu veux des exemples de ce type ?
28/09/2016, 14h28
Zeckkk

utiliser MVC n'est plus à jour pour du web ?
Si c'est possible oui je veux bien :)
Merci !

Un exemple type d'une action struts (le contrôleur)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
...
    public ActionForward load(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response)
            throws Exception
    {
        DetailForm _form = (DetailForm) form;
 
        forward = mapping.findForward(FORWARD_DEFAULT);
 
        ArboreFacadeRemote facade = ArboreEJBLocator.getInstance().getArboreFacadeRemote();
 
        _form.setDtoElement(facade.getElement(_form.getFilterUid(), null, null, _form.getDtoContexte()));
        _form.setCreatePending(false);
        _form.setSomethingAsChanged(false);
 
        /*
         * Traitement du mode d'affichage
         */
        processFieldMode(mapping, _form, request, response);
 
        return forward;
    }
...

Le code du modèle associé

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class DetailForm extends GenericForm
{
    public static final long serialVersionUID = 1;
    private static final Logger logger = Logger.getLogger(DetailForm.class);
    private String filterMode = "NORMAL";
    private Integer filterUid;
    private String nature;
    private String type;
    private DTOElement dtoElement = null;
    private List<String> listNatures;
    private List<DTOTypeElement> listTypes;
    private Arbt01[] listTypesLibelles = new Arbt01[60];
    private List<String> sis;
...
}

La facade de l'application

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
 
@Stateless(name = "ArboreFacade")
@TransactionTimeout(value = 3600)
public class ArboreFacadeImpl implements ArboreFacadeLocal, ArboreFacadeRemote
{
    @PersistenceContext(unitName = "ArborePU")
    protected EntityManager entityManager;
 
    @EJB
    private EnteteEJBLocal enteteEJB;
    @EJB
    private ElementEJBLocal elementEJB;
    @EJB
    private ArbdepscEJBLocal arbdepscEJB;
    @EJB
    private ArbcoeffEJBLocal arbcoeffEJB;
    @EJB
    private ArbrespEJBLocal arbrespEJB;
    @EJB
    private ArbetbsEJBLocal arbetbsEJB;
 
    ...
 
    public DTOElement getElement(Integer uid, String code, Integer division, DTOContexte dtoContexte)
    {
        try
        {
            Domaine domaine = null;
            if (Utils.isSet(uid))
            {
                domaine = entityManager.find(Domaine.class, uid);
            }
            else
            {
                Query query = entityManager.createQuery("select a from Domaine a where docodedom=:code and dodivision=:division");
                query.setParameter("code", code);
                query.setParameter("division", division);
                query.setMaxResults(1);
                domaine = (Domaine) query.getSingleResult();
            }
            return ArboreConverters.domaine2DTOElement(domaine);
        }
        catch (Exception e)
        {
            logger.error(e.toString());
        }
        return null;
    }
 
    public void deleteElement(Integer uid, DTOContexte dtoContexte) throws AbstractApplicationException
    {
        Domaine domaine = elementEJB.find(uid, dtoContexte);
        if (domaine != null)
        {
            elementEJB.delete(domaine, dtoContexte);
            traceElementAction(domaine, "DLT", dtoContexte);
        }
    }
 
    public DTOElement saveElement(DTOElement dtoElement, String mode, DTOContexte dtoContexte) throws ValidationException
    {
        Domaine domaine = ArboreConverters.dtoElement2Domaine(dtoElement);
        if (domaine.getDouid() == null)
        {
            domaine = elementEJB.save(domaine, dtoContexte);
            traceElementAction(domaine, "CRT", dtoContexte);
        }
        else
        {
            if ("NORMAL".equals(mode))
            {
                try
                {
                    domaine = elementEJB.checkForUsedElement(domaine, dtoContexte);
                }
                catch (Exception e)
                {
                    throw new EJBException(e);
                }
                domaine = elementEJB.update(domaine, dtoContexte);
                traceElementAction(domaine, "UPD", dtoContexte);
            }
            else
            {
                domaine = elementEJB.update(domaine, dtoContexte);
                traceElementAction(domaine, "UPD_FLAG", dtoContexte);
            }
        }
 
        return ArboreConverters.domaine2DTOElement(domaine);
    }
 
    ...    
}

28/09/2016, 15h07
Zeckkk

merci, ça me donne des pistes, même si j'ia l'impression que l'on ne peut pas se détacher des tryc/catch qui font grossir le code ^^
Merci ;)
28/09/2016, 15h10
OButterlin

Là il n'y a des try catch que dans la couche métier... dans la mesure où on veut récupérer l'erreur, sinon, ce n'est pas la peine.