Discussion :

[nymformaticien]

Bonjour,

D'après http://baptiste-wicht.developpez.com...eption/mvc/#LI, le modèle représente les données de l'application, mais définit aussi le traitement de ces données.

D'après http://laurent-audibert.developpez.c...5.html#htoc206, les classes entités, qui sont issues du modèle du domaine, ne comportent que des attributs, et les contrôles, qui implémentent la logique applicative, ne comportent que des opérations.

J'ai donc l'impression qu'il y a deux visions différentes de la couche "modèle" d'une application :
- une vision "objet", pour laquelle une classe définit un état et le comportement des objets qu'elle permet d'instancier ; les objets créés sont donc autonomes, possèdent des attributs et des méthodes.
- une vision "impérative", pour laquelle une classe ne décrit que l'état des objets qu'elle permet d'instancier ; les objets créés permettent donc uniquement le stockage (non-persistant) de données et ne contiennent que des attributs.

Les questions que je me pose : quelle approche utilisée et pour quelle situation? Quelles sont les avantages et les inconvénients de chacune d'elles? Laquelle avez-vous l'habitude d'utiliser dans vos projets?

Merci par avance et bonne journée.

cc

[ego]

Séparer données et traitements est souvent une bonne solution surtout en "informatique de gestion". Dans ces cas, les données sont bien souvent utilisées dans différents contextes, il est donc préférable qu'elles ne portent pas de traitements qui ne serait valables que dans un contexte précis. Où alors elles deviendrait "trop grosses" car elles sauraient "tout" faire elles-mêmes.
Mais je crois que cette séparation est, selon mon expérience personnelle, une très bonne chose qui ne va en fait pas du tout à l'encontre du paradigme objet.
L'avantage, gestion ou pas, c'est pour faire passer les données d'un "tier" à l'autre. Si tu y mets des traitements (opérations), attention à ce que ces opérations n'utilisent que les données propres à l'objet car sinon, tu auras des problèmes quand ton objet passera du tier serveur au tier client; car sur le client tu n'auras pas le même contexte ni les mêmes librairies (par exemple).

Maintenant, dans l'informatique embarquée, peut être que la situation est différente, là je ne sais pas car je n'en ai pas beaucoup fait.


Fait attention aux 2 articles qui ne traitent pas du même sujet.
Le M de MVC c'est le modèle côté couche IHM, les entités de l'autre article c'est le "modèle métier" côté couche métier/serveur. Ils ne parlent donc pas de la même chose.

[nymformaticien]

Merci pour ta réponse.

Séparer données et traitements est souvent une bonne solution surtout en "informatique de gestion". Dans ces cas, les données sont bien souvent utilisées dans différents contextes, il est donc préférable qu'elles ne portent pas de traitements qui ne serait valables que dans un contexte précis. Où alors elles deviendrait "trop grosses" car elles sauraient "tout" faire elles-mêmes.
Mais je crois que cette séparation est, selon mon expérience personnelle, une très bonne chose qui ne va en fait pas du tout à l'encontre du paradigme objet.
L'avantage, gestion ou pas, c'est pour faire passer les données d'un "tier" à l'autre. Si tu y mets des traitements (opérations), attention à ce que ces opérations n'utilisent que les données propres à l'objet car sinon, tu auras des problèmes quand ton objet passera du tier serveur au tier client; car sur le client tu n'auras pas le même contexte ni les mêmes librairies (par exemple).

Je croyais qu'en POO, un objet était autonome, que ses méthodes définissaient son comportement et permettaient de faire évoluer son état. J'ai donc tout faux?

Fait attention aux 2 articles qui ne traitent pas du même sujet.
Le M de MVC c'est le modèle côté couche IHM, les entités de l'autre article c'est le "modèle métier" côté couche métier/serveur. Ils ne parlent donc pas de la même chose.

