Discussion :

[dorra1987]

Bonjour,
J'ai fait qlq recherches sur les architectures logicielles
je m'interesse aux 3 architectures suivtes: MVC,PAC,Arch
Je crois que ARch est trés vieux et on ne travaille pas avec, de plus je pense que le dialogue n'est pas dynamique
Tandis qu'avec MVC et PAC, ils sont dynamiques, appropriés aux systèmes interactifs
mais j'hésite entre les 2

Pour mon application, il s'agit de faire l'adaptation des IHM aux différentes plateformes (par exemple tablettes, iOS, smartphone ...) par une application de gestion de maintenance assistée par ordinateur (GMAO) d'un système de suivi de tableau de bord et déclaration des interventions correctives.
Est ce que vous pourvez m'aidez à choisir quel patern utiliser?

[Luckyluke34]

Bonjour,

MVC (et ses cousins MVP, MVVM, etc.) a aujourd'hui presque totalement éclipsé ses concurrents, d'ailleurs je n'avais jamais entendu parler des deux autres. Il y a des centaines de bibliothèques et frameworks MVC, des milliers de tutoriels, de livres, etc.

Par contre j'hésiterais à le qualifier d'"architecture logicielle", pour moi c'est plutôt un pattern d'interface utilisateur. Attention aux frameworks MVC qui prétendent déterminer voire générer toute l'architecture de l'application très facilement. Pour une appli de taille sérieuse, on peut se retrouver rapidement coincé dans un cadre trop rigide.

[BakSh0]

Bonjour,

En effet MVC à surplombé la plupart des architectures aujourd'hui, cela ne veux surement pas dire qu'il est le meilleur, mais le plus courant .

Attention aux frameworks MVC qui prétendent déterminer voire générer toute l'architecture de l'application très facilement. Pour une appli de taille sérieuse, on peut se retrouver rapidement coincé dans un cadre trop rigide.

Tu peux développer le sujet un petit peu ?

[Luckyluke34]

Tu peux développer le sujet un petit peu ?

Oui, les forums sont remplis de gens initialement séduits par la facilité de "frameworks web" clés en main (Ruby on Rails, Django, etc.) mais qui ensuite veulent faire des choses un peu custom, ou changer leurs options techniques, et sont coincés. Ces frameworks sont très pratiques pour obtenir un site web relativement simple en peu de temps, mais sont assez monolithiques et ne permettent pas de modifier des pans entiers du système facilement. Ils confondent un peu MVC avec une architecture dans le sens où tout est centré sur la partie présentation et intégré autour d'elle. Dans une application complexe et qui va devoir beaucoup évoluer, il est plus judicieux de se concentrer sur le métier et de considérer les autres questions (interface utilisateur, stockage, dialogue avec d'autres systèmes) comme satellites et interchangeables. Dans ce cas de figure, une bonne architecture doit permettre le changement, et non l'empêcher.

http://blog.8thlight.com/uncle-bob/2...hitecture.html

[BakSh0]

Oui, les forums sont remplis de gens initialement séduits par la facilité de "frameworks web" clés en main (Ruby on Rails, Django, etc.) mais qui ensuite veulent faire des choses un peu custom, ou changer leurs options techniques, et sont coincés.

C'est exactement le problème avec certains développeurs d'aujourd'hui je suis d'accord

Dans une application complexe et qui va devoir beaucoup évoluer, il est plus judicieux de se concentrer sur le métier et de considérer les autres questions (interface utilisateur, stockage, dialogue avec d'autres systèmes) comme satellites et interchangeables.

Exact, mais c'est ce qui justifie les nombreux choix de pattern MVC, la gestion séparé du métier d'un coté et de l'affichage et de l'accès aux données de l'autre, indépendamment les uns des autres, les considérant ainsi comme 'satellite et interchangeable' comme tu le souligne.

Ils confondent un peu MVC avec une architecture dans le sens où tout est centré sur la partie présentation et intégré autour d'elle

Pas vraiment d'accord sur ce point Je vois plutôt ce pattern comme 3 des 'satellites' dont tu parle.

Dans ce cas de figure, une bonne architecture doit permettre le changement, et non l'empêcher.

Pour moi je n'y vois pas cette inconvénient, encore une fois tout est question de point de vue.

En tout cas il est intéressant d'échanger sur le sujet.

[dorra1987]

oui tt le monde travaille avec
mvc est un pattern architectural et PAC est un pattern de conception et d implementation
mon application est un etude de cas pour appliquer une approche de conception (je fais de la recherche), donc pour mon cas, elle ne va pas etre de gde taille
mais ce que j'ai trouvé c est que:
PAC est beaucoup plus orienté vers la séparation entre IHM et noyau fonctionnel, donc vers des objectifs de génie logiciel.
MVC est plus focalisé sur l'organisation des entrées et des sorties dans les composants logiciels.
pour moi mon but c'est faire l'adaptation des IHM (suivt ma méthodologie de conception: une approche), donc j'utilise un pattern qui est bcp orienté vers la separation entre ihm et noyau , donc le PAC,
bon c se que je pensais'
j ai trouvé aussi ce lien http://www.developpez.net/forums/d54...cture-mvc-pac/

quel est vos avis

[wiztricks]

Salut,

quel est vos avis

L'interface utilisateur n'est qu'un des composants d'une application: l'IHM.
Avec PAC, c'est Abstraction qui fait l'interface technique avec le reste (appelez cela "noyau"). Avec MVC ce sera le "Model". Dans les deux cas, "Model" et "Abstraction" seront des adaptateurs (au sens du GOF pattern Adaptator) de l'IHM au noyau (qui réalise, entre autres, tout ce qui à trait aux fonctions métiers).
C'est ce qui permet de réaliser plusieurs IHM pour une même application et de choisir différents patterns architecturaux pour les construire.

- W