Microsoft .NET 3.5 : Arrive-t-on à un tournant ?

Microsoft va sortir fin novembre 2007 pour ses abonnés MSDN, puis début 2008 pour les autres, la version 3.5 de son Framework .NET, accompagné des nouvelles versions de nombreux produits, à commencer par Visual Studio 2008. Pour bien comprendre ce que sera cette nouvelle version, il est temps de faire le point sur l’existant et de faire le tour des véritables nouveautés.

5 ans après la sortie de la version 1.0 du Framework .Net, Microsoft s’apprête à sortir la version 3.5 de son Framework dans quelques semaines. Tout comme pour la première version, les entreprises et les éditeurs peuvent déjà prendre en main les versions bêta, permettant par la même occasion à Microsoft de tester en « live » son nouvel environnement et ses outils de développement. Que s’est-il passé entre temps, et quelle sont les nouveautés de cette nouvelle version ? Que faut-il attendre de cette version pour le développement des applications Web ?

.NET Framework 1.0 : l’arrivée d’un Framework chez Microsoft

Avant l’arrivée de .NET, pour développer une application graphique (ou console), un
service ou un site Web dynamique, nous devions faire un choix parmi une jungle de modèles de développement (COM, WIN32, MFC, Visual Basic Runtime, ATL, etc.) et les langages associés (VBScript, Visual Basic 6, C++, J++, etc.). Côté déploiement d’applications, l’« enfer des DLL »[[DLL Hell en anglais]] était le lot quotidien des équipes de développement et d’exploitation.

Microsoft se devait de proposer une plateforme et une technologie entièrement nouvelles, tout en garantissant une compatibilité avec l’existant. En novembre 2000, Microsoft a ainsi présenté la première version de .NET 1.0 (Bêta 1), issue d’un travail commencé en interne dès 1996.

Les briques du Framework .NET

Comme socle du Framework, on trouve le « CLR » (Common Language Runtime), qui exécute de façon managée un code natif à la plate-forme cible (code machine). Le CLR dispose donc de mécanismes, dont certains sont connus du monde Java, comme le Class Loader, Le Garbage Collector (ramasse-miettes), le Type Checker, l’Exception Manager et le Security Engine pour garantir la fiabilité et la sécurité de l’exécution des applications.

On trouve également d’autres éléments plus spécifiques, comme le JIT[[{Just In Time]] Compiler} pour la compilation à la volée du langage intermédiaire commun (« CIL ») en instructions de codes natifs aux processeurs, ou l’interopérabilité COM avec le COM Marshaler pour garantir la compatibilité avec l’existant du monde COM. Enfin, les mécanismes pour la gestion des Threads, le Debug et le Profiling des applications sont aussi natifs au CLR.

Le Framework propose aussi un ensemble de classes (Types) de base, organisées en Namespaces — par exemple System.Text — qui vont des fonctionnalités les plus simples (gestion des tableaux, des chaines,..) aux plus évoluées comme ASP.NET (System.Web.*). Les services de bases sont regroupés dans le BCL, qui propose les types de base (booléen, chaîne, entier, tableaux, collections, etc.) et tous les services de gestion du CLR, comme par exemple la gestion du ramasse-miettes (System.GC) et la configuration des applications (System.Configuration), la sécurité, etc.

Puis les spécialisations sont faites par ensembles de fonctionnalités. Par exemple, ASP.NET regroupe un ensemble de services pour la création et l’hébergement des applications et des services Web. L’ensemble des services de bases est communément appelé NetFx pour .NET Functionality eXtension. On parle aussi de Hosts (Application WEB, Windows Forms, Service NT, Office avec VSTO).

Le Framework .NET 1.0 comptait déjà près de 4700 Classes, et comme pour Java, la performance des développeurs passe par la bonne connaissance des services proposés nativement. Pour les développements, les codes sources peuvent être en C# (nouveau langage issu des travaux de Anders Hejlsberg), ou en VB.NET (une évolution importante de VB 6.0 pour la plate-forme .NET). Le choix du langage ne s’arrête pas à ces deux exemples, mais dépend des compétences existantes dans l’équipe de développement. Ainsi, .NET est multi-langage. Le code source quand à lui est compilé en IL (Intermediate Language), un Bytecode compilé en code natif et géré par le CLR, permettant, en théorie, de cibler tous les systèmes disposant du bon CLR. Le projet Mono permet par exemple de disposer d’un CLR sous Linux relativement complète, notamment pour ASP.NET.

Pour le déploiement, le modèle se base sur l’unité de déploiement auto-descriptive appelées Assembly (ou assemblage). Il se caractérise physiquement sous forme d’un fichier (.dll ou .exe) contenant un ensemble de codes IL, de métadonnées et de ressources. L’Assembly décrit dans son Manifest les informations nécessaires à son déploiement, comme son nom, sa version, les Types exposés, ses dépendances à d’autres Assemblies,…

