Episode 7 : Mathias découvre Unity+WPF+MVVM aux Techdays 2010

Je vous ai parlé de ma découverte de .Net dans l’épisode 6.
J’ai constaté un gros contraste avec Java: j’avais l’impression que Java était compliqué (EJB et tout ça) et que .Net était simple.

Cette simplicité n’est pas toujours positive, on peut même dire que Microsoft est "maudit" par ce fléau: rester attractif pour les développeurs débutants.

En général, cela donne des frameworks "sales" avec un fort couplage du code métier avec les interfaces, impossible à tester unitairement bien sûr.

Pour pouvoir découpler tout cela, on distingue 3 couches:

  • L’interface, appelée "view" ou "presenter", c’est le moyen d’afficher l’information
  • La logique métier, appelée "model", c’est ce que l’on va pouvoir tester à l’aide de tests unitaires
  • Les actions ou commandes, qui représente une action de l’interface par l’utilisateur qui va déclencher un traitement

Mais quand on sépare les responsabilités en plusieurs objets, on se retrouve avec un nouveau problème : comment coupler les vues, contrôleurs, etc. ? Comment "broker" les actions ?

Il y a une solution à cela: l’IOC. On peut dire aussi que le Databinding en est une autre.
Si Microsoft avait un train de retard sur les Framework IOC, ils connaissaient néanmoins déjà le problème depuis un moment, puisqu’ils l’avaient en partie résolu dans CAB.
C’est donc sans surprise que Microsoft nous livre son framework d’IOC "officiel" basé sur l’existant de CAB : Unity.

A la sortie d’Unity, j’étais déjà tellement convaincu par Spring.net que je n’ai jamais adopté le framework de Microsoft. De plus, les alternatives OpenSources étaient  bien présentes: Castle Windsor, Ninject, Autofac, etc.

A noter que les framework tel que CAB/RCP rendent vos clients lourds "extensibles", ce qui veut dire qu’un plugin va pouvoir greffer de "vues" dans l’interface, et s’abonner aux "commandes": chose tout à fait faisable avec de l’IOC.

Mais les frameworks IOC ne font pas tout, et ne suffisent pas à fournir une véritable architecture MVC pour client lourd, même s’ils peuvent nous y aider (voir mon poste précédent).

Pour résoudre le fléau du couplage fort entre l’interface et le code métier, Microsoft a sortie quelque chose de révolutionnaire: WPF et Silverlight!
Avec la venue de WPF et Silverlight, la communauté .Net OpenSource a commencé à se pencher alors sur le problème du MVC pour les applications lourdes. Divers frameworks apparaissent alors, comme Prism: http://compositewpf.codeplex.com/

Mais le MVC, comme on le connait dans le monde Web, ne s’applique pas bien aux clients lourds, surtout si on veut exploiter le Databinding et les événements.

Très franchement, je ne me suis jamais vraiment passionné pour WPF/Prism/etc. mais je voyais bien que quelque chose de gros était en train de venir…
J’ai ensuite assisté aux Techdays 2010 et j’en ai profité pour me mettre à jours sur le sujet.
Les sessions étaient d’ailleurs très accès sur Silverlight/WPF mais aussi sur le nouveau modèle MVVM (Model-View-ViewModel), et avec une bonne dose d’Unity bien sûr…
J’ai alors été très agréablement surpris par ces présentations, surtout celle qui montre comment supprimer tout le « code behind » des interfaces XAML avec des ViewModel et des Commands.

Pour mieux comprendre de quoi je parle, aller voir vite le screencast ici!!!

Bref, je ne sais pas si vous me suivez, mais l’IOC, le RCP, le MVC, la gestion de plugins, tout ça c’est intimement lié !

Petit à petit, .Net rattrape le retard vis-à-vis d’Eclipse RCP !
On peut même dire que .Net a pris de l’avance avec Silverlight/WPF, puisque la rédaction des interfaces en XML n’est qu’au stade de proposition pour Eclipse 4: http://wiki.eclipse.org/images/a/ab/XWT.pdf

Episode 6: Mathias découvre .Net!

En fait, je triche, les épisodes ne sont pas dans l’ordre chronologique.
Je n’ai pas découvert .Net après Java, mais en même temps.

C’était le 6 Janvier 2005, j avais blogué à ce sujet: j’avais découvert qu’avec Mono, il était possible d’exécuter un même programme EXE sous Windows comme sous Linux ! J’en avais la larme à l’œil…

Ce qui m’a le plus impressionné c’était de voir qu’il était possible d’exécuter du Java dans .Net grâce à IKVM ! Cela marchait tellement bien qu’ils ont réussi à exécuter Eclipse sous .Net ! Mais ce n’était qu’expérimental à l’époque…

En découvrant .Net, j’ai tout de suite pris conscience du retard par rapport à Java, et j’ai alors voulu m’y atteler.
J’ai alors commencé à réaliser un framework « RCP » comme celui d’Eclipse, mais full .Net. Voici le résultat à l’époque :

On pouvait réaliser des plugins qui fournissent des vues qui s’encrent dans différents endroits, que ce soit dans la fenêtre principale ou dans un onglet d’édition.
J’en était plutôt fier, encore aujourd’hui… j’ai bien envie de le porter avec les technos modernes d’aujourd’hui…

C’est aussi à cette époque que j’ai découvert Spring, et au même titre Spring.Net, que j’ai utilisé dans mon entreprise pour réaliser, avec Romain, un framework MVC Winforms.

J’ai aussi découvert d’autres framework IOC, et par la même occasion CAB de Microsoft (Composite Application Bloc), mais sans en être convaincu.

A l’époque, on commençait à parler d’OSGI, mais je n’avais pas assez de connaissance dans le domaine

En conclusion, je restais sur ma fin avec .Net, et j’en étais même frustré. Mais j’ai toujours été convaincu que c’était aussi "une terre d’opportunités" et que je pouvais faire quelque chose…
L’IOC, le MVC pour client riche, RCP, OSGI… les idées émergeaient déjà, mais n’était pas matures.

Episode 3 : Mathias découvre Eclipse (et un peu OSGI)

Dans l’épisode 2, je vous ai dit à quel point les serveurs J2EE pouvaient être complexe dans la gestion d’application.
Il en est de même dans le monde des IDE avec la gestion des plugins.

Tout en étudiant J2EE, je suis tombé amoureux de mon IDE Java préféré : Eclipse. Pas seulement pour sont utilisation, mais aussi pour son architecture.

En effet, la réalisation de plugins pour Eclipse se fait de manière ultra puissante. A tel point que le « noyau » d’Eclipse peut être complètement extrait pour faire sa propre application qui n’a rien à voir avec un IDE : c’est le framework RCP (Rich Client Platform).
J’ai d’ailleurs à l’époque réalisé une application RCP pour la gestion de budget d’achat de livres pour les bibliothèques.

Malheureusement, la pauvreté des composants graphique en Java faisait du tors à cette plateforme.
Mais je restais subjugué par le moteur de plugins :

  • Les plugins sont isolés afin que si un plugin crash, les autres continuent leur vie
  • Les plugins sont aussi isolé coté sécurité : un plugin ne peut pas accéder aux codes d’un autre plugin si ce dernier ne l’a pas explicitement rendu « publique »
  • Les plugins peuvent publier et consommer des services, avec un model très élégant
  • Il y a une gestion de dépendance entre les plugins, avec la prise en compte des versions
  • L’installation et la mise à jour des plugins se fait d’une simplicité déconcertante

En fait, si la gestion des plugins est si balaise c’est car elle provient d’un standard de « développement par composant » : OSGI.

L’alliance OSGI est un organisme de personnes qui se mette d’accord ensemble sur des specs concernant les frameworks OSGI. C’est encore la que Java écrase .Net par sa maturité : il n’y a pas de monopole, il y a bien plusieurs acteurs derrière un « standard » ouvert qui va connaitre de multiples implémentations.

OSGI est donc un framework complexe de gestion de « modules » qui exposent des « services ». N’hésitez pas à lire le WIKI qui explique ça très bien : http://en.wikipedia.org/wiki/OSGi

En conclusion, Eclipse est une plateforme riche en plugins grâce au coté Open-Source de l’IDE, à l’API de plugins très bien faite mais aussi à l’aide du plugins pour développer des plugins :)

Qu’en est-il du coté .Net? VisualStudio a-t-il le même succès concernant le développement ce plugins? Offre-t-il une architecture de plugin aussi puissante? On verra ça dans un autre épisode ;)

Cloud computing

OK, je ne suis pas original, je parle d’un sujet "dans le vent" : le Cloud Computing

Cloud Computing: introduction avec Azure et Amazon

Grâce à la présentation chez Fastconnect par Romain, j’ai pu découvrir les joies de Azure. C’est la solution Cloud de Microsoft qui est bien sûr très orientée .Net + VisualStudio.

On parle ici de "Plateform as a Service" puisque Azure nous offre de quoi héberger nos applications (web ou service) à l’aide d’une architecture "cloud".
On développe des applications qui effectuent des calcules distribués sur X machines, ou on héberge X sites web ASP.Net dont la charge est répartie entre eux.
En plus d’offrir une architecture "scalable", on a droit à certains services "bas niveau" comme le service de stockage de données binaires (full REST), une queue ou un stockage "à la BigTable". On peut ensuite bénéficier de services plus "haut niveau" comme "Live Search" ou "Live Calendar".

Par comparaison, Amazon avec EC2 propose un service "Cloud" orienté "Hardware as a Service" car on loue ici à des machines virtuelles, vierges ou avec des choses pré-installé (comme Linux Apache Msql PHP). La puissance de ces machines est aussi "scalable" à la demande, et on ne paie que ce que l’on utilise.
A la différence d’Azure, où la partie "Hardware" est complètement masquée (IIS7, WindowsServer2008, etc.). Azure offre une interface web d’administration pour surveiller l’utilisation du CPU ou de la mémoire, et on peut rapidement changer le nombre d’instances d’un site web à la demande.
Ceci dit, Amazon offre aussi des couches techniques comme le service de stockage Amazon S3.

Bref, le Cloud ce n’est pas qu’un hébergeur de site web ou une Dedibox, c’est surtout le fait de bénéficier des serveurs des gros mastodontes tel qu’Amazon ou Microsoft pour louer la puissance dont on a besoin, et profiter d’applications et de services pré-installés utilisables tout de suite. C’est aussi la possibilité d’utiliser des services techniques (Database, etc.) ou haut niveaux (Map, Calendar, etc.).

Nouvelle solution de Cloud avec Aptana

Azure offre de quoi développer un site ASP.Net Scalable rapidement, mais je vais faire le chieur en voulant développer une application Rails sous Eclipse!

C’est la que j’ai découvert Aptana Cloud.
Lire la suite

Eclipse Vista

Juste parceque les gens adorent les screenshots :
Eclipse sous Vista Beta 2.

EclipseVista2

Suivre

Recevez les nouvelles publications par mail.