C# et windows forms?

Salut à tous,

Je voulais vous posez une question à propos du C#,

Ne connaissant rien à la programmation, je voudrais apprendre le langage C#, j'ai acheté un livre.

Je pose cette question car une fois le livre terminé je n'aurais rien appris sur les windows forms alors que c'était dans mes objectifs.

En revanche avez vous un livre à me conseiller qui traite la programmation en windows forms, en partant du principe que j'aurais lu celui que je viens d'acheter avant, ce qui m'aidera beaucoup quand même je pense, sachant que c'est un livre qui est fait pour les personnes sans connaissances qui partent de zéro dans la programmation.

Je vous remercie d'avance bye ;-)

Bonjour #heska77240,

L'erreur de la jeunesse qui ne lit plus, la prochaine fois si possible lis le sommaire . Ce n'est pas un mauvais livre et pour commencer il faut passer par le mode console. Les Winform ou WPF ne sont pas bien compliqués et de bons tutoriels Winform sur le net expliquent leurs fonctionnements.

Salut girakith,

Tout d'abord merci pour ta réponse ;-)

Si tu me dis que pour commencer il faut passer par le mode console sa me rassure, mais je voulais savoir si la console et les Winforms sont deux mondes à part ou bien retrouve ton les mêmes "codes", variables etc....

J'ai hesité à apprendre le C++ mais le C# étant le plus récent j'ai préféré ce choix, mais pour exemple pour apprendre le C++ il traite le sujet des Winforms mais le le C++ est bien plus compliqué que le C#.

L'avantage de bosser en mode console est que les concepts cœurs ne sont pas noyés dans de la tuyauterie graphique donc continue comme ça.

Après pour faire des interfaces graphiques en .Net sache que WinForms est obsolescent depuis quelques années remplacé par WPF dont l'avenir est ... disons incertain. ;)
Mais sur Windows XP/Vista/7 pas le choix c'est WPF et la transition WinRT n'est pas aussi abrupte que de WinForms aux technos XAML.

Après le fait que C# soit plus récent n'en fait pas un meilleur langage, par exemple il est à la ramasse par rapport à du C++ pour faire du calcul haute performance et c'est bien normal ce n'est pas son objectif.
En revanche pour le développement d'applications graphiques couplé avec WPF ou WinRT il est top.

Citation:

---

Envoyé par Pragmateek

L'avantage de bosser en mode console est que les concepts cœurs ne sont pas noyés dans de la tuyauterie graphique donc continue comme ça.

Après pour faire des interfaces graphiques en .Net sache que WinForms est obsolescent depuis quelques années remplacé par WPF dont l'avenir est ... disons incertain. ;)
Mais sur Windows XP/Vista/7 pas le choix c'est WPF et la transition WinRT n'est pas aussi abrupte que de WinForms aux technos XAML.

Après le fait que C# soit plus récent n'en fait pas un meilleur langage, par exemple il est à la ramasse par rapport à du C++ pour faire du calcul haute performance et c'est bien normal ce n'est pas son objectif.
En revanche pour le développement d'applications graphiques couplé avec WPF ou WinRT il est top.

---

Merci Pragmateek,

Très clair et très bien expliqué! Pour être honnête le truc c'est que je n'ai pas vraiment de projets après l'apprentissage de ce language, la seule chose que j'ai en tête c'est de vouloir apprendre un language qui me permettrai de créer des applications ou logiciels, l'objectif premier que j'ai est de créer un crypteur de fichiers.

J'ai entendu que du bien sur le C++, mais apparemment il est très difficile à apprendre c'est pour sa que j'ai choisi le C#, mais j'en suis qu'au début sur l'apprentissage du C#, si le jeu en vaut la chandelle je préférerais me tourner sur le C++........

En tant que connaisseur qu'en penses-tu???

Encore merci pour ton aide ;-)

Dans l'idéal il te faudrait mixer les deux : C++ pour la couche de calcul et C# pour élaborer l'UI en WPF.

Après si c'est purement un projet éducatif tu peux commencer par tout faire en C# en veillant à bien séparer la couche UI de la couche calcul.
Puis une fois cette 1ère version terminée tu réimplémentes la couche calcul en C++ natif.

