Discussion :

[joc02]

Bonjour,

Actuellement nous développons nos logicielles "à l'ancienne". Création de l'interface et mise en place d'évènement et code en même temps.

L'avantage indéniable et le temps de dèv et la compréhension (pour les novices, ou les très anciens )

Depuis quelques temps nous faisons des recherches sur les développements "n'tiers". Du coup nous voyons pas mal de chose sympa. Mais par contre, le niveau de compréhension monte d'un cran (risque de larguer certains collaborateurs), et les temps de développement sont nettement plus élevé.
Nous avons étudié le pattern MVP sans ORM.

Le souci étant également que l'on a un gros existant qui ne pourrait pas être migré en tiers.

Du coup j'en arrive à me demander si, il y a un intérêt (dans mon cas) de faire l'effort de passer quelques dév en n'tiers ? L'infrastructure avant de commencer un dév me parait important pour peu de gain.

[souviron34]

Bonjour

Tu peux déjà lire ces 2 fils ici-même :

Architecture 4 tiers ?

Langage unique libre pour archi 3 tiers ?

Ensuite, pose des questions, nous tâcherons d'y répondre...

[tmanta7]

Nous c'est une entreprise ?

Si c'est le cas ça donne envie de pas postuler chez vous

[souviron34]

Nous c'est une entreprise ?

Si c'est le cas ça donne envie de pas postuler chez vous

Tu postuleras pas dans beaucoup de boites alors...

[pseudocode]

Du coup j'en arrive à me demander si, il y a un intérêt (dans mon cas) de faire l'effort de passer quelques dév en n'tiers ? L'infrastructure avant de commencer un dév me parait important pour peu de gain.

Ce n'est pas évident de faire cohabiter les 2 conceptions "form/action" et "MVP". Il vaut mieux faire tout l'un ou tout l'autre, sauf cas très spécifique où on peut totalement découper l'application en plusieurs parties.

Il y a des avantages a passer en MVP. La question c'est de savoir si ces avantages sont intéressants pour toi.

- La conception "Form/Action" permet une séparation entre l'affichage (aspect statique) et le comportement (aspect dynamique). C'est donc une séparation plutôt technique.

C'est bien adapté pour des applis où chaque écran est fonctionnellement indépendant des autres. C'est à dire que les "actions" n'affectent pas l'affichage des autres écrans. Typiquement, c'est le modèle qu'on utilise pour le web "1.0" (html/css + javascript/php).


- La conception "MVP" permet une séparation entre le rendu (vision utilisateur) et l'information (vision métier). C'est donc une séparation plutôt fonctionnelle.

C'est bien adapté pour des applis où les écrans représentent une même information sous différentes formes. C'est à dire qu'une action d'un écran peut modifier toues les autres écrans. Typiquement, c'est le modèle qu'on utilise pour les applications de monitoring (bourse, scada, ...)

[souviron34]

- La conception "MVP" permet une séparation entre le rendu (vision utilisateur) et l'information (vision métier). C'est donc une séparation plutôt fonctionnelle.

C'est bien adapté pour des applis où les écrans représentent une même information sous différentes formes. C'est à dire qu'une action d'un écran peut modifier toues les autres écrans. Typiquement, c'est le modèle qu'on utilise pour les applications de monitoring (bourse, scada, ...)

J'ajouterais que c'est également bien adapté (comme mentionné dans les posts cités) pour créer un ensemble d'applications ayant une même base fonctionnelle (style se créer un "framework", ou un gros "widget" métier), et aussi lorsqu'on s'attend à avoir différentes "versions" avec le même coeur métier (par exemple divers moteurs de BD, divers formats, divers outils/langages de présentation graphique...)