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