logique des diagrammes de packages, et mvc

Bonjour.
j'utilise le patron de conception MVC pour mon application.
j'ai deux options, mais en fait une seule me semble logique.
soit, je focalise sur le patron mvc, et là j'ai un package metier, un autre traitement et un autre vue(mais là, il va m'etre bien difficile de trouver des relations dans mes packages traitements et vues), soit, je cree un package pour chaque classe de ma classe metier, sachant qu'ainsi le package aura un ensemble de classe en relation(celles provenant du controlleur et du dialogue(vue) de ce package metier).
là encore, je crois que je respecte le patron mvc.
svp, dites moi ce que vous en pensez.

personnellement :
plutot la premiere option, pour un découpage en couches, avec les dependances :
metier (alias domaine) <--- traitements (alias cas d'utilisation) <--- vue (IHM) ---> lib_ihm
avec parfois metier <--- vue (evite de faire beaucoup de delegations).

Alex

Salut,
Une fois que tu as ta classe métier jolie, propre 8-), (c'est bien la raison d'être de ton appli, n'est ca pas ?) Il me semble que il est plus simple de mettre les élements du mvc dans un même package.
C'est donc la deuxième solution.
Par ailleurs si tu veux utiliser un package pour chaque couche, ce qui est plus pratique quand on a par exemple +sieurs vues et/ou controleurs, c'est aussi bien. Il te suffit juste alors de faire des getters et des setters pour les accès. C'est la première solution.

A + .

Je suis d'accord avec ce qui a été dit précédemment. Les deux solutions sont justes, à mon sens. Personnellement je préfère la 1e solution, mais c'est un peu une question de gout.

merci à vous.
j'ai opté pour les deux solutions.
j'explique.
en phase concepetion, j'ai des packages qui prennent en compte le classes metiers, dialogue et controle.ceci pour ne pas me retrouver avec des diagrammes de classe trés volumineux.
mais en phase d'implementation, j'ai un package qui traite de la logique metier, un autre des controles, et enfin celui de la vue.
j'espere que c'est pas trop brouillon.

c'est très bien comme ca, ce n'est pas trop brouillon !

On peut distinguer 3 cas :
1) le modèle de conception "colle" a l'implémentation, on a une relation 1 pour 1 :
dans ce cas on parle de conception détaillée.
2) le modèle de conception est un peut plus abstrait que l'implémentation, on a une relation 1 vers n :
dans ce cas on est plutôt en conception générale.
3) pas de modèle de conception, simplement des règles de conception du modèle d'analyse vers l'implémentation :
dans ce cas, on est en MDA (PIM vers CIM). (bon, d'accord, on a souvent, et même besoins, du modèle de conception entre analyse et implémentation).

Tu est plutôt dans le cas 2 : conception générale.

Remarque :
ces 3 cas sont assez theoriques, mais permettent de comprendre ce que l'on entend en général par 'conception'.

Mieux vaut tard que jamais,

MVC est structurant au sein d'un package dans le sens ou ils distribue des responsabilités dans des classes a forte cohésion (solution 2).
Parcontre la solution 1, faire 3 gros packages, je suis perplexe notament sur certains principes de cohésion des package justement comme CCP (common closure principle).
Quel est le sens d'un package qui consiste à accumuler à l'infini des classes de vues sans rapport entre elles dans le sens ou elles n'ont pas vocations à évoluer ensembles? idems pour les modèles et les controllers.

Merci Gisele pour ta réponse...
Je vais malheureusement fermer le topic...
9a date tellement ....