Discussion :

[dinbougre]

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"


???

[Exsilius]

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)...

[dinbougre]

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.

[pseudocode]

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.

[dinbougre]

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.

[Ismail.h]

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.

[slim]

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.

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.

[dinbougre]

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...

[pseudocode]

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é) .

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.

[slim]

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

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

[pseudocode]

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

[slim]

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"

[pseudocode]

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

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é.

[dinbougre]

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 ?

[Exsilius]

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

[dinbougre]

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

Merci à tous

[Immobilis]

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+

[haitso]

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

[NicoL__]

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"