Enfin, une des grandes forces du Framework .Net (dès la version 1.0) est l’unification des développements Web et Windows en proposant une architecture dans ASP.NET permettant de voir le modèle HTTP (fondé sur le principe des réponses à des requêtes) comme une modèle événementiel. C’est ASP.NET qui fait la transition entre ces deux modèles tout en proposant un accès « classique » et total au modèle HTTP. ASP.NET propose aussi le « hosting » de Web Services.

.NET 1.1 : L’indispensable stabilisation !

.NET 1.1 ne fut principalement que la stabilisation du Framework .NET 1.0, instabilités propres à la jeunesse du Framework, et l’intégration de fonctionnalités arrivées après la sortie de .Net 1.0 et qui étaient disponibles de manière indépendante via un téléchargement. Ainsi l’utilisation des bases de données Oracle a été proposée de manière native avec l’intégration d’un Data Provider dans le namespace System.Data.OracleClient et les driver ODBC ont été intégrés via le namespace System.Data.Odbc.

Outre quelques éléments de sécurité, rien n’est venu perturber les développeurs. C’est du coté de son outil développement que Microsoft a fait pas mal de changements en proposant la version 2003 de Visual Studio .NET.

Enfin, les développements pour les mobiles ont été parfaitement intégrés à cette version.

L’arrivée de la version .NET 2.0 : un vrai socle pour les futurs {{NetFx ?}}

Pour bien comprendre pourquoi le Framework 2.0 peut être vu comme un socle il est nécessaires de voir comment ont évoluées chaque partie du Framework avec cette version.

Quoi de neuf dans la version 2.0

C’est le 8 novembre 2005 que Microsoft à sortie officiellement la version 2.0 de son Framework. Les nouveautés du Framework 2.0 sur la partie technique furent une vraie révolution. Cela à permis de mettre en place les éléments manquants pour faire de .NET 2.0 une vraie base pour les futures évolutions.

Et c’est tout d’abord le CLR 2.0 qui fut fortement touchée on retrouve dans la nouvelle architecture :
– Le support des Architectures Microprocesseurs 64 bits pour cibler les microprocesseurs de dernières génération.
– La mise en place de Generics pour permettre une sécurisation du code lors de la compilation et éviter le casting de type (depuis ou vers Object). L’arrivée des Nullable (System.Nullable) en est aussi une parfaite utilisation.
– Le support natif de nouvelles interfaces ou de nouveaux protocoles de communication avec dans les librairies de classes de base, les BCL, le support du FTP, des ports de communications séries, etc. On trouve aussi dans System.Web la classe HttpListner pour la création de Serveur Web.
– Le support natif des transactions, avec Sytem.Transaction, permet d’utiliser le gestionnaire de transactions de sont choix (comme MSDTC-Microsoft Distributed Transaction Coordinator) et doit nous simplifier la réalisation des comportements transactionnelles de nos composants.
– Le retour du Edit and Continue natif à le CLR est le point intéressant coté développement.
– La performance a été éprouvée, certes moins visibles mais tout aussi efficace, on trouve dans ce point des éléments comme la gestion des collections dans System.Collections.Generic (grâce en partie à l’utilisation des Generics) ou les traitements XML améliorés sur les sérialisations par exemple.

Lister toutes les nouveautés de .NET 2.0 serait un peu long, mais elles montrent bien les réelles avancées de Microsoft pour construire un socle stable.

Quelques points nous semblent importants à bien comprendre, voici donc un zoom sur ce qu’il faut retenir.

Les Generics

L’arrivée des génériques dans le CLR 2.0 induit donc la capacité à ne traiter les types qu’au moment de l’exécution et non pas au moment de la compilation, cela signifie que l’on développe en écrivant du code fortement typé, donc sécurisé, sans mécanisme de boxing/unboxing et tout en ne connaissant pas le type à priori. Tout du moins, on peut restreindre sur un ensemble de Types. Cette notion est issue du principe de Template C++.

Du point de vu du développement, les Generics permettent de déclarer un type avec un nom quelconque et ce type sera remplacé à l’exécution par le type réel choisi.

Cette nouveauté simplifie grandement l’implémentation d’un Framework (technique ou fonctionnel) car cela évite de générer des méthodes spécifiques aux types des objets métiers manipulés. Il est aussi possible de limiter les types potentiellement affectables via l’opérateur where.

Exemple en C# 2.0.

Dans cet exemple, nous déclarons une classe convertissant un objet dans un type quelconque :


public class CAConverter<T>
<em>public TypeduRetour Convert(object o)
{
// Codes pour la conversion selon
// le code est très simple : return (TypeDuRetour) o ;
// on retrouve ici le métiers selon le type
return (TypeDuRetour) o ;
</em>
}


