Discussion :

[goran kajfes]

Bonjour à tous.

Je débute en architecture 3-tiers. J'ai lu et réutilisé sur un autre projet l'excellent tutoriel de Thomas Lebrun mais comme ce n'est qu'une introduction, je me pose encore pas mal de questions.

Je m'excuse d'avance au cas où mes questions manqueraient de clarté.

Les 3-tiers sont:

1. la couche de présentation
2. la couche applicative (ou métier)
3. la couche d'accès aux données

Questions :

1) où placer le contrôle de saisie pour un formulaire ? Obligatoirement dans la couche de présentation ou dans celle du métier ?

2) une fois chargées, les tables deviennent des collections d'objets (chaque ligne représentant un objet). Ces derniers sont utilisés par la couche métier et la couche d'accès aux données (en tout cas dans l'exemple de Thomas). Dans le cas où les 3-tiers seraient réparties sur 3 machines distantes, il faudrait déployer les objets métiers sur 2 machines différentes. Est-ce que je me trompe ? Y aurait-il un moyen de ne déployer ces classes que sur une seule (et donc de les associer strictement à une seule couche) ?

3) Il peut-être pratique d'ajouter des méthodes autres que celles représentants les colonnes de la table aux classes des objets métiers. Par exemple, une concaténation de propriétés, mais aussi le total d'une ligne de commande. Est-ce une mauvaise pratique ? Faut-il réserver ça à la couche métier (applicative) ? Mais si je mets ce calcul dans la couche métier, il faudrait alors que je recrée une nouvelle collection d'objets (métiers ?), pour la transmettre telle quelle à un widget (ex: utilisation de la propriété DataSource d'un contrôle ComboBox ou ListBox en .net/winform). Est-ce un problème ? De tels objets pourraient-ils toujours être considérés comme des objets métiers ?

4) Cette question fait écho à la précédente. Supposons que je veuille afficher un tableau construit à partir de la jointure de 2 tables. Je ne vois pas comment lui transmettre une collection d'objets en utilisant à un moment ou à un autre, les objets métiers (chaque objet métier représentant une table et une seule).

5) Les pools de connexion de SqlServer 2008 limitent-ils l'intérêt des singletons (des couches métier et d'accès aux données) ?

6) Pourquoi la couche métier porte-t-elle ce nom ? Il ne me semble pas très intuitif. Y aurait-il un nom plus approprié ?

[pseudocode]

Bonsoir,

voila mon interprétation des choses :

1) où placer le contrôle de saisie pour un formulaire ? Obligatoirement dans la couche de présentation ou dans celle du métier ?

Si le controle de saisie ne contient que des règles de syntaxe (regexp, ...) ou de cohérence inter-champs (date début/fin, ...), alors le contrôle peut être fait dans la couche de présentation.

Si le controle necessite une règle métier (disponibilité de stocks, ...) il doit être déplacé dans la couche métier.

2) une fois chargées, les tables deviennent des collections d'objets (chaque ligne représentant un objet). Ces derniers sont utilisés par la couche métier et la couche d'accès aux données (en tout cas dans l'exemple de Thomas). Dans le cas où les 3-tiers seraient réparties sur 3 machines distantes, il faudrait déployer les objets métiers sur 2 machines différentes. Est-ce que je me trompe ? Y aurait-il un moyen de ne déployer ces classes que sur une seule (et donc de les associer strictement à une seule couche) ?

Il est tout a fait possible de créer une représentation "neutre" des données pour communiquer facilement entre la couche métier et la couche DAO. Par exemple une map <clé,valeur>, ou mieux <clé,type/valeur>.

Dans ce cas, la couche métier doit pouvoir sérialiser/désérialiser des objets dans ce format neutre.

3) Il peut-être pratique d'ajouter des méthodes autres que celles représentants les colonnes de la table aux classes des objets métiers. Par exemple, une concaténation de propriétés, mais aussi le total d'une ligne de commande. Est-ce une mauvaise pratique ? Faut-il réserver ça à la couche métier (applicative) ? Mais si je mets ce calcul dans la couche métier, il faudrait alors que je recrée une nouvelle collection d'objets (métiers ?), pour la transmettre telle quelle à un widget (ex: utilisation de la propriété DataSource d'un contrôle ComboBox ou ListBox en .net/winform). Est-ce un problème ? De tels objets pourraient-ils toujours être considérés comme des objets métiers ?

L'héritage ou la composition sont deux moyens de créer des objets métier "enrichis" à partir des objets métier "de base".