Ah oui et une "petite" précision : si tu veux une UI portable sur Mac, Linux et Unix oublie WPF qui n'est pas implémenté par Mono (la version multi-plateforme de .Net), tu n'as que WinForms à ta disposition.

Ou faire une application web mais là c'est un autre univers...

Pour la portabilité ce n'est pas un problème pour l'instant seul windows m'interresse, quand tu parle de mixer les deux c'est pour les projets en générale ou pour mon projet de crypteur ?

Sinon étant donné qu'après la lecture de " Apprenez à développer en C# ", je ne saurais rien sur comment programmer avec WPF, as tu un livre à me conseiller ?

Je te cache pas que je suis un peut perdu lol, je ne savais pas qu'on pouvais couplet deux languages.

Commence par bien maîtriser le C# 8-) ou le C++, le gros avantage du C++ est la gestion de la mémoire. Pour exemple de programme mixé tu as Unity que est ultra souple et pourtant c'est une machine de guerre :mouarf:.

La meilleur façon de travailler c'est aussi de travailler en groupe. Un groupe de deux est super pour bachoter un langage (avis personnel). Je ne connais pas spécialement de livre pour le WPF mais la documentation de Microsoft est pour moi assez complète pour commencer à l'utiliser.

> Lien <

Tu as aussi à ta disposition toute l'équipe de Developpez.com pour tes problèmes de conception 8-)

Le mix des langages c'est pour ton projet car la crypto doit se faire le plus rapidement possible.
Ce n'est pas une généralité, la plupart des développements se contentent de .Net/C#.

Cependant mixer est très commun : e.g. en finance les pricers sont la plupart du temps implémentés en C++ pour les perfs et pour les outils de calcul numériques quasi inexistant en .Net/C#, par contre les UIs sont développées en .Net/C# pour la richesse fonctionnelle, la productivité et l'interfaçage aisé avec d'autres outils comme Excel.

Pour chaque besoin il faut le bon outil, il n'existe pas encore de langage/plateforme à large spectre, mais un projet de développement d'une telle bête existe : http://www.red-lang.org/
Je ne sais pas si ça aboutira car c'est très ambitieux et n'apporte pas forcément une grosse valeur ajoutée, la plupart des devs travaillant dans un domaine restreint et l'interop n'étant pas si compliquée que ça quand il faut passer les frontières de chaque langage/plateforme.

Pour WPF en français tu as "Développez des applications riches sous Windows" qui date de 2010 mais est toujours d'actualité vu la faible évolution de WPF depuis.
Le seul truc qu'on peut reprocher à ce livre est l'organisation étrange avec certains sujets avancés au début, et le biais "rendu 2D/3D" de l'auteur.

