Avec la sortie vendredi dernier de la beta 2 de Silverlight 2.0, la convergence WPF / Silverlight se fait plus nette :
Contrôles
Les contrôles les plus fréquemment utilisés (boutons, boites de listes, etc.) sont inclus dans Silverlight plutôt que de faire partie d'assemblées supplémentaires;
De nouveaux contrôles (DataGrid, Calendar) sont disponibles sous formes d'assemblées supplémentaires comme dans la beta 1;
Templates
Enfin, les impressionnantes fonctionnalités de templating de WPF sont en partie intégrées à Silverlight et exploitables depuis Blend (Expression Blend 2.5 June Preview)
Les templates décrivent non seulement la hiérarchie d'objet contenus dans un contrôle mais aussi le comportement en réponse aux actions de l'utilisateur.
Un nouveau concept de VSM (Visual State Manager) qui facilite la gestion des états des contrôles est introduit dans Silverlight 2.0. Il sera ultérieurement ajouté à WPF.
UI Automation.
Comme pour WPF, Silverlight autorise l'automatisation des tests des interfaces graphique grâce au framework d'UI Automation
Compatibilité avec WPF
Les APIs Silverlight et WPF convergent. Ouf.
Media
Streaming adaptatif. Une application Silverlight peut choisir parmi plusieurs encodages en fonction des conditions du réseau.
DRM. Inclus dans Silverlight beta 2.
Réseau
Echanges cross-domains. Un fichier XML à déposer sur le serveur de destination de la requête sera lu par Silverlight. Les fichiers destinés à Flash sont compatibles.
Serveur push. Le mode Duplex Communication permet à Silvelight d'être notifié par le serveur plutôt que de l'interroger régulièrement (pull).
Silverlight supporte JSON et les services REST
Data
Silverlight inclut Linq to JSON. Cool.
Binding : enrichissement du data binding, avec en particulier la venue du binding sur les propriétés attachées.
Stockage local : 1Mo par défaut, extensible par l'utilisateur via le menu contextuel "Configuration Silverlight".
Hibernate et son cousin .Net NHibernate souffrent d’un handicap qui nuit à leur réputation. Dès 2006 Sami Jaber constatait que les premiers retours terrain étaient plutôt désastreux : "[...] des requêtes SQL générées de 70 pages imprimées (véridique), parfois 300 ou 400 requêtes par formulaires et des DBA qui crient au scandale".
Implicit Lazy loading
Le lazy loading implicite (littéralement "chargement paresseux") mis en œuvre par (N)Hibernate est en grande partie responsable de cette notoriété reprochable. Typiquement en lazy loading, un objet (disons client) dont les propriétés ont été renseignées par NHibernate verra ses objets associés (disons client.Commandes) initialisés paresseusement par une requête SQL, c'est-à-dire seulement quand nécessaire et si nécessaire.
Lazy road crossing. Rien à voir. Désolé.
Jusque là tout va bien, le lazy loading c'est plutôt bien pour éviter que toute la base de données ne se retrouve en mémoire par le biais de plusieurs associations.
Le hic, c'est que toute cette mécanique de requêtage automatique de la base de données se produit implicitement, presque à l'insu du développeur. Par exemple si le développeur doit écrire une itération sur tous les client.Commandes pour calculer le total des commandes, il écrira une boucle foreach (Commande commande in client.Commandes), et NHibernate va silencieusement générer et exécuter autant de requêtes SQL que de commandes associées à cet objet client. 150 commandes ? 150 requêtes envoyées une-à-une à la base de données...
D'un côté c'est génial parce que le développeur peut manipuler des objets C# purs et durs en ignorant qu'une base de données est à l'œuvre derrière le décor, orchestrée par NHibernate. De l'autre, et pour les même raisons, c'est une catastrophe. En ignorant la réalité du SGDB, les performances chutent et les DBA crient au scandale, parce que la façon optimale de charger des données en mémoire dépend, au cas par cas, de l'usage que l'on s'apprête à en faire. NHibernate n'ayant aucune vision de cet usage, l'optimisation des requêtes ne peut être menée que par le développeur grâce aux outils (join fetch par exemple) de NHibernate.
Malheureusement, quelles que soient les possibilités qu'offre NHibernate pour forcer le chargement d'une collection d'objets en un seul aller-retour SQL, le seul fait que le développeur ait la possibilité d'ignorer le moyen par lequel les objets persistent (conformément au principe de Persistence Ignorance –PI– de l'approche Domain Driven Design –DDD) promet quelques utilisateurs énervés par la lenteur de certains traitements, des DBA scandalisés et finalement des clients mécontents. Bref une sale réputation.
Explicit loading
Et c'est donc une décision marketing qui a conduit l'équipe Microsoft responsable d'Entity Framework à choisir le chargement explicite (explicit loading) plutôt qu'implicite. Dans le dernier numéro de MSDN Magazine, l'encart intitulé "Insights: Entity Framework Data Loading" et signé DiegoVega est clair à ce propos : " Following the "no hidden network roundtrips" principle, Entity Framework avoids automatic lazy loading".
Aucun aller-retour avec le SGBD n'aura lieu sans que le développeur ne le sache.
Le principe de l'explicit loading est simple : tant que le développeur n'a pas écrit le nécessaire pour charger une Commande de notre association client.Commandes, l'accès à une de ces commandes déclenche une exception. En explicit loading, les développeurs se soucient du SGBD, les DBA sont heureux, et l'image de Microsoft est sauve.
Entity Framework, la couche de mapping objets/base de données relationelle (ORM) de .Net actuellement en beta 3, sera multi-database comme l'est Nhibernate. On pourra basculer de SQL Server vers MySql aussi facilement qu'on change de T-shirt (oui, vous faites bien de vous méfier de ce genre de promesses...).
Pour preuve, ces éditeurs cités par InfoQ prévoient de livrer des providers ADO.Net compatibles Entity Framework pour Oracle, MySQL, PostgreSQL, SQLite et DB2 : http://www.infoq.com/news/2008/05/ADO.NETProvider
WPF a vraiment énormément de qualités. Le choix de WPF pour écrire une nouvelle application Windows ou refondre l'interface graphique d'une application existante serait un choix évident si seulement le déploiement de .Net 3.0 ou 3.5, nécessaire sur les machines XP, n'était pas si long. Vraiment trop long.
Le service pack 1 de .Net 3.5 corrige ce handicap en autorisant de ne packager que ce que votre application n'utilise réellement du framework .Net. Un package typique devrait ainsi atteindre 25Mo, soit à peu près l'équivalent du download d'Acrobat Reader.
Cette option des projets d'installation, baptisée Client Profile, sera configurable depuis Visual Studio 2008 SP1.
L'IoC proposée par Microsoft à travers les Enterprise Library Blocks (EntLib) présentait jusqu'à maintenant deux inconvénients majeurs. D'un part l'objet au centre du mécanisme de construction des composants, ObjectBuilder, était insuffisamment documenté, et d'autre part et surtout les dépendances à injecter aux modules étaient spécifiées par des attributs définis dans EntLib (par exemble [ServiceDependency] et [CreateNew]). Un module développé pour l'IoC d'EntLib était donc définitivement lié à celui-ci au lieu d'être "container-agnostic".
Un système IoC qui implique une dépendance entre le module et son conteneur manque l'objectif de couplage faible. Le couplage fort entre modules et conteneur ruine tout espoir de réutilisation des modules hors EntLib. C'était une approche clairement inadaptée à la variété des applications et des socles techniques en entreprise.
Au final, les approches open-source telles que Castle Windsor, Spring.Net et StructuredMap étaient largement supérieures à l'approche ObjectBuilder dès que la réutilisation pesait dans la balance.
"[ASP.NET MVC] is highly extensible and pluggable. Everything in the MVC framework is
designed so that it can be easily replaced/customized (for example: you can
optionally plug-in your own view engine, routing policy, parameter
serialization, etc). It also supports using existing dependency injection and
IOC container models (Windsor, Spring.Net, NHibernate, etc)."
Grigori Melnik (Patterns & Practices): "Once refactored, the EntLib blocks can be used as a la carte with other DI containers – some updating of the façade would be necessary and we invite the EntLib enthusiasts to port the EntLib façade to individual containers. Swapping DI containers means organizations can leverage their existing infrastructure."
Linq occupe une telle place dans le buzz autour des nouveautés de .Net 3.5 sorti il y a deux mois qu'on en oublierait presque que Window Presentation Foundation (WPF) progresse lui aussi avec cette nouvelle mouture de .Net.
Bref, buzzons un peu sur les nouveautés de WPF en .Net 3.5, certaines méritent d'être connues.
RIA
- les applications WPF en mode Rich Internet Application que sont les applications XBAP (XAML Browser Application) peuvent maintenant s'exécuter sur Firefox en plus d'internet Explorer. Certes l'utilisateur final doit toujours installer .Net 3.5. Pour soulager l'utilisateur d'un téléchargement imposant il faut aujourd'hui se tourner vers Silverlight 1.0 et perdre 95% de la puissance de WPF.
- les cookies convoyés par une application Web sont maintenant exploitables par l'application XBAP et vice-versa.
3D intéractive
- Il manquait en WPF v1 (.Net 3.0) un moyen de coller simplement des éléments visuels interactifs sur des objets 3D. C'est chose faite en .Net 3.5 avec l'arrivée de la classe UIElement3D qui gère le focus et les événements du clavier et de la souris. C'est au développeur de créer ses classes dérivées de UIElement3D. Voir à ce propos le projet Perspective de Olivier Dewit disponible sur Codeplex.
- Mieux, on peut maintenant simplement plaquer sur des objets 3D des contrôles 2D (TextBox et Cie) grâce à la classe Viewport2DVisual3D. Cf. par exemple ce post de Lester Lobo.
Data Binding
- Le debugging du data binding s'est amélioré puisque les objets peuvent être notifié du statut du data binding via une nouvelle propriété attachée TraceLevel.
- Les objets métiers (ou les objets dédiés à la validation) peuvent valider ou invalider les changements des propriétés en implémentant l'interface IDataErrorInfo.
- Le couplage avec les collections issues de Linq a été amélioré.
Il faut ajouter à ces points à fort impact des progrès disséminés sur l'ensemble de WPF, dont les contrôles (RichTextBox en particulier), les documents (une propriété Selection sur les FlowDocuments est bien utile), les annotations et les add-in.
.Net 3.5, la prochaine mouture du framework .Net de Microsoft, actuellement disponible en version béta 2, comprendra des classes spécialement conçues pour faciliter le développement d'applications Peer-to-Peer. Réunies dans l'espace de nom System.Net.PeerToPeer, ces classes formalisent les trois étapes "standard" d'un système P2P : découvrir les machines peers, s'y connecter et communiquer.
Le 19 avril dernier est sortie la version beta de .Net 3.5 et de la prochaine version de Visual Studio ("Orcas"). Hélas pour l'instant ce téléchargement n'est accessible qu'aux bénéficiaires d'une souscription MSDN.
C# 3.0, inclus dans la preview de mars (liens ci-dessous), apporte les "extension methodes", ou méthodes d'extension, qui permettent d'implémenter de nouvelles méthodes sur des classes développées par des tiers, y compris par exemple sur des classes du namespace system. Plus besoin donc de classes type "helper" ou "utils" porteuses de méthodes statiques, les méthodes apparaitrons maintenant comme faisant partie des classes à traiter.
Par exemple
if (String Helper.IsValidEmailAddress(myString)) {...}
devient
if (myString.IsValidEmailAddress()) {...}
C'est par ce moyen qu'apparaissent dans Intellisense les nouvelles méthodes de Linq : select, where, group, orderby, etc.
C'est surement à consommer avec modération, mais c'est aussi un moyen à envisager pour publier des extensions métier à des socles logiciels génériques.
Les commentaires récents