4) Cette question fait écho à la précédente. Supposons que je veuille afficher un tableau construit à partir de la jointure de 2 tables. Je ne vois pas comment lui transmettre une collection d'objets en utilisant à un moment ou à un autre, les objets métiers (chaque objet métier représentant une table et une seule).

Il y a soit la solution d'envoyer les objets "en entier" a la couche métier qui devra se charger de créer les associations. Ou alors la solution de créer un type d'objet spécifique pour la requete executée.

5) Les pools de connexion de SqlServer 2008 limitent-ils l'intérêt des singletons (des couches métier et d'accès aux données) ?

Je ne vois pas bien le rapport entre ces 2 concepts.

6) Pourquoi la couche métier porte-t-elle ce nom ? Il ne me semble pas très intuitif. Y aurait-il un nom plus approprié ?

Parce que c'est celle qui modélise le "métier" (données + process) sous-jacent à l'application. Par exemple le métier du commerce, du transport, du médical, de l'administratif, ...

[goran kajfes]

Bonjour pseudocode.

1) Si le controle de saisie ne contient que des règles de syntaxe (regexp, ...) ou de cohérence inter-champs (date début/fin, ...), alors le contrôle peut être fait dans la couche de présentation.

Si le controle necessite une règle métier (disponibilité de stocks, ...) il doit être déplacé dans la couche métier.

Entendu.

2) Il est tout a fait possible de créer une représentation "neutre" des données pour communiquer facilement entre la couche métier et la couche DAO. Par exemple une map <clé,valeur>, ou mieux <clé,type/valeur>.

Sur un autre tutoriel, Serge Tahé place le source des objets métiers et des exceptions dans la couche d'accès aux données, puis importe une bibliothèque de cette même couche dans les 2 autres.

3) L'héritage ou la composition sont deux moyens de créer des objets métier "enrichis" à partir des objets métier "de base".

D'accord.

4) Il y a soit la solution d'envoyer les objets "en entier" a la couche métier qui devra se charger de créer les associations. Ou alors la solution de créer un type d'objet spécifique pour la requete executée.

Recréer des associations ? Ce doit être un peu laborieux à coder. Je suppose que la plupart des développeurs ne codent pas cela à la main mais utilisent des bibliothèques pour faire un mappage objet-relationnel, non ?

Donc on peut aussi créer un objet spécifique à la requête. Mon formateur me l'avait déconseillé, mais cela me laissait un peu dubitatif.

5) Je ne vois pas bien le rapport entre ces 2 concepts.

Je ne suis pas sûr de comprendre ce que j'ai voulu dire.
En parlant de connexion à la base, j'ai peut-être débusqué une anomalie dans le tutoriel de Thomas Lebrun : il utilise le mode connecté, mais ne se déconnecte jamais après chaque requête. En tout cas c'est ce que me dit l'espion. L'instruction using serait ici trompeuse car en fait la mémoire du vrai objet connexion n'est pas libérée.

Du coup

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
using (DbConnection cnx = SqlFactory.Instance.GetSqlConnection()) {
    clients = GetClientsFromDB(cnx);
}

serait à remplacer par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
try {
    DbConnection cnx = SqlFactory.Instance.GetSqlConnection();
    clients = GetClientsFromDB(cnx);
} finally {
    SqlFactory.Instance.CloseConnection();
}

Faudrait que je lui écrive.

6) Parce que c'est celle qui modélise le "métier" (données + process) sous-jacent à l'application. Par exemple le métier du commerce, du transport, du médical, de l'administratif, ...

Le terme a une connotation très professionnelle.


Je te remercie pour ta réponse. Le brouillard se dissipe un peu.

Le tutoriel de Serge Tahé m'a aussi éclairé. J'ai appris ce qu'est une interface et comment en tirer parti pour autonomiser un peu plus les différentes couches. Il montre aussi comment utiliser Spring pour ne plus écrire le nom des classes directement dans le code, mais plutôt dans un fichier de configuration xml.

[pseudocode]

Sur un autre tutoriel, Serge Tahé place le source des objets métiers et des exceptions dans la couche d'accès aux données, puis importe une bibliothèque de cette même couche dans les 2 autres.

La couche DAO (comme son nom l'indique) est chargée de faciliter l'accès aux données métiers. Elle n'a pas forcément pour responsabilité de créer des objets métiers (données enrichies + comportement + relations), meme s'il arrive assez souvent qu'elle face les deux. Dans ce dernier cas, on parle plus facilement de "Data Store" que de DAO.

Recréer des associations ? Ce doit être un peu laborieux à coder. Je suppose que la plupart des développeurs ne codent pas cela à la main mais utilisent des bibliothèques pour faire un mappage objet-relationnel, non ?

Effectivement, on utilise souvent des ORM pour faire cela. Encore faut-il que la source des données s'y prête, c'est à dire que le schéma de la BdD soit assez proche du schéma Objet de l'application

Donc on peut aussi créer un objet spécifique à la requête. Mon formateur me l'avait déconseillé, mais cela me laissait un peu dubitatif.

Je suppose qu'il parlait du cas ou la BdD est créée spécialement pour l'application : la couche DAO+BdD fait de la "persistance objet". Auquel cas toutes les données de la BdD sont des attributs d'objets de l'application, donc autant récupérer ces objets qu'en créer des nouveaux.

[Hephaistos007]

Donc on peut aussi créer un objet spécifique à la requête. Mon formateur me l'avait déconseillé, mais cela me laissait un peu dubitatif.

Oui, je pense comprendre ton problème et cela m'interpelle tout à coup. Peut-être que pseudocode pourra nous éclairer.

L'idée du mapping objet-relationnel c'est qu'à chaque table peut correspondre un objet équivalent. En somme, que le schéma de la BD corresponde au "diagramme de classe". Or, par définition, les opérateurs de jointure et de projection en SQL produisent des "tables" dont la structure est implicite, c-a-d qui n'ont pas de définition explicite comme c'est le cas des schemas. Du même coup, il est bien évident qu'il n'existe pas de classe d'objets en mesure de recueillir ces informations, sauf à faire ce dont parlais ton formateur.

Peut-être qu'en pratique (je ne programme plus beaucoup), les résultats d'une jointure sont récupérés dans le seul objet prévu à cet effet, c-a-d un ResulSet, qui sera alors manipulé directement pour récupérer et afficher les informations. Si c'est le cas, il n'y a pas d'objet "métier" à proprement parler.

[pseudocode]

Peut-être qu'en pratique (je ne programme plus beaucoup), les résultats d'une jointure sont récupérés dans le seul objet prévu à cet effet, c-a-d un ResulSet, qui sera alors manipulé directement pour récupérer et afficher les informations. Si c'est le cas, il n'y a pas d'objet "métier" à proprement parler.

Oui, c'est effectivement le cas.

Si l'ORM dispose d'un système de requetes "orienté objet", on formule la requete à l'ORM et celui ci revoie des instances d'objets.

Sinon, on effectue des requêtes SQL classiques :
- des requetes SQL qui renvoient des données, sous forme de resultset.
- des requetes SQL qui renvoient des "id" d'objet, puis on demande a l'ORM de construire les objets correpondant a ces "id".

[Hephaistos007]

Si l'ORM dispose d'un système de requetes "orienté objet", on formule la requete à l'ORM et celui ci revoie des instances d'objets.

Oui, mais dans le cas simple d'interrogation d'une table où dans le cas plus complexe (qui nous intéresse ici) d'une jointure et/ou d'une projection ? Par exemple si j'exprime une requête de jointure entre la table client et la table commande, comment un ORM peut-il me renvoyer des objets dont la structure est l'union des attributs de la classe métier CLIENT et de la classe métier COMMANDE ?

[pseudocode]

Oui, mais dans le cas simple d'interrogation d'une table où dans le cas plus complexe (qui nous intéresse ici) d'une jointure et/ou d'une projection ? Par exemple si j'exprime une requête de jointure entre la table client et la table commande, comment un ORM peut-il me renvoyer des objets dont la structure est l'union des attributs de la classe métier CLIENT et de la classe métier COMMANDE ?

Dans des requetes "orienté objet" il n'est pas possible de demander autre chose que des objets ou des attributs d'objets. Genre :

"SELECT c FROM client AS c WHERE c.commande.prix>100", qui renvoie une liste d'instances de la classe client

ou

"SELECT c.nom FROM client AS c WHERE c.commande.prix>100", qui renvoie une liste de String (les noms des clients)


Par contre si tu fais une requete SQL, là tu te retrouves avec un resultset et l'ORM ne peut rien faire pour toi. Dans ces cas là, on fait une requete SQL pour récupérer l'id des objets (une liste d'entier), puis on utilise la couche DAO pour aller chercher les objets

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
List<int> listid = executeSQL("SELECT c.id FROM client AS c INNER JOIN commande AS com ON com.clientid = c.id WHERE com.prix>100")
for(int id : listid) {
    Client c = DAO.getClient(id);
    ...
}

[Hephaistos007]

Oui, je comprends mieux. Bon et bien je me retire du débat dans lequel je n'ai rien à faire à l'origine