Pour les livres en anglais (et en général d'ailleurs) le mieux c'est "WPF 4.5 Unleashed" par contre il est très détaillé et se veut exhaustif donc passe beaucoup de temps sur des sujets rarement utilisés voire obsolètes donc il faut savoir faire le tri.

Apprendre le c# juste en mode console me parait légèrement trop axé concepts
c'est bien sur le papier, mais ca doit etre frustrant ^^
enfin au moins tu devrais avoir de bonnes bases

concernant windows forms, il est en effet censé disparaitre depuis une bonne décennie, mais force est de constater que ca reste simple à coder et que ca fonctionne encore sur les windows récents
et quand microsoft abandonne une techo elle marche encore un bout de temps, et une techno si usité je pense qu'on verra venir la fin du fonctionnement
sans parler du fait que si on reste dans l'utilisation du framework, celui peut etre modifié pour ne plus appeler les dll win32 de base (on sait jamais ^^)
(un exe windows forms appelle du code du framework .net qui lui appelle le code des dlls de windows, le framework peut être codé différement sur chaque OS sans que ca ne change le fonctionnement du programme qui s'appuie dessus, c'est le principe d'une machine virtuelle)

wpf est donc un autre mode de gestion graphique d'un exe
il devait être le futur, on voit qu'avec silverlight ca a quand même bien cafouillé, à mon sens il y a eut pas mal de défaut au début, et microsoft bricole des trucs pour qu'on puisse faire des choses complexes avec


pour le choix entre les 2 je te laisse voir, techniquement ils sont vraiment différents, et maitriser l'un n'aide pas à maitriser l'autre, et le code c# à produire derrière n'est pas le même non plus

pour le windows forms, je ne pense pas qu'acheter un livre soit utile, c'est une conception très ancienne et simple à comprendre
il y a une classe (Control) qui représente un controle, celui ci est géré par windows (demande de rendu et autre) et il est rectangle
plein de classes héritent de control, chacune a ses propriétés et une méthode de dessin (méthode paint) (form (une fenetre) hérite de la classe control)
dans la méthode de dessin un bouton dessine un rectangle puis un string, alors qu'un listbox va dessiner plein de string à la suite
quand on modifie une propriété, le redessin et demandé pour ce controle
tous les controles de bases sauf le textbox sont codés en .net
on peut en créer des nouveaux en codant le méthode paint
donc au final on a du code qui modifie des propriétés des controles, et qui répond à des évènements de ceux ci (sur button.click faire que button.enabled passe à false par exemple, puis executer du code d'un traitement (qui peut etre rangé dans une classe quand même))
quand on pose un controle en mode design sur une fenetre, visual studio génère le code qui va avec dans le fichier .designer.cs (button b = new button();b.left = 50;this.controls.add(b);)


pour wpf c'est plus complexe, c'est de conception plus récente
il y a un nouveau langage à balise nommé xaml qui permet de décrire l'interface plutot que de poser les controles sur une fenetre (on peut quand même les poser mais on en perd vite l'habitude)
dans ce langage on décrit à quoi ressemble la fenetre, comment se dessinent les controles (combinaison d'autres controles) et le lien entre les controles et les données
après le code en c# ne fait que traiter des données, normalement on ne modifie aucune propriété des controles directement
par exemple en xaml on écrit que dans un listbox c'est la propriétés "Clients" qui est affiché, qu'un client c'est un label avec le nom du client, un bouton pour le supprimer etc...
quand la propriété nom d'un client change, le listbox est rafraichit (il y a aussi des bindings en winforms, mais moins complets)
et sur le bouton supprimer on dit que ca appelle la méthode "Supprimer" qui se trouve sur la classe client, et là autant qu'en windows forms on écrirait listboxclients.remove(telclient), en wpf, on le supprime juste de notre collection et ca le supprime du controle qui l'affichait
le code c# est donc totalement déconnecté de l'interface, ce qui permet de mieux trier, maintenir et tester le code
quant au rendu, c'est un thread de wpf qui s'en occupe à intervalle régulier, ca utilise DirectX, on peut faire des formes autres que rectangle, et ca gère de la vraie transparence
en bref sur le papier ca parait parfait :D



l'utilité du C++ ce sont les performances, et la portabilité
sur la portabilité il n'y a rien à dire ca permet de développer pour autre chose que windows
pour les perfs, peu de programmes en ont besoin, du C# bien codé reste très performant (et microsoft parle d'un compilateur en code natif pour le C#)

Merci pour tous vos conseils je vais déjà commencé par finir mon livre pour partir sur de bonnes bases et je verrai par la suite.

Merci pour vos explications très clairs ;-)

Si jamais j'ai quelques questions je sais à qui m'adresser ;-) bye

Citation:

---

Envoyé par Pragmateek

Ah oui et une "petite" précision : si tu veux une UI portable sur Mac, Linux et Unix oublie WPF qui n'est pas implémenté par Mono (la version multi-plateforme de .Net), tu n'as que WinForms à ta disposition.

Ou faire une application web mais là c'est un autre univers...

---

Il y a une alternative au WPF avec Mono : Moonlight

Citation:

---

Envoyé par Pol63

pour les perfs, peu de programmes en ont besoin, du C# bien codé reste très performant (et microsoft parle d'un compilateur en code natif pour le C#)

---

J'aurais ajouté "peu de programme pour le grand public en ont besoin", amuse toi à faire un Photoshop, Autocad, SolidWorks en C# ou java, :mouarf: bonjour la machine qui devra faire tourner cette application ! C'est sûr pour FlappyBird... usless.

Attention Moonlight c'est l'implémentation Mono de Silverlight qui est une techno obsolète (j'en sais quelque chose ayant été "victime" de ce couac :/).

Pour info l'implémentation de WPF prévue par Mono se nommait le projet Olive mais vu la complexité du bousin ça n'a jamais été implémenté et ça ne le sera jamais puisque désormais l'avenir de WPF est incertain avec l'arrivée de WinRT.

Citation:

---

Envoyé par girakith

J'aurais ajouté "peu de programme pour le grand public en ont besoin", amuse toi à faire un Photoshop, Autocad, SolidWorks en C# ou java, :mouarf: bonjour la machine qui devra faire tourner cette application ! C'est sûr pour FlappyBird... usless.

---

c'est pas vraiment une question de grand public, mais c'est vrai que dans ce que tu cites, en c# ca n'ira pas trop ^^
il y a bien paint.net, mais ce n'est pas photoshop et la dernière version prend déjà 30% de mon i7 à rien faire !

nous on fait des applications de supervision industrielle en .net avec des tas de données et des tas de routines à exécuter ca reste très performant


@Pragmateek
winrt n'est pas un genre de wpf ? wpf sera abandonné ?
je ne fais trop de wpf, j'attends le prochain langage ^^ mais j'ai cru comprendre que même si ce n'est pas wpf qui reste ca sera du xaml, donc assez proche dans la logique et la syntaxe
je me trompe peut être mais je pense que wpf n'a pas été très adopté, ce qui me fait penser qu'il pourrait être remplacé rapidement et/ou facilement ...

Citation:

---

Envoyé par girakith

J'aurais ajouté "peu de programme pour le grand public en ont besoin", amuse toi à faire un Photoshop, Autocad, SolidWorks en C# ou java, :mouarf: bonjour la machine qui devra faire tourner cette application !

---

Bof. Très franchement je ne vois pas pourquoi C# ou Java seraient inadaptés à ce genre de programme. Oui ce sera un peu plus lent. Un peu. Pas beaucoup. Et ça pourrait même être plus rapide si les gains de productivité et de sécurité permettent de se concentrer sur des optimisations de haut niveau et la parallélisation (le nouveau compilateur C# écrit en C# est par exemple plus rapide que l'ancien en C++).

Je n'ai notamment aucun doute concernant la faisabilité d'un Photoshop en C#, aucun problème. Je suis un peu plus hésitant sur la 3D à cause des accès aléatoires de tableaux mais pas beaucoup plus.

Au pire, si c'est parce que tu as besoin de quelques instructions assembleur vectorielles, tu crées 1% du programme en C/asm et basta.

Citation:

---

Envoyé par DonQuiche

Bof. Très franchement je ne vois pas pourquoi C# ou Java seraient inadaptés à ce genre de programme. Oui ce sera un peu plus lent. Un peu. Pas beaucoup.

---

Je n'est pas dit que l'application serait lente mais que le matériel pour utiliser l'application devra être plus évolués.

Citation:

---

Envoyé par DonQuiche

le nouveau compilateur C# écrit en C# est par exemple plus rapide que l'ancien en C++

---

Tu peux me donner les compilateurs que tu prends pour référence dans ton argument ? GCC, Gtk# ?

Citation:

---

Envoyé par DonQuiche

Et ça pourrait même être plus rapide si les gains de productivité et de sécurité permettent de se concentrer sur des optimisations de haut niveau et la parallélisation

---

Dans le framework .NET il y a un moyen de rendre plus rapide ton application au détriment de sa portabilité sur d'autres plateformes.

Citation:

---

Envoyé par girakith

Je n'est pas dit que l'application serait lente mais que le matériel pour utiliser l'application devra être plus évolués.

---

Cela revient au même, à quelques détails près.

Citation:

---

Tu peux me donner les compilateurs que tu prends pour référence dans ton argument ? GCC, Gtk# ?

---

Je faisais référence au précédent compilateur C# qui était écrit en C++, et qui a été remplacé par un nouveau compilateur C# écrit en C#. D'après MS leur nouveau compilo est significativement plus rapide parce qu'ils ont opté pour un design plus propre et très parallélisable, avec beaucoup de données immuables.

Citation:

---

Dans le framework .NET il y a un moyen de rendre plus rapide ton application au détriment de sa portabilité sur d'autres plateformes. <

---

Non, il n'y a pas de gain de vitesse avec ça, le compilateur est le même que le compilateur JIT et cela ne fait qu'accélérer les futurs démarrages puisqu'il ne sera pas nécessaire de recompiler. Accessoirement tu peux très bien faire cette opération sur la machine du client, à l'installation.

Si tu veux un vrai compilateur AOT il faut se tourner du côté de dotnet native qui n'est pour l'instant utilisable que pour les applis windows store. Et si les gains sont appréciables (30%) cela ne se substituera certainement pas à un code optimisé et parallèle : c'est toujours au codeur de faire le gros du boulot.

Citation:

---

Envoyé par Pol63

@Pragmateek
winrt n'est pas un genre de wpf ? wpf sera abandonné ?
je ne fais trop de wpf, j'attends le prochain langage ^^ mais j'ai cru comprendre que même si ce n'est pas wpf qui reste ca sera du xaml, donc assez proche dans la logique et la syntaxe
je me trompe peut être mais je pense que wpf n'a pas été très adopté, ce qui me fait penser qu'il pourrait être remplacé rapidement et/ou facilement ...

---

WinRT emprunte beaucoup de choses à WPF et Silverlight (XAML, liaison de données, MVVM, templates...) mais ça reste un environnement très différent de .Net, et même ce qui est commun n'est pas identique.
Donc la transition depuis WPF n'est pas monstrueuse mais il faut souvent apprendre à faire avec moins.
Cependant WinRT n'est pas encore stabilisé et reste un work-in-progress comme le montrent les nombreuses hésitations avec des composants abandonnés, mais je pense qu'on a atteint la phase de bêta depuis la 8.1, et pê que la version pour Windows 9 sera enfin assez complète pour être qualifiée de version finale, wait and see...

Il est vrai que l'adoption de WPF a été assez lente et qu'il s'est retrouvé victime d'un effet ciseau :
- d'un côté les développeurs à l'aise avec WinForms impressionnés par ce gros morceau ont mis beaucoup de temps à l'adopter, le FUD de certains n'ayant rien arrangé, faisant même croire que WPF était plus complexe que WinForms alors qu'il est juste plus riche, et rien n'empêche de faire du WPF à la WinForms
- de l'autre côté le changement de stratégie de Microsoft, notamment en raison de tensions politiques internes, certains voulant la peau de .Net (Steven Sinofsky finalement débarqué fin 2012) et l'ayant à priori obtenue en ce qui concerne le client (WinRT reposant sur COM directement et pas sur .Net), tensions sûrement associées à de véritables contraintes techniques, qui ont coupées net les perspectives de WPF.

Après WPF reste parfaitement viable et même incontournable si tu cibles Windows 7 mais il n'est plus une technologie d'avenir.

Je prépare un article sur mon blog concernant ce sujet ô combien épineux, mais pas eu le temps de le poser. :)

Pour en revenir au début du sujet, il faut savoir que la GUI, que ce soit ASP.NET, WinForms, WCF, WPF, ou Console, ou je ne sais quoi d'autre n'impacte qu'une faible partie du code d'une application.

Bon, après, si on code une application purement GUI (jeu par exemple) évidement, la partie impactée est plus grande.

En C#, comme dans tous les langages, on travaille par modules, et 99% du code est présent dans des classes qui n'ont rien à voir avec la GUI. Tout comme elles n'ont rien à voir avec le SGBD utilisé ou la résolution de l'écran !

Donc pour apprendre le langage à proprement parler, le mode Console est tout aussi complet et efficace que n'importe quel autre type de projet.

Si tu maîtrises les mécanismes de C#, alors le portage d'une application de Console à WinForms, WCF, WPF ou même ASP.NET n'est qu'une simple formalité (à quelques détails quand même, il faut l'avouer).

Sinon, j'ai envie de rebondir sur les problèmes de performance de C# par rapport à C++, mais aussi sur la gestion mémoire...

C# est comme tous les langages (y compris les "plus mauvais") : si le développeur fait de la merde, il fera de la merde. Si le développeur optimise ses algos et son code, en maîtrisant les mécanismes du langage, alors le programme sera rapide et peu gourmand.

Autant C++ permet d'aller encore plus loin dans l'optimisation (et encore, ça dépend des domaines, mais à ce moment, autant proposer de faire directement de l'assembleur), autant C++ permet de faire en 2 lignes des fuites mémoires catastrophiques aussi, qu'il serait impossible à faire en C#.

Alors après, quand un développeur fait des concaténations de string à grand coup d'opérateur "+", qu'il vienne pas chialer que C# est lent... Avec StringBuilder (hihi c'est moi) les performances de C# sont identiques à celles du C++ alors bon...

@StringBuilder : autant je suis d'accord sur la 2ème partie concernant les performances, autant je suis complètement en désaccord sur le reste :) (+1 quand même)

Citation:

---

Pour en revenir au début du sujet, il faut savoir que la GUI, que ce soit ASP.NET, WinForms, WCF, WPF, ou Console, ou je ne sais quoi d'autre n'impacte qu'une faible partie du code d'une application.

---

Malheureusement d'expérience (HTML/CSS/JS, Flex, ASP.NET WebForms, ASP.Net MVC, WinForms, WPF, Silverlight, Excel, Swing...) la GUI représente une grosse partie du code ET une grosse partie du temps de développement.
Après tout dépend de ton contexte : bien sûr si tu as une partie métier très riche et complexe (pricing sur une ferme) et des besoins visuels réduits (quelques indicateurs) alors oui tu peux avoir du 99% - 1%.
Mais pour une application LOB (Line Of Business) comme une interface de trading, même si la partie métier est riche et complexe (pricing, risque, passage d'ordre...) l'interface affiche énormément de données en temps réel et en récupère beaucoup de l'utilisateur donc là tu passes la majorité du temps dans la partie UI/logique applicative.

Citation:

---

Bon, après, si on code une application purement GUI (jeu par exemple) évidement, la partie impactée est plus grande.

---

Un jeu non trivial n'est jamais purement GUI il faut souvent un moteur physique et une IA, donc au global tu développes autant du code non visuel.
Après si tu prends tout packagé c'est une autre histoire mais même l'intégration n'est pas forcément triviale.

Citation:

---

En C#, comme dans tous les langages, on travaille par modules, et 99% du code est présent dans des classes qui n'ont rien à voir avec la GUI. Tout comme elles n'ont rien à voir avec le SGBD utilisé ou la résolution de l'écran !

---

Tout dépend des applis : j'ai eu à développer de simples vues sur des tables SQL donc là 99% du code c'est du visuel, le reste c'est un simple DataReader.

Citation:

---

Donc pour apprendre le langage à proprement parler, le mode Console est tout aussi complet et efficace que n'importe quel autre type de projet.

---

Oui pour le langage mais sans savoir présenter les données tu ne sais faire que disons 50% de ce qui est demandé par le marché du développement.
Il y a bien sûr quelques devs qui ne verront jamais une GUI mais la plupart devront en développer, même des basiques et même si la personne n'est pas un dev : e.g. j'en ai connu un qui s'était fait une petite GUI PHP pour faciliter son administration SVN !
Donc c'est incontournable, ce n'est pas pour rien que la grande majorité des offres de dev demande un framework de GUI comme compétence (l'autre raison c'est l'incompétence de personnes pour qui WPF = VS = .Net = C# ~= Java = SWING... :))

Citation:

---

Si tu maîtrises les mécanismes de C#, alors le portage d'une application de Console à WinForms, WCF, WPF ou même ASP.NET n'est qu'une simple formalité (à quelques détails quand même, il faut l'avouer).

---

Si seulement :( pour avoir fait des migrations de WinForms à WPF, de Excel à WPF et même entre Silverlight et WPF je peux t'assurer que c'est très loin d'être une formalité : l'architecture globale change, les composants visuels (rendu des données et mise en page) sont différents dans leur structure et leur comportement, sans parler des façons différentes d'aborder une même problèmatique.
Développer une GUI "lourde" n'a pas grand chose à voir avec développer une appli web "classique" qui est très différent de développer une appli web SPA.

Je suis d'accord si le GUI prend le pas sur le développement.

Mais pour ne citer que mon expérience (qui n'est en rien sur du C#, mais cela pourrait tout aussi bien en être), je travaille depuis... près de 20 ans sur un ERP, Generix Collaborative Entreprise pour ne pas le citer.

Le code est écrit en Java (et C pour quelques traitements serveur qui n'ont pas encore été portés en Java).

La GUI, c'est de la simple transformation XSLT sur un flux de données XML. Pas une ligne de développement Java.
Il s'agit pourtant d'un ERP tout ce qu'il y a de plus complet, donc avec des flux et des présentations de données relativement complexes. Et pour ce faire, on n'a accès qu'à du XSLT et de l'Ajax (qui récupère lui aussi des données mises en forme selon la même méthode).

C'est pour ça que j'ai tendance à vraiment séparer la GUI des traitements à proprement parler (c'est d'ailleurs le principe du MVC).

Sur cet outils, le GUI est absolument totalement séparée du moteur lui-même. Les développeurs de l'éditeur qui écrivent les objets Java ne s'occupent pas une demi-seconde de la GUI, et ceux qui travaillent sur la GUI n'ont absolument pas accès au source des programmes Java, juste à la doc pour savoir comment les appeler depuis les feuilles XSLT.

Et pour tous mes projets C#, qu'ils soient persos ou pros, j'ai toujours un pauvre EXE à deux balles qui s'occupe purement de la GUI, et une ou plusieurs DLL qui contiennent 100% du "code" à proprement parler.

Alors après, effectivement, s'il y a beaucoup de mise en forme, des effets visuels à mettre en place et autres, effectivement, la GUI représente une grosse partie du code.

Et quand on développement de cette manière, on se retrouve souvent à partager la même DLL entre la verson Web et la version WinForms... Alors après, il y a surtout des notions de synchrone/asynchrone mais aussi de contexte, qu'on ne gérera pas de la même manière entre un WebService, un site Web ou une application lourde. Mais à nouveau, mise à part pour quelques traitements spécifiques, c'est souvent le même code qui est réutilisable. Je vais même aller plus loin... Il y a quelques temps, j'ai écrit une DLL qui permet, à partir d'une adresse, de requêter Google Maps, récupérer l'adresse "propre" et les coordonnées GPS. Cette DLL est en exploitation dans 3 applications différentes à l'heure actuelle :
- une application Windows Forms
- un site web
- un trigger CLR dans une base SQL Server

Pour le partage du code métier oui ça c'est incontournable sinon en effet on refait 100% à chaque fois.
Là on ne refait que la GUI donc une plus ou moins grosse partie : de 1 à 99%. :)

Ton expérience est très intéressante, j'avais déjà entendu parlé de bousins basés sur XSLT. :aie:
J'imagine que ça a été conçu à une époque lointaine où la mode était au tout XML. (j'en ai abusé aussi...)

Et l'AJAX ça me fait fortement penser à des SPAs qui deviennent très à la mode et pour de bonnes raisons je pense, surtout avec le tooling disponible désormais (AngularJS pour ne citer que le "meilleur").
Mais du coup le backend doit être plus dans une approche web-service léger désormais j'imagine, ce qui s'oppose à la génération de vues via XSLT (sauf pour des "vues" de données) ?
J'ai l'impression qu'il y a conflit générationnel : les petits jeunes en mode AJAX "migrant" ni vu ni connu le monstre XSLT... ;)

Non non, y'a surtout des gens qui ont été très mal conseillés (à la base, l'ERP fonctionnait en mode 80 colonne par TELNET).

Du coup ils ont fait une... heu... j'ai pas le droit de cracher sur mon gagne pain... donc... une chose, qui était très lente et vraiment pas ergonomique.

Et vu que ce sont les clients qui customisent leur GUI à grand coup de XSLT sur lesquels ils ont la main, on leur a soufflé que l'Ajax c'était mieux que de recharger des frames (sisi, en 2014, ils continuent à utiliser des frames :D)

Mais l'Ajax ne se base pas sur des WebServices... Non non non, c'est juste qu'ils chargent un XSLT qui transforme du XML... en XML... Et vogue la galère :aie:

C'est un 1er pas, le pied est dans la porte :), c'est le plus important, ça permet de commencer à capitaliser sur une expertise technique "moderne" avant d'envisager une migration à proprement parler au fil de l'eau module par module.

Après si le client a lui-même ses propres personnalisations ça va en effet être plus délicat de lui retirer ou changer son jouet. ;)

En tout cas c'est une belle illustration de ce qu'on appelle un choix "structurant". :mrgreen: