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 4 : Mathias découvre Spring (et un peu plus OSGI)

Dans l’Episode 2, je vous ai parlé de ma découverte de J2EE.
Si j’ai été émerveillé par la plateforme, j’avoue qu’elle était assez complexe.

C’est alors que la lourdeur des framework J2EE a donné naissance à une alternative qui s’est voulu plus simple : Spring.

J’aime bien Spring, je pense que vous le savez déjà :)
C’est pour moi en quelque sorte l’équivalent de l’esprit d’ALT.Net, mais en Java.

Ce fut alors la mode des IOC, et de l’approche orienté POJO. Quand j’ai découvert cela, je me suis rendu compte à quel point le framework d’Eclipse RCP pouvait être compliqué…
La gestion de dépendance et de publication/consommation de service devenaient extrêmement simple.

La ou Spring n’était qu’un framework, « SpringSource DM Server » est, quand à lui, un vrai serveur J2EE mais avec une architecture complètement différente de ses concurrents : il est basé sur le même moteur OSGI qu’Eclipse !

L’installation de nouvelles applications vous semble pénible ? SpringSource DM Server offre un « AppStore » pour installer un nouveau service et ses dépendances en 2 cliques!

Pour ceux qui ont lu mon billet sur WebMatrix, la fonctionnalité n’est pas tout à fait la même que c’elle du produit Microsoft.Vous pouvez ici installer bien d’autres choses que des applications Web: des ESB, des serveurs Web (car oui, en Java, on a le choix entre Tomcat, Jetty et autres), etc.
Vous voulez installer un serveur de Messaging ? Installer ActiveMQ en quelques cliques : http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.activemq&version=5.3.0

Vous trouvez plus d’infos sur http://www.springsource.com/products/dmserver/repository


En plus de tout ces avantages, SpringSource DM Serveur offre un interface d’administration d’un pure merveille, j’en bave quand je vois que Microsoft reste attaché à sa MMC…
Et comme si ça ne suffisait pas, SpringSource ont racheté Hyperic qui est une appli Web de Monitoring applicatif, ce qui rend l’administration de votre serveur  encore plus professionnel.

Petite conclusion:

  • l’IOC c’est cool, vive l’approche POJO
  • OSGI c’est de la bombe. Cela permet aussi bien de gérer des plugins dans un IDE, que des middleware dans un serveur d’applications
  • l’installation d’une plateforme applicative doit être simple et facile, autant que de lancer un Setup de EasyPHP ou de cliquer sur un lien d’un "AppStore"
  • vive les interfaces Web d’administration, à mort la MMC

GUICE : un framework de DI pour Java

Je pense que la Dependency Injection est une valeur fondamentale à l’écriture d’un programme, et je l’utilise tous les jours.
Je suis un adorateur (voir expert) de Spring/Spring.Net, et j’affectionne l’écriture de la structure du programme en XML.

Mais cette technique est très largement contestée :

  • nécessite un éditeur XML "intelligent" (ce qui est le cas grâce à SpringIDE) pour la complétion de la structure mais aussi des types.
  • interprétation au Runtime, et donc erreurs potentielles découvertes qu’au dernier moment.
  • verbeux
  • mauvaises performance (lecture du XML…)

Ça a aussi ses avantages, c’est pour ça que je reste adorateur de Spring, mais ce n’est pas le sujet…

J’ai déjà souvent eu ce débat avec Romain dans le monde .Net (voir http://ninject.org).
Je connais très mal les alternatives à Spring dans le monde Java, mais je connais celle de Google : Guice.

Voici un tuto/introduction très convaincante.

Pour ceux qui ne connaissent pas Ninject ou Guice, voici un peu le principe :
Au lieu de rédiger un XML, on utilise massivement les annotations (attributs en .Net) pour spécifier les injections. Ceci est aussi possible en Spring (technique dite Autowire) mais l’utilisation du XML reste nécessaire pour personnaliser plus finement les dépendances entre instances.
Dans le cas de Guice, au lieu de rédiger un XML, on créer une classe Module qui réalise le mapping entre une interface et la classe concrète à instancier/injecter.
On peut spécifier bien plus de chose que cela, mais je vous laisse lire l’article pour découvrir par vous même.

Pour ceux qui veulent suivre le débat "Spring vs Guice" ou "XML vs Code", voici le point de vue de la documentation officielle de Guice.

Suivre

Recevez les nouvelles publications par mail.