Il est possible de déclarer plusieurs types génériques. Dans cet exemple la classe implémente une hashtable fortement typée de manière générique (même si cela existe dans le Framework .NET 2.0) :


public class MaClasse<TypeKey, TypeValue>
<em>private Hashtable _CAHashtable = new Hashtable() ;
public void Add(TypeKey key, TypeValue value)
{
_CAHashtable.Add(key, value) ;
</em>
public TypeValue Get(TypeKey key)
<em>return (TypeValue)_CAHashtable<a href="http://www.hibernate.org/343.html">key] ;
</em>
}


On l’utilise l’utilisera alors de la façon suivante :


// Déclaration et initilisation
CAClasse<int, string> htable = new CAClasse<int, string>() ;
htable.Add(0, "Conseil") ;
htable.Add(1, “en") ;
htable.Add(1, “architecture") ;
// Récupération
string s = htable.Get(0) ;


On a aussi la possibilité de limiter un Generic à un scope.

Le premier exemple limite aux classes implémentant IList :


public class MaClasse<T> where T : IList
<em>...
</em>


Le second exemple limite T aux classes ayant un héritage, la syntaxe C# est :


public class DTOList<T> : IList<T> where T : DTO
<em>...
</em>


Dans le cas où plusieurs types ont été définis, la syntaxe est :


public class DTOList<T, U> where T : DTO where U : MaClasse
<em>...
</em>


NetFx 2.0 utilise les Generics massivement dans un ensemble de nouvelles classes. Il est important de bien maîtriser cette notion, notamment dans les développements d’applications ou de Frameworks. [NHibernate par exemple intègre maintenant les Generics.

ASP.NET 2.0

De grandes évolutions ciblent aussi ASP.NET (Namespace System.Web). En effet, parmi les plus grandes avancées sur les fonctionnalités proposées par le Framework .NET 2.0, c’est ASP.NET qui a été le plus fournit en nouveautés.
On trouve ainsi :
– L’utilisation des classes partielles pour la gestion du mode de développement en « Code behind »
– L’arrivée des Master Pages et des thèmes pour améliorer la « Templétisation » et la séparation de la présentation et du code.
– Le pattern Provider est utilisé pour définir un ensemble de nouvelles API qui permette la conception et la réalisation des fonctionnalités (services) d’un site WEB (Membership, SessionState, etc.). Au moins une implémentation est fournit par ASP.NET pour chacun des services définit (SQLMembershipProvider, AciveDirectoryMembershipProvider, InProcSessionStateStore, etc.). Ce modèle de Provider est extensible ( Namespace System.Configuration.Provider) peut être utilisé dans tous les développements .NET, il faudra pour cela bien vérifier qu’une Factory est disponible. Pour ASP.NET cette factory se trouve dans System.Web.Configuration.ProvidersHelper
– Un ensemble de composants (près de 40 contrôles ASP.NET), que l’on peut qualifiés de composites, qui permet de mettre en œuvre facilement les fonctionnalités apportées par les Providers.
– L’unification des modèles de développements Web d’ASP.NET 1.1 (System.Web) et de Microsoft Sharepoint Service 2.0 (Microsoft.Sharepoint), ainsi on retrouve le nouveau Namespace System.Web.UI.WebControls.WebParts dans ASP.NET 2.0.
– Une forte utilisation et évolution des assistants lors de la conception dans Visual Studio 2005 ce sont les « Design Time Wizard».

ADO.NET 2.0

ADO.NET, lui aussi a vu son modèle évoluer avec la gestion des Provider de bases de données (fournisseurs managés pour la communication et les opérations avec la base) et est maintenant basé sur une API qui utilise le Pattern Factory. Pas mal de nouveautés d’ADO .NET permettent la conversion de DataReader en DataTable ou DataSet. Cette opération est réversible. A noter que les datatable sont iXMLSerialible.


< !-- Dans le fichier de configuration de l’application-->
<appSettings>
<add key="DbProvider" value="System.Data.SqlClient"/>
<add key="ConnectionString"
value="Server=localhost;
Database=Northwind;
Integrated Security=true;"/>
</appSettings>


SampleADO20.cs


// Utilisation de la Factory pour obtenir une instance du Provider
DbProviderFactory dbfactory =
DbProviderFactories.GetFactory(
ConfigurationSettings.AppSettings.Get("DbProvider"));


Conclusion sur .NET 2.0

Globalement, lorsque cela était nécessaire (voir obligatoire) pour assurer le caractère extensible du Framework, on trouve dans les évolutions de ces Namespaces, un mécanisme de délégation de l’implémentation, réalisé par la définition d’une Interface et d’un constructeur (sorte de Factory), permettant ainsi une très grande modularité.

Le Framework 2.0 (CLR et NetFx) a donc gagné en maturité et devient le socle des évolutions suivantes.

Visual Studio 2005 : au point pour la productivité ?

Véritable pierre angulaire de la stratégie de productivité des développements .NET pour Microsoft, Visual Studio 2005 (nom de code « Whidbey ») est arrivé avec le NetFx 2.0. C’est après deux compagnes de versions Betas et malgré les nombreux commentaires des bêta-testeurs pointant de nombreux bugs, que Microsoft avait maintenu sa sortie. Nous avions pu rapidement constater l’immaturité du produit lors de sa sortie alors qu’il avait déjà pris beaucoup de retard, puisqu’il aurait du être livré initialement fin 2004.

Le principal retard de l’IDE (Integrated Development Environnement) fut sur l’usine logicielle : ce n’est que 4 mois après la sortie de Visual Studio 2005 que Visual Studio Team Foundation Server a fait son apparition avec des bugs de jeunesse parfois assez importants.

Entre temps, nous sommes nombreux à avoir opté pour des solutions Open Source basée sur CruiseControl .NET, Subversion et Ankh[[une extension à VS 2005 qui permet de gérer ses sources SVN directement depuis l’IDE]].

Enfin, il a fallu attendre le SP1 en décembre 2006 (et en mars 2007 pour les développeurs sous Vista), soit près de 13 mois après la sortie de VS 2005, pour voir corrigé et optimisé l’environnement qui souffrait de problèmes majeurs (lors du debugging d’application Windows par exemple).

De WinFX à .NET 3.0 : le discours marketing prend le dessus !

La version 3.0 du Framework, longtemps connue sous le nom de code WinFX, ajoute 4 briques fonctionnelles au socle NetFx 2.0. On peut voir ces 4 extensions comme des Hosts supplémentaires.

Cela aurait été plus clair de le laisser sous ce nom car ces nouvelles fonctionnalités sont, comme le fut ASP.NET 2.0 en son temps, que des extensions au CLR 2.0 et aux BCL (Base Class Libraries). La dénomination de ces briques ne laissait pourtant aucun doute :

– Windows Communication Foundation (WCF) est l’unification, au sein d’un modèle unique, des modes de communications dans les applications réparties (WebServices, .Net Remoting , WSE 3.0, MSMQ, …).
– Windows Presentation Foundation (WPF) a fait évoluer le moteur de présentation (le « rendu ») des applications Windows et fournit un modèle de développement basé sur l’externalisation de la définition de ces interfaces, via le langage XAML. Silverlight — ex WPF/E pour « Everywhere » — est la déclinaison de WPF pour son intégration dans les navigateurs Web.
– Windows Workflow Foundation (WF)[[Pas de chance, WWF était déjà utilisé]], propose un moteur d’exécution de Workflow (sur la plate-forme Windows) ainsi qu’un modèle de programmation et des outils pour le développement des ces Workflows.
– Windows CardSpace, permet la gestion des identités numériques, il regroupe les applications pour l’utilisateur (InfoCard), lui permettant de manipuler ces identités (cartes) et les API (.NET et autres) pour l’utilisation de ces identités. Il ne correspond pas à une évolution de Microsoft Passport mais bien à une mise en œuvre avec les standards des protocoles WS-*.

Nous aurons l’occasion de revenir sur ces 4 briques dans de prochains articles de notre blog.

[greenbit<-]Ce choix d’appellation aura au moins eu le mérite de forcer les équipes de développements de chez Microsoft à mettre en place une stratégie de migration et de cohabitation des différentes versions du Framework. En effet, pour permettre l’évolution vers NetFx 3.0, les équipes de Microsoft ont mis en place un mécanisme d’évolution appelé « RedBit », qui permet de garder une compatibilité ascendante sans recompiler le code source des applications .NET 2.0.

On comprend mieux alors que .NET 3.0 ne soit qu’une évolution qui propose de nouvelles fonctionnalités de « haut » niveau.

.NET 3.0 : l’évolution à maîtriser ?

C’est donc fin novembre 2006, que .NET 3.0 fut disponible, entre autre retardé par le besoin de synchroniser sa sortie avec celle de Windows Vista. Mais il manque encore pas mal des choses à la plate-forme pour une réelle productivité des développements. Ces manques se retrouvent à plusieurs niveaux.

Si l’on reprend les briques de .NET 3.0, les choses ne sont pas si roses pour nous lors des développements.

Dans le cas de WPF, même s’il est stable, Microsoft a beaucoup « tâtonné » dans la réalisation des outils pour le développement des interfaces WPF et c’est seulement avec l’arrivée de Silverligth que les outils de développements associés (la Gamme Visual Studio Expression) ont été finalisés.

Même si Microsoft avait anticipé certains phénomènes du Web 2.0, il manque de vrai références pour les applications RIA/RDA. En effet, Il n’existe pas encore, chez Microsoft, de véritable produit ou application grand public avec une interface riche basée sur WPF. Enfin Silverlight, en version finale seulement depuis peu, a perdu du temps face à ses concurrents. Seul Popfly semble utiliser pleinement les capacités de Silverligt.

Pour WCF, les extensions pour Visual Studio 2005 sont disponibles dans les « Visual Studio 2005 extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP » et Microsoft indique qu’elles resteront en CTP (Community Technologie Preview) pour Visual Studio 2005. Là aussi il faudra attendre Visual Studio 2008 pour une intégration complète.

Là encore on constate que Microsoft a loupé la sortie des outils associés à ces nouvelles briques techniques.

Enfin, WF semble être le mieux intégré car il est utilisé dans les produits Microsoft avec MOSS 2007 — via le WorkFlow Designer — par exemple. Enfin les extensions WF pour Visual Studio 2005 sont disponibles et maintenues.

et Ajax ?

Certes, les extensions Ajax pour ASP.NET – Microsoft ASP.NET 2.0 Ajax Extension – permettent la mise en place d’applications « Ajaxisées » en .Net, mais Visual Studio 2005 ne propose pas toutes les facilités pour un tel type de développement, pas d’IntelliSense javascript avancée, pas de debug non plus.

Toutes ces avancées de Microsoft ne sont malheureusement pas appuyées par une évolution de Visual studio 2005 et toute la puissance d’un tel environnement sur la productivité a fortement été réduite. Toutes ces évolutions ne seront proposées que par Visual Studio 2008.

.NET 3.0 : Les entreprises sont-elles prêtes ?

Aujourd’hui toutes les entreprises n’ont pas fait le pas vers .NET 3.0, tout juste le passage vers .NET 2.0 est encore en cours pour certaines. Pour les entreprises, les avantages de .NET 3.0 sont très mal connus et la situation pas très claire lors du changement de nom a été un frein important. Le retard, voir le manque d’outils pour les développements ne joue pas en faveur de son adoption.

Le déploiement de cette version 3.0 du Framework reste aussi un des freins majeurs à son adoption, c’est encore une mise à jour à déployer sur les serveurs et les postes clients XP et seul Windows Vista l’intègre nativement.

Enfin, un grand nombre de produits de l’offre Microsoft n’intègrent pas ces évolutions, par exemple Commerce Server 2007 ne se base pas sur Wokflow Foundation pour la gestion de ces processus eCommerce. Il faudra donc attendre la prochaine Release des produits Microsoft pour voir une généralisation de .NET 3.0.

Malgré cette situation peu claire sur .NET 3.0, il nous parait impératif de passer en version 2.0 du Framework .NET, car c’est évidement un gage de pérennité sur le support et l’évolution des applications .NET.

Après .NET 3.0 : A quoi fallait-il s’attendre ?

Les évolutions (mineures) de Visual Studio avec ses outils de la gamme Team Suite (l’outil de gestion des projets de base de données), la spécialisation de la gamme Expression (pour la partie du Framework d’interfaces avec Silverlight par exemple) et les quelques plug-in évoqués pour les briques WCF et WF ne suffisent pas à faire le choix de .NET.

La productivité de Visual Studio 2005 ne fait plus la différence pour les développements ciblant la version 3.0 du Framework.

.NET 3.5 : la seconde révolution de Microsoft ?

La productivité des développements reste au cœur de la plateforme .Net et Microsoft se doit d’évoluer face à la monté des Frameworks RAD.

Avec .NET 3.5 Microsoft repart sur la voie de l’innovation et LINQ, (Language INtegrated Query), en est l’exemple parfait.

Pourquoi LINQ

L’une des grandes problématiques avec les développements .NET et les langages associés est l’accès aux données (source d’informations). Par exemple, on voit souvent une différence entre l’accès aux données relationnelles (SQL-92 par exemple) et l’accès aux données dans une collection d’objets ou une séquence XML. Par exemple on fera pour du SQL dans une string :


SELECT nom, prenom FROM clients WHERE nom LIKE ‘%Clever %’


Alors que pour une liste d’objet on utilisera :


For each client In clients
<em>ListeDeroulante.Add(client.nom) ;
</em>


On voit clairement ici que la capacité du Runtime de faire la vérification est impossible dans le cas de la requête SQL.

LINQ offre la capacité d’intégrer aux langages .NET une syntaxe d’interrogation des sources de données. Cette interrogation est sécurisée puisqu’elle est fortement typée. Ainsi, les modifications sont directement visibles et intégrés dans le langage. Les deux langages VB 9.0 et C# 3.0 voient évoluer leur syntaxe et leur compilateur.

Avec LINQ, la manière d’aborder le CLR a dû évoluer. En effet, ce n’est pas le CLR qui est modifié et on ne voit pas une nouvelle version du Runtime mais ce sont les compilateurs qui apportent des nouveautés en utilisant toutes ses capacités (donc le CLR reste en version 2.0 !).

En termes de données « interrogeables » on retrouve :
– XML avec LINQ to XML
– les bases de données avec les extensions ADO.NET 3.0, LINQ to SQL, LINQ to Dataset et LINQ to Entities
– les objets avec LINQ to Objets

Le modèle est ouvert et permet l’intégration de tout type de données.

Evolutions des langages C# et VB.NET avec LINQ

Les nouveautés présentées en C# 3.0 sont disponibles en VB.NET 9.0.

Les variables locales peuvent être typées de façon implicite, on utilise alors le mot clé var, les variables restent fortement typée.


var age = 34 ;


Dans cet exemple la variable locale age est de type int. Et le code suivant ne compilera pas


var age = 34 ;
age = "43 ans" ;


Les méthodes d’extension donnent aux développeurs la capacité d’étendre les fonctionnalités d’une classe pour laquelle il ne dispose pas du code, de « greffer » des méthodes. Le mécanisme passe par la prise en paramètre de l’instance de l’objet passé en paramètre. Ces méthodes doivent être static :


namespace System
<em>public static class CleverAgeStringExtension
{
public static bool MadeBy(this string str) // déclaration de la method d’extension
{
// Ajoute Made By ‘Clever Age’
return new string(“Made by Clever Age : ” + str) ;
</em>
}
}


Son utilisation sera alors :


string s = "Chronique .NET 3.5" ;
txtInfo.Text = s. MadeBy () ;


Les expression Lambda permettent d’étendre les codes des méthodes et d’inclure des blocs de code directement en ligne (inline). Cette notion existait déjà en C# 2.0 avec les méthodes anonymes. Avec les expressions lambda ce mécanisme est étendu aux données.

La syntaxe d’une expression lamba est Une liste de paramètre => Une expression (code) :


(int x) => x + 1 // un paramètre (type explicite)
(y,z) => return y * z ; // paramètre typé de manière implicite


L’utilisation d’une telle syntaxe se comprend facilement lorsqu’une lamba expression sert à simplifier l’utilisation d’un délégué.

Avec une méthode de recherche qui aurait cette signature :


public static IEnumerable<T> Where<T>(
IEnumerable<T> items, Func<T, bool> predicate)


On peut faire un appel de ce genre :


var Filiales =
nosSocietes.Where(s, s => s.societePrincipale == “Conso. Coprp.”) ;


Pour ceux qui ont utilisé les Predicat Generic Delegate , cela devrait simplifier leurs problèmes. La encore c’est le compilateur qui va travailler pour nous.

L’Initialiseur d’objet permet de simplifier la construction d’un objet, on passe alors du code suivant :


Chronique nouvelleChronique = new Chronique() ;
customer.Titre = “.NET 3.5” ;
customer.Auteur = “Laurent Pasquali” ;


à ce code(même si le constructeur paramétré n’existe pas)  :


Chronique nouvelleChronique = new Chronique()<em>Titre = “.NET 3.5”, Auteur = “Laurent Pasquali”</em> ;


Il faudra donc faire attention pour la maintenance des applications et faire évoluer les guides de développement.

Les type anonymes offrent la possibilité de déclarer un nouveau type directement dans le code.


var InfosSimplifier = new <em>NomSociete = "Clever Age", EstUnCabinetDeConseil = true </em> ;


Le compilateur crée un type anonyme qu’il ne sera pas possible de référencer (facilement !) en dehors du bloc de code contenant cette déclaration.

Exemple de code LINQ

Ce code permet donc la création d’une liste d’aperçus depuis la liste des chroniques.


List chroniques = GetChroniqueList() ;

var AppercuChroniquesEnligne =
from c in chroniques
where c.IsOnline == true
select new <em>Titre = c.Title, Resume = c.Summary </em> ;


Les autres évolutions de .NET 3.5

ADO.NET 3.5

Cette partie du Framework se voit dotée de nouveautés très intéressantes comme :
– le Framework de Mapping Objet Relationel (MOR) ADO.NET Entity Framewok, même si celui–ci ne sera pas forcement inclus dans la version finale de NetFx 3.5.
– LINQ to Entity est l’extension LINQ pour ADO.NET Entity Framework.
– LINQ to SQL dans System.Data.Linq.dll.
– LINQ to XML dans System.Xml.Linq.dll.
– LINQ to DataSet dans System.Data.DataSetExtensions.dll .

On constate qu’ADO.NET se voit doté de deux technologies de MOR. Dans nos projets un choix devra se faire avant la mise en place de l’architecture logicielle.

ASP.NET 3.5

Avec cette nouvelle version d’ASP.NET, arrive le support complet des extensions AJAX (System.Web.Extensions.dll passe en Version 3.5) donc plus besoin d’installer de nouvelles assemblies et les deux versions peuvent vivre ensemble. Donc avec cette intégration d’ASP.NET AJAX 3.5, Microsoft fournit par exemple :
– Le debuging JavaScript
– L’utilisation d’UpdatePanel avec les contrôles WebParts
– Le support JSON avec WCF
– L’inscription automatique des extensions dans le Web.config

De nouveaux contrôles arrivent pour plus de productivité :
– asp:ListView agrège un ensemble de contrôle pour permettre la gestion complète des données et du code HTML générés
– asp:DataPager permet, quand à lui, la mise en place d’un contrôle pour la Pagination (jusque là un peu pénible)
– asp:LinqDataSource peut être vu comme le pendant d’ObjectDatasource pour l’intégration de LINQ comme source de donnée.

La dernière nouveauté attendue est l’arrivée d’un Framewok MVC, si souvent annoncé, qui permettra enfin à ASP.NET de disposer d’une implémentation de référence.

et encore..

Les autres évolutions à noter sont :
– Le cœur de BCL évolue (System.Core.dll) et intègre, outre LINQ to object, de nouvelles classes comme HashSet, TimeZoneInfo, Pipes, ReaderWriteLockSlim.
– un système d’Addin (plug-in) définit dans les BCL System.AddIn.dll
– Nouveau namespace pour du PeertoPeer System.Net.PeerToPeer
– De nouveaux algorithmes ajoutés dans le namespace System.Security.Cryptography
– Une évolution de WPF pour supporter les Addin.
– WF (System.WorkflowServices.dll) et WCF (System.ServiceModel.Web.dll) évoluent eux aussi.

Et la pérennité des Frameworks dans tout ça ?

Afin de garantir la compatibilité des évolutions de son Framework, Microsoft dès la version 3.0 avait mis en place une notion d’identification des Assembly de la version 3.0, ce furent les assembly « RedBit ». On peut voir cette notion comme un block de compatibilité d’assemblies entre elles. Ces assemblies s’appuient sur le CLR 2.0 et garantissent une compatibilité avec celui-ci.

Ce mécanisme d’extension du Framework par couches successives fut appliqué à NetFx 3.5 (.NET 3.5), dont le code est « Greenbit ». En interne Microsoft avait lancé les développements des deux Frameworks en parallèle.

On peut même pousser cette notion et identifier NetFx 2.0, lui-même, comme un bloc de compatibilité à part entière.

La notion de Red et Green Bits avait été lancée par soma et Jason dès mai 2006.

Pour NetFx 3.5, System.Core.dll est donc l’assembly principale et au « cœur » du Green bits !

Visual Studio 2008 : la productivité retrouvée

Depuis la version précédente de Visual Studio, Microsoft avait supprimé le terme .NET dans la désignation de ses produits et avait étoffé la gamme de produits avec une suite orientée sur les développements en équipes Visual Studio Team Suite.

Visual Studio 2008 continue dans cette direction et ne propose pas un changement radical d’interface comme le fut le passage de la version Visual Studio .NET 2003 à la version Visual Studio 2005.

Visual Studio 2008 est donc l’intégration d’outils de productivité pour .NET 3.5 (LINQ entre autres) et l’unification de tous les points laissés en suspens sur Visual Studio 2005 en ajoutant le support intégral des extensions du NetFx 3.0 (WCF, WF, WPF). Visual Studio continue sur le créneau de la « Productivité du développeur ».

Cependant, l’intégration continue et l’automatisation des tests (règles importantes de nombreuses méthodologies projets) restent des point sur lequel Microsoft doit poursuivre ses effort, même si Visual Studio 2008 Team Foundation proposera l’ensemble des améliorations et demandes faite depuis la version 2005 du produit (comme TFS PowerToys). L’annonce de la prochaine version de Visual Studio Team System — Code Name « Rosario » — montre que Microsoft doit rapidement investir le terrain de la gestion de projet.

Les nouveautés de Visual Studio 2008

Le multi-targeting est donc la première nouveauté notable et offre la capacité à Visual Studio 2008 de cibler plusieurs versions du Framework (NetFx). Mais cette capacité ne concerne que les applications .NET 2.0 à .NET 3.5. Car comme on a pu le voir le CLR ne change pas de version dans ce cas !

Cette capacité vaut aussi pour les deux versions d’ASP.NET AJAX Extension (version 1.0 et version 3.5).

Certes il ne sera plus nécessaire d’avoir plusieurs outils pour la maintenance des applications mais les développements faits sur NetFx 1.1 devront encore être repris avec Visual Studio 2003.

Pour les développements Web, ce sont de nouveaux outils qui apparaissent :
– Intellisense du Javascript « classique » et celui du Microsoft AJAX Library (Framework JavaScript client).
– Un nouveau designer de page (hérité de Visual Studio Expression Web) avec une vue conjointe du code et du design.
– De nouveaux outils pour les CSS

Avec toutes ces nouveautés (nous ne les avons pas toutes listées), une formation courte des équipes s’impose avec l’arrivée de l’outil. Ainsi tous les développements 2.0, 3.0 et 3.5 pourront être faits avec le même outil.

Et la construction d’application et d’architecture orientés services dans tout cela ?

Après cette présentation du Framework 3.5, il devient donc indispensable de bien choisir les briques que l’on va utiliser lors de la construction du Framework applicatif.

Pour nous, la mise en œuvre des prochaines architectures, ou l’évolution des applications existantes, passent par l’utilisation des Frameworks et d’outil RAD qui devront, au moins, intégrer LINQ, WCF et WF.

Pour la modélisation des applications (interfaces Web et des clients riches) les extensions DSL — [Domain-Specific Language->http://msdn2.microsoft.com/en-us/vstudio/aa718368.aspx] — doivent s’inscrire dans la démarche de réalisation des projets. Cette technologie s’intègre maintenant à Visual Studio 2008.

Des Frameworks RAD pour .NET ?

Avec le Framework .NET 3.5 et ses outils il faut se poser la question du choix de NHibernate par rapport à Linq to Data ou ADO.NET Entity Framework. Le choix du Framework MVC, lui aussi, devient crucial. Le reste des questions pour la réalisation d’un projet l’est tout autant : quelles stratégies de tests faut-il adopter et avec quels outils, comment modéliser les domaines de son application, comment modéliser la navigation dans l’interface de l’application,… ?

Là où Java a su répondre en imposant des Framework de références et son outil Eclipse, les architectures .NET 3.5 se voient confrontées à de nombreux choix.

On voit bien que le renouveau de PHP et l’engouement massif pour RubyOnRails s’explique par le fait qu’ils proposent une réelle productivité : PHP dispose de vrais Framework RAD — dont Symfony — et RubyOnRails guide fortement par son architecture MVC et dispose d’un langage très productif. On peut donc se poser la question : Microsoft a-t-il anticipé ?

Coté langages, Microsoft pourrait répondre à GWT (Google Web Toolkit) par son projet Volta (permettant à partir d’un seul développement de fournir le code pour une exécution sur différents tiers : pour le navigateur avec la génération du code javascript, pour les serveurs d’application avec de l’IL). Chez Microsoft on pousse aussi pour faire émerger des langages fonctionnels comme F#

Coté Frameworks RAD, cela n’avait pas été toujours le point fort chez Microsoft, les Entreprise Librairies et ses applications blocs ne furent pas un modèle de « souplesse ». C’est avec l’arrivée des Software Factory, que Microsoft semble proposer enfin des bribes de Frameworks RAD.

Puis les projets comme BLINQ qui permet la génération de Back-Office pour la gestion des données d’une application, Jasper, Astoria, pensent à croire que Microsoft s’engage dans la voie des Framework RAD.

Faut-il compter sur les communautés et les initiatives OpenSource ?

Microsoft à ces derniers temps largement communiqué sur son souhait de s’ouvrir aux autres technologies et plateformes. C’est peu être comme cela que Microsoft pourra ajouter à ses développeurs habituels, qui travaillait déjà sur la plate-forme Windows et pour qui l’utilisation de .NET était naturelle, l’ensemble des développeurs de la plateforme Internet (via Silverlight entre autre) ; et le nombre des développeurs de cette communauté est bien plus important !

Conclusion

Avec .NET 3.5 et ses outils de développements, Microsoft repart sur la voie de l’innovation et de la productivité pour réaliser des applications riches plus rapidement.

Le socle du Framework stabilisé et le chemin de migration maîtrisé permettent une véritable richesse des outils de productivité pour les développeurs et architectes. Attention cependant, à ce qu’ils soient complets et finalisés donc stables dès la sortie de .NET 3.5 prochainement.

C’est donc l’engouement derrière LINQ, les nouveautés d’ASP.NET (et ses extensions AJAX), l’essor de WPF/Silverlight, puis l’émergence de bons Frameworks (MVC, MOR) et de langages fonctionnels productifs qui permettront de comprendre si Microsoft, avec le Framework 3.5, aura réussi son pari et démontré clairement que .NET évolue dans le bon sens.

Pour les entreprises qui ont attendu de voir ce qui se passait avec .NET 3.0, c’est donc avec .NET 3.5 qu’il faut véritablement prendre le pas de .NET 3.x.

Synthèse des versions