Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 19 sur 19
  1. #1
    Membre habitué
    Inscrit en
    juillet 2004
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : juillet 2004
    Messages : 231
    Points : 128
    Points
    128

    Par défaut Développement en architecture 3 couches ?

    Bonjour,

    J'aimerai juste avoir votre avis sur le sujet d'un développement à 3 couches.
    Voilà, j'essaye (dans le but de me familiariser avec ce type de dév) de migrer une appli que j'ai faites sur ce schéma.
    Donc une couche ihm, métier et données.
    Prenons un exemple pour illustrer mes questions.

    On a une :
    - table T_USER (usr_id, usr_prenom, usr_nom, usr_age)
    - une interface qui liste dans une grille tous les user et qui permet de faire des recherches de mon user sur tous les critères : id, nom, prénom, age.

    (corriger moi si j'ai faux, ce sont des hypotèses sur ce que j'ai compris)

    J'ai donc bien compris l'élément essentiel, l'ihm ne peut communiquer directement avec la couche données sans passer par la couche métier.


    Dans ma couche données
    J'y mets toutes les procédures et fonctions qui iront intéragir avec les données. Cela va des Insert, Update, Delete... sur mes tables à mes requêtes Sql : entre autre ma requête Select qui va récupérer mes données à afficher dans ma grille de résultat sur l'ihm


    Dans ma couche métier
    Je vais recevoir de la part de ma couche ihm, toutes les saisies de mon utilisateur sur ses critères de recherche (qui peuvent être vide) et y faire les vérifs nécessaire (du style : une date doit être une date, un numérique doit être numérique, un champ ne peut être vide...) et une fois ces vérifs terminer je vais envoyer ces paramètres à ma couche données qui me retournera le résultat que je renvois à mon ihm


    Dans ma couche ihm
    Je récupère la saisie et balance les données brut à ma couche métier qui se chargera de faire les formatages et vérifs sur cette saisie. J'affiche ensuite le résulat de ce que me retournera la couche métier si aucune erreur


    Ok donc à partir de là j'ai sois bien compris la base soit j'ai faux.
    Mais dans la mesure où j'ai bien compris, comment se passe le cas où mon user va saisir ses critères de recherches ?
    Mon ihm balance la saisie à ma couche métier qui va tout vérifier avant de balancer ça à ma couche données ? Ok mais...
    Ma fonction de ma couche données qui va retourner les données va être une usine à gaz non ? Si j'ai 10 critères de recherche, il faut que je donne à cette fonction en paramètre, la liste des champs que je veux qu'il retourne, la liste des critères de recherche et eventuellement le champ ordonné (pour être le plus flexible possible) ? Cette fonction sera un vrai bricolage du style

    MaFonction (TabloChamp, TabloCondition, TabloOrdonnance)
    MaVariable = "Select "
    (ici la routine qui va récupérer dans les paramètres par exemple un tableau de champs à afficher)
    MaVariable = MaVariable & "From MaTable"
    (ici la liste des critères de recherche, si non renseigné le zapper par exemple)
    MaVariable = MaVariable & ORder By "
    (ici la liste des champs ordonnés"



    ???

  2. #2
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    101
    Détails du profil
    Informations personnelles :
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : septembre 2004
    Messages : 101
    Points : 57
    Points
    57

    Par défaut

    Je n'ai que relativement peu d'expérience sur le sujet (et je galère également terriblement pour trouver des infos claires sur le sujet), mais j'ai l'impression que ta couche métier n'en ai pas vraiment une.

    Ta couche métier devrait contenir des classes basées sur le modèle objet (donc proche du monde rélél). Tu dois donc mapper (transformer) les objets de classe d'accés aux données (basé sur un modèle relationnel, tes tables) à tes objets de classe métier (basé sur le modèle objet, tes objets de la vie réélle)

    Concernant la recherche, je m'oriente vers le fait qu'une instance de classe métier me sert également de structure de recherche. C'est à dire que les critéres saisi par l'utitisateur dans la couche présentation sont stocké dans un objet de classe métier. Du coup, je ne manipule que mes objets métiers (soit comme conteneur de recherche, soit comme conteneur de résultat)...

  3. #3
    Membre habitué
    Inscrit en
    juillet 2004
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : juillet 2004
    Messages : 231
    Points : 128
    Points
    128

    Par défaut

    De ce que j'ai commencé à faire, mes classes métiers se rapporte beaucoup à l'objet réel en question. C'est un peu ce que j'avais compris à ce sujet. En revanche j'y mets peut être d'autre procédures ou fonctions qui n'auraient pas lieu d'être.

  4. #4
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 960
    Points : 15 081
    Points
    15 081

    Par défaut

    il y a une discussion interessant sur le multi-couche ici.

    Pour résumer,

    - la couche donnée ne contient que les données, pas les query SQL. Donc en gros, c'est ta base de données. point.

    - la couche metier qui contient generalement:
    1. Des objets representant les "données", juste avec des methodes get et set (+ quelques methodes pour calculer des champs dynamiques)
    2. Des objets "controleur", qui manipulent les données (creation, modif, ... )
    3. Des objets "broker", qui sont chargés de charger, sauver les objets "données" depuis/dans la base de données. Generalement c'est un moteur ORM.

    - la couche presentation qui contient ton IHM, generalement un model MVC ou M(MVC)C.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  5. #5
    Membre habitué
    Inscrit en
    juillet 2004
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : juillet 2004
    Messages : 231
    Points : 128
    Points
    128

    Par défaut

    Arf dans la théorie j'arrive à bien comprendre, mais dans la pratique c'est pas la même chose. J'ai plus de mal.

  6. #6
    Invité de passage
    Inscrit en
    janvier 2007
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 2
    Points : 2
    Points
    2

    Par défaut

    Pour moi la définition la plus intéressante des architectures mutli couches est celle qu'a fournit graig larman et qui se définit comme suit :

    première couche :
    couche de présentation :

    ------------------------------------------------
    - HTML,DHTML,Ajax,Swing,WFC
    ------------------------------------------------

    Deuxième couche :
    Couche applicative :
    ------------------------------------------------------------------
    -- Contrôleurs,gestion des flux de pages web,gestion des sessions..
    ------------------------------------------------------------------

    troisiéme couche :
    Couche Domaine (POJO,Session beans ....):
    ----------------------------------------------------------------------
    --Englobe les objets du domaine model résultant d'une analyse par RUP
    --Model + services + logique applicative.....
    ----------------------------------------------------------------------

    Quatriéme couche :
    Couche applicative spécifique (Algorithmes ...)
    -----------------------------------------------------------------
    -- Applications specifiques comme calculs financiers ou autres
    -----------------------------------------------------------------

    Cinquiéme couche :
    Couche de services techniques :
    -----------------------------------------------------------------------
    -- Services fournis en général par des frameworks comme spring;struts ou
    -- autres et consistant en la persistance,la sécurité,la gestion des -- transactions...
    -----------------------------------------------------------------------

    Sixiéme couche :
    Couche Technique de bas niveau :
    -----------------------------------------------------------------
    -Bases de données,annuaire LDAP,Protocols particuliers HTTP,SOAP,
    TCP/IP..
    -----------------------------------------------------------------

    Cela reste pour moi le modèle le plus générique pour une application mutli couches,une fois qu'on a comprit ca on a tout comprit.

  7. #7
    Membre chevronné Avatar de slim
    Homme Profil pro Salim Chami
    Ingénieur développement logiciels
    Inscrit en
    décembre 2002
    Messages
    744
    Détails du profil
    Informations personnelles :
    Nom : Homme Salim Chami
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2002
    Messages : 744
    Points : 792
    Points
    792

    Par défaut

    Salut !
    j'ai vu dans cette discussion plusieurs modèles de développement en couche.
    Ils ont l'air très intéressents mais il faudrait que tu donne le type, la taille, les objectifs, le type d'utilisateurs etc. de ton application. Le modèle "qu'a fournit graig larman" est surement utilisé pour les grandes applications.

    j'ajoute une remarque : dans la discussion, le mot IHM est mal employé. Il s'agit de l'interface ici, je crois.

    Bref, je te suggérerai le design pattern MVC. Il en existe d'autres, mais c'est celui que je connais.
    Contrairement à ce qu'a dit pseudocode, le MVC ne se situe pas seulement dans la couche présentation mais contient cette couche.
    Citation Envoyé par Wikipédia fr
    L'architecture Modèle Vue Contrôleur (MVC) est un motif de conception pour le développement d'applications logicielles qui sépare le modèle de données, l'interface utilisateur et la logique de contrôle.
    Tu n'a qu'a chercher dans cette voie.
    Ou si ton application est de grande taille, la solution proposée par Ismail.h me parait convenable.

    Remarque 2 : MVC aussi est plus adapté aux moyennes et grandes applications.
    Il en existe d'autres mieux adaptés aux petites.

  8. #8
    Membre habitué
    Inscrit en
    juillet 2004
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : juillet 2004
    Messages : 231
    Points : 128
    Points
    128

    Par défaut

    Un peu plus de détail sur mon application.

    C'est une application développée en VB.NET 2005. La particularité c'est que j'ai en fait 2 applications qui utilisent le même jeu de fonctions Sql et ont beaucoup de procèdures et fonctions métier en commun, pour ces raisons je comptais avoir une couche d'accès aux données et métier identique pour faciliter les mises à jour. A l'heure actuelle tout est fait en VB.NET 2005 et Access 2003, on pourrait envisager une migration future sur une plateforme web mais pour l'instant ce n'est pas le cas.

    Je précise que c'est en VB.NET car j'ai appris que java (que je ne connais pas) était beaucoup plus approprié à un dév multicouches, mais qu'en est-il de VB.NET ?

    Donc pour en revenir à mon appli j'avais dans l'idée d'utiliser une DLL Pour la couche d'accès aux données et une DLL regroupant toute la partie métier....

    Corrigez moi si je me trompe, hormis merise il est vrai que je ne connais pas les autres méthodologie...

  9. #9
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 960
    Points : 15 081
    Points
    15 081

    Par défaut

    Pour moi la définition la plus intéressante des architectures mutli couches est celle qu'a fournit graig larman et qui se définit comme suit :
    Dans une architecture en couche, une couche de niveau N ne peut communiquer qu'avec les couches N-1 et N+1. La definiton de graig larman mélange alegrement le decoupage en couches applicatives (présentation, données, logique métier) et le decoupage en couches techniques (framework, communication, securité) .

    Citation Envoyé par slim
    Contrairement à ce qu'a dit pseudocode, le MVC ne se situe pas seulement dans la couche présentation mais contient cette couche.
    Oui et Non. Le MVC est a la fois un pattern de conception (dans une IHM) ET un style d'architecture (dans une application).

    Si tu dis que le MVC contient la présentation, alors tu parles du MVC en tant que style d'architecture, et du coup on n'est plus dans une architecture en couche (N+1 / N / N-1). Dans ce style d'architecture, tu aurais la présentation dans la VUE, les données dans le MODELE et le reste dans le CONTROLEUR et ces 3 "objets" seraient reliés en triangle.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  10. #10
    Membre chevronné Avatar de slim
    Homme Profil pro Salim Chami
    Ingénieur développement logiciels
    Inscrit en
    décembre 2002
    Messages
    744
    Détails du profil
    Informations personnelles :
    Nom : Homme Salim Chami
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2002
    Messages : 744
    Points : 792
    Points
    792

    Par défaut

    Citation Envoyé par pseudocode
    Dans une architecture en couche, une couche de niveau N ne peut communiquer qu'avec les couches N-1 et N+1. La definiton de graig larman mélange alegrement le decoupage en couches applicatives (présentation, données, logique métier) et le decoupage en couches techniques (framework, communication, securité) .
    +1


    Citation Envoyé par pseudocode
    Oui et Non. Le MVC est a la fois un pattern de conception (dans une IHM) ET un style d'architecture (dans une application).

    Si tu dis que le MVC contient la présentation, alors tu parles du MVC en tant que style d'architecture, et du coup on n'est plus dans une architecture en couche (N+1 / N / N-1).
    je suis d'accord quand tu dis que je parle de MVC en tant que style d'architecture. Mais meme là, l'architecture en couche (N+1 / N / N-1) est respectée. Controleur / Modele / Vue

  11. #11
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 960
    Points : 15 081
    Points
    15 081

    Par défaut

    Citation Envoyé par slim
    je suis d'accord quand tu dis que je parle de MVC en tant que style d'architecture. Mais meme là, l'architecture en couche (N+1 / N / N-1) est respectée. Controleur / Modele / Vue
    Heu, non pas trop



    Model-view-controller from WikiPedia
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  12. #12
    Membre chevronné Avatar de slim
    Homme Profil pro Salim Chami
    Ingénieur développement logiciels
    Inscrit en
    décembre 2002
    Messages
    744
    Détails du profil
    Informations personnelles :
    Nom : Homme Salim Chami
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2002
    Messages : 744
    Points : 792
    Points
    792

    Par défaut

    Ok !

    Tu dis qu'une architecture en couche doit respecter le modele N-1 / N / N+1.
    N-1 et N+1 ne peuvent pas communiquer. J'en vois pas l'utilité...
    MVC ne respecte pas cette règle et pourtant c'est une architecture en couche ?
    Il y a bien séparation entre les données, l'interface, et "le reste"...
    Le but est de faciliter la modifiabilité. C'est le cas ici, sans la règle "N-1 / N / N+1"


  13. #13
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

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

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 960
    Points : 15 081
    Points
    15 081

    Par défaut

    Citation Envoyé par slim
    MVC ne respecte pas cette règle et pourtant c'est une architecture en couche ?
    Non, ce n'est pas une architecture en couche, car ca ne respecte pas la regle N-1 / N / N+1

    Citation Envoyé par slim
    Il y a bien séparation entre les données, l'interface, et "le reste"...
    Le but est de faciliter la modifiabilité. C'est le cas ici, sans la règle "N-1 / N / N+1"
    Le modele "en couche" n'est bien sur pas le seul qui permette d'assurer la séparation, la modifiabilité,...

    Il faut differencier les 2 notions:

    - les "styles d'architecture", qui répondent a une definition precise (couche, MVC, Client-Serveur, tableau noir, ...)

    - les caracteristiques non fonctionelles (aka. Quality Attribute) de ton architecture, par exemple: Performance, Reusability, Isolation, Security, Modifiability, Evolutivity (aka. P.R.I.S.M.E)

    On peut "evaluer" un style d'architecture selon ces caracteristiques. Et meme si le MVC a une bonne note en "Isolation" et "Modifiability", on pourrait imaginer un autre style qui serait aussi bien (mieux ?) noté.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  14. #14
    Membre habitué
    Inscrit en
    juillet 2004
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : juillet 2004
    Messages : 231
    Points : 128
    Points
    128

    Par défaut

    Je suis en train d'essayer d'appliquer une architecture à 3 couches à une appli existante. C'est pas une mince affaire.... J'ai l'impression de multiplier le nombre de ligne de code par 3 !
    Ok, le jour où je migre une des couches c'est beaucoup plus simple et rapide mais là j'ai l'impression d'en faire une usine à gaz.
    Cest normal ou je m'y prend mal ?

  15. #15
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    101
    Détails du profil
    Informations personnelles :
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : septembre 2004
    Messages : 101
    Points : 57
    Points
    57

    Par défaut

    La contrainte principale de l'architecture en couche est qu'il n'y ait aucune dépendance vers les couches supérieures. Une couche N, peut donc être dépendante des couches inférieures (N+x), mais pas des couches supérieures (N-x). C'est ce point qui permet la réutilisabilité des couches dans différentes applications ou même différents SI. Quant à la contrainte de ne pas avoir à 'sauter' une couche, cela me parait plus être un choix, qu'un dogme inébranlable.

    Dinbougre, il y a pas mal d'autres discussions sur ce sujet (dans les forums conception & DotNet) mais pour en revenir à ce que tu as ecrit plus haut, je te conseille de penser de la manière suivante :

    Ta couche d'accés aux données doit être basé sur un modèle relationnel et doit permettre un accés simple et générique à l'ensemble des données persisitante (BDD en ce qui te concerne). Personnellement, je travaille également sur DotNet et sur une appli qui ressemble à ce que tu fais, et j'utilise des DataSet fortement typés dans cette couche et rien d'autre.

    Dans ta couche métier, tes classes métiers dovent être basées sur le modèle objet.
    Il est également nécessaire de mapper (transformer) tes données relationnelles en données orienté objet. Pour cela, je te conseille de créer un ensemble de classe de mapping ou d'utiliser un outil ORM (ou autre framework de persistance gérant la fonctionnalité de mapping). Je pense que la partie contrôle peut être gérer indépendamment ou dans tes classes de mapping (qui tu pourrais nommer du coup 'Controleur')

    Tu peut imaginer une couche application, si tu as beaucoup de données 'de session' (existant dans la durée de vie d'une utilisation de ton appli)

    Et pour la couche IHM, rien de neuf.

    Normalement, ton code ne doit pas être énormément plus lourd, mais plutot mieux réparti.

    Bonne chance

  16. #16
    Membre habitué
    Inscrit en
    juillet 2004
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : juillet 2004
    Messages : 231
    Points : 128
    Points
    128

    Par défaut

    Ok merci c'est un peu plus clair
    Je vais marquer le sujet en "Résolu" et sauter dans le bain

    Merci à tous

  17. #17
    Expert Confirmé Sénior
    Avatar de Immobilis
    Inscrit en
    mars 2004
    Messages
    6 551
    Détails du profil
    Informations forums :
    Inscription : mars 2004
    Messages : 6 551
    Points : 7 246
    Points
    7 246

    Par défaut

    Salut,

    Faire une couche multitiers peu paraitre difficile à gérer et donner l'impression de répéter du code.
    Quels peuvent être les risque à mêler l'entité à ses méthodes?

    Cela rend les entités dépendantes de la couche d'accès à prioris...
    Cela rend-il les évolutions plus compliquées?

    Merci

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  18. #18
    Invité de passage
    Inscrit en
    novembre 2010
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : novembre 2010
    Messages : 1
    Points : 1
    Points
    1

    Par défaut

    Bonjour. je suis débutant en Je22 ,j'arrive pas à détermine exactement le définition et le rôle de couche métier. est ce que qq peut m'aide?
    merciii

  19. #19
    Membre expérimenté Avatar de NicoL__
    Homme Profil pro Nicolas
    Inscrit en
    janvier 2011
    Messages
    399
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas
    Localisation : France

    Informations forums :
    Inscription : janvier 2011
    Messages : 399
    Points : 548
    Points
    548

    Par défaut

    Architecture tiers (qui veut dire littéralement "gradin" en anglais, et attention quand les anglais parle de layer c'est parfois autre chose, plus en rapport avec le physique) est un concept simple.
    En gros chaque tiers correspond à une responsabilité (accès base de données, réalisation des algo métiers, présentation, et on peut en trouvé d'autre...).
    L'idée de séparation : pas de recouvrement de responsabilité et dépendance dans un seul sens (comme dans un gradin).
    Contrairement ça donne un namespace par tiers et des import de namespace autorisé que dans le tiers juste supérieur.

    Pour digressé un peu sur le layer, la présentation en web est réalisé à la fois sur le serveur : création du flux HTML et le sur le client : interprétation du flux plus exécution javascript. Y a un tiers et 2 layers.

    Pour répondre à haitso : normalement c'est la ou on implémente les règles du cahier des charges... mais bon des fois c'est juste mettre les données en base alors ça serait une couche qui ne fait que transmettre de la présentation à la couche DAO... juste des métodes "passe plat"

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •