IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres Discussion :

répartition des composants (débutant)


Sujet :

Autres

  1. #1
    Membre régulier
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    128
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2005
    Messages : 128
    Points : 100
    Points
    100
    Par défaut répartition des composants (débutant)
    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é ?

  2. #2
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 797
    Points
    15 797
    Par défaut
    Bonsoir,

    voila mon interprétation des choses :

    Citation Envoyé par goran kajfes Voir le message
    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, ...
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    128
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2005
    Messages : 128
    Points : 100
    Points
    100
    Par défaut
    Bonjour pseudocode.

    Citation Envoyé par 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.

    Citation Envoyé par pseudocode
    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.

    Citation Envoyé par pseudocode
    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.

    Citation Envoyé par pseudocode
    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.

    Citation Envoyé par pseudocode
    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.

    Citation Envoyé par pseudocode
    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.

  4. #4
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 797
    Points
    15 797
    Par défaut
    Citation Envoyé par goran kajfes Voir le message
    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.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  5. #5
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    décembre 2004
    Messages
    2 492
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2004
    Messages : 2 492
    Points : 4 061
    Points
    4 061
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    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.
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  6. #6
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 797
    Points
    15 797
    Par défaut
    Citation Envoyé par Hephaistos007 Voir le message
    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".
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  7. #7
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    décembre 2004
    Messages
    2 492
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2004
    Messages : 2 492
    Points : 4 061
    Points
    4 061
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    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 ?
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

  8. #8
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 061
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 061
    Points : 15 797
    Points
    15 797
    Par défaut
    Citation Envoyé par Hephaistos007 Voir le message
    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);
        ...
    }
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  9. #9
    Expert confirmé
    Avatar de Hephaistos007
    Profil pro
    Enseignant Chercheur
    Inscrit en
    décembre 2004
    Messages
    2 492
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2004
    Messages : 2 492
    Points : 4 061
    Points
    4 061
    Par défaut
    Oui, je comprends mieux. Bon et bien je me retire du débat dans lequel je n'ai rien à faire à l'origine
    Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes --- devise SHADOKS

    Kit de survie Android : mon guide pour apprendre à programmer sur Android, mon tutoriel sur les web services et enfin l'outil en ligne pour vous faire gagner du temps - N'oubliez pas de consulter la FAQ Android

Discussions similaires

  1. [Débutant] Analyse des composants du Welcome Center de Vista
    Par badack dans le forum Windows Presentation Foundation
    Réponses: 1
    Dernier message: 24/08/2009, 13h26
  2. Répartition des composants dans une fenetre
    Par Oussama_Gabes dans le forum AWT/Swing
    Réponses: 7
    Dernier message: 11/04/2008, 14h40
  3. Réponses: 5
    Dernier message: 19/02/2007, 15h44
  4. [débutant][JSplitPane] Centrage des composants
    Par gcore dans le forum Agents de placement/Fenêtres
    Réponses: 4
    Dernier message: 17/06/2004, 19h11
  5. Réponses: 1
    Dernier message: 02/01/2003, 12h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo