Discussion :

[Pragmateek]

@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)

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.

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.

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.

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... )

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.

[StringBuilder]

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

[Pragmateek]

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.
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...

[StringBuilder]

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 )

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

[Pragmateek]

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".