technologie objet et architecture n-tiers

Bonjour,

Contexte

Dans le cadre d'une refonte de mon application web (PHP) je cherche à mettre en pratique une architecture simple, efficace, ... combinée à la technologie objet.

Or je me heurte depuis un long moment à ce qui me paraît être une incompatibilité entre l'architecture N-tiers et la méthodologie objet. Si vous pouviez m'éclaircir les idées, je vous serez reconnaissant.


Définition

La technologie objet:
- type = module = classe
- une classe est composée de caractéristiques (attributs et routines)

Architecture N-tiers:
- couche DAL
- couche métier
- couche de presentation

- manipulation d'objet métier (DTO)


Doute
J'ai pu constater que les classes métiers contenaient uniquement des attributs, accesseurs et modifieurs. Et que les traitement s'effectués dans des classes de collection de fonction.
Mais n'est ce pas en soi une "aberration" de la méthodologie objet?
J'ai l'impression que les classes sont aux services des fonctions, procédures, ce qui est contraire à la raison de la naissance de la technologie objet.


La logique métier ne devraient-elle pas être incluse dans les objets métiers?

Dans une vision N-tiers les classes seraient-elles devenus de simple conteneur? Les classes métiers, des types sans aucunes opérations?


Merci de votre aide.

Première précision : il faut bien faire la différence entre N-tier qui décrit la distribution physique d'une application (les tiers étant habituellement séparés les uns des autres par le réseau, ex : tiers client, tiers serveur d'application, tiers serveur de BDD) et application en couches qui décrit le découpage logique du code. Les deux se confondent souvent mais pas toujours.

Dans ton cas tu sembles parler des couches applicatives.

Citation:

---

Envoyé par Conaclos

Mais n'est ce pas en soi une "aberration" de la méthodologie objet?
J'ai l'impression que les classes sont aux services des fonctions, procédures, ce qui est contraire à la raison de la naissance de la technologie objet.

---

Tu as raison, orienté objet implique théoriquement encapsulation des données et des comportements dans les objets métier. Lorsque ce n'est pas le cas et que toute la logique métier se trouve dans des services (l'équivalent de ce que tu nommes classes de collection de fonction) certains qualifient la chose d'anti-pattern (Anemic Domain Model). Il y a débat dans la communauté pour savoir si et quand c'est vraiment une mauvaise pratique ou non.

Rassure toi, il n'y a pas du tout incompatibilité entre N-Tier (ou multi-layer) et orienté objet, si tu te sens plus à l'aise avec une logique encapsulée dans les objets métier, n'hésite pas à le faire. Certaines méthodes de conception (DDD) sont même fondées autour de ce concept. Cela a notamment pour avantage un code qui colle plus aux vrais concepts métier et plus lisible car moins épars ; en revanche attention à bien attribuer les bonnes responsabilités aux bons objets.