Donc le modèle côté IHM (http://baptiste-wicht.developpez.com...eption/mvc/#LI) décrit les données de l'application et leur(s) traitement(s). La séparation données/traitements n'est donc respectée dans ce cas là. Ce n'est donc pas la bonne solution? Ce que tu m'as expliqué (séparation données/traitements), est-ce valable pour du MVC ou pour une architecture 3-tiers?

Merci de m'éclairer sur ce sujet : ce n'est pas encore très clair pour moi.

cc

[nymformaticien]

Pour résumer : ne pas mettre de méthodes dans le modèle métier.
Mais que mettre comme méthodes dans le M de MVC? Uniquement les méthodes d'accès aux données persistantes (connexion et interrogation d'une base de données par exemple)?
D'après http://fr.wikipedia.org/wiki/Mod%C3%...re_trois_tiers, lors de l'implémentation d'une architecture 3-tiers (présentation, traitement, accès aux données), il est conseillé d'utiliser le MVC pour la couche de présentation.
Donc, si l'on voulait faire un parallèle entre les 2 méthodes, cela donnerait :
- couche présentation <=> vue et contrôleur (V et C de MVC)
- couches traitement et accès aux données <=> modèle (M de MVC)

Êtes-vous d'accord?

Merci par avance.

cc

[ego]

ben non c'est pas ce que j'ai dis.

Dans le cas de l'IHM, les "opérations" du M du MVC c'est un peu, les opérations du C. Le M du MVC n'a pas d'autres opérations que les get/set en général. Et ce M n'a pas d'intelligence métier. Ce M est en général "fabriqué" par le C suite à l'appel des services offerts par la couche métier.

Côté serveur, je reste sur ma position, les "entités métier" ne doivent pas avoir d'autres opérations que des opérations totalement intrinsèques à elles-mêmes. C'est à dire uniquement des opérations qui manipulent les attributs des entités, et rien d'autre. La logique métier est à externaliser dans des classes "traitement"

[nymformaticien]

Ok j'ai compris. Mon erreur était d'essayer de faire un parallèle entre les méthodes MVC et 3-tiers. Elles sont complémentaires mais pas équivalentes.
Les entités de la couche métier du modèle 3-tiers sont en faites indépendantes des données décrites dans la partie modèle du MVC, tout comme les traitements de la couche traitement et les traitements du contrôleur.

Merci.

[ego]

yesssssss

[stephane.06]

bonjour,

je me permet de relancer le débat par rapport au fait de savoir "Où mettre les traitements ?"

Comment architecturer de manière professionnelle son modèle afin de dissocier les objets modèle des traitements ?

J'ai développé un logiciel (il marche mais il est architecturer n'importe comment...) et j'aimerais pouvoir le re-développer en utilisant le pattern MVC.

Dans mon logiciel j'ai des traitements assez important. les méthodes réalisant ces traitement peuvent utiliser un ou plusieurs objet de mon modèle.

Comment alors ranger ces grosses méthodes qui ne font que du traitement dont le résultat permet de mettre à jour les attributs de mes objets modèle ?

Est-ce que créer une classe sans constructeur avec des méthodes static est une bonne solution ?

Heu j'ai une autre question qui est secondaire : dans ma vue j'utilise un JTable et un JTree. Où faut il placer leurs renderers dans le cas d'une architecture MVC ?

je vous remercie d'avance de vos réponses.

[nymformaticien]

Bonjour,

Je ne suis pas un expert, mais je vais essayer de répondre quand même.

MVC, c'est pour structurer (de grosses) applications graphiques (cf. Implémentation du pattern MVC).

Indépendamment de MVC, il souhaitable de séparer les données des traitements. Les différentes réponses d'ego dans cette discussion, ainsi que son article Pourquoi modéliser ? Objets, données, traitements et modélisation, expliquent les avantages de cette séparation.
Pour cela, on peut utiliser les designs patterns. Souplesse et modularité grâce aux Design Patterns constitue une bonne introduction. Pour une séparation précise entre données et traitements, il y est conseillé d'utiliser les patterns Composite et Visitor.

J'espère t'avoir aidé, et de ne pas avoir écrit trop de bêtises.

Les gourous de la conception : vous en pensez quoi ?