Blog Objet Direct

L’année dernière, pendant mon année d’alternance, j’ai travaillé sur la plateforme Windows Phone 7. Je vais essayer de partager avec vous mon expérience sur cette plateforme mobile qui reste un peu méconnue du grand public, tout en essayant d’avoir un esprit critique sur le sujet.

Dès mon arrivée en septembre 2010, j ‘ai eu la chance  de manipuler des terminaux qui n’étaient pas encore commercialisés (date officielle de sortie : le 21 octobre 2010). Voici les réactions immédiates qui me sont venues concernant le hardware. Côté design rien d’impressionnant,   les téléphones sont assez sobres mais ce qui m’a surpris ce sont les performances : une rapidité d’exécution pouvant faire pâlir certains de ses concurrents et des écrans de très bonne qualité. La gamme des téléphones est assez homogène (caractéristiques techniques moyennes : processeur 1Ghz, 512MB de RAM, capacité entre 8 et 16Go, écran 800×480pixels, APN 5mégapixels avec Flash).

Au niveau de l’OS, le premier démarrage donne vite un brin de déception : on trouve un premier bureau avec les applications épinglées (grosses icônes carrées) et un autre avec « une grosse liste horizontale de toutes les applications », autant dire qu’il ne faut pas avoir peur de slider lorsqu’on a une grosse liste d’applications… On retrouve donc une interface Metro assez basique et on se rend vite compte que, mis à part la couleur des icônes et l’épinglage d’applications, rien n’est modifiable. En ce qui concerne les applications natives, on retrouve les classiques  (« Téléphone», « Contacts », « Photos », « Musiques + Vidéos », « Internet Explorer 8 » et « Jeux » qui correspond au Xbox Live),  la suite Microsoft Office Mobile et le moteur de recherche Bing accessible à tout moment (grâce à la touche recherche). Enfin, on a le Windows Phone MarketPlace, sur lequel, j’ai pu me rendre compte tout au long de l’année, qu’on retrouve petit à petit les grands classiques des autres markets (pour n’en citer aucun).

Maintenant, que le tour de l’utilisateur lambda est fait, passons à la partie un peu plus technique.

Le développement d’application WP7 repose sur une version de Silverlight « adaptée ». En plus du framework traditionnel, on trouvera toutes les APIS spécifiques aux SmartPhones : accéléromètre,  géolocalisation, caméra, tâches : téléphoner, envoyer un message, lancer le marketplace, et d’autres encore. On trouve aussi les 2 modes de navigation propres aux applications WP7 que sont le panorama et le pivot ; dans le cadre de mon projet l’accent était mis sur l’utilisation du panorama pour garder l’authenticité de WP7 et ne pas essayer de copier la navigation par onglets des autres plateformes mobiles. Toutefois, on observe une certaine amputation au niveau des composants classiques qui composent Silverlight et celle-ci s’avère vite handicapante.

Qui dit Silverlight, dit pattern MVVM (Model View ViewModel)… Ces deux notions étaient pour moi totalement inconnues et mes premiers pas furent hésitants, mais une fois les grands principes compris, on devient très vite adepte du concept.  Pour faire simple, et sans rentrer dans les détails voici un petit schéma  qui explique le pattern:

MVVM est basé sur le principe de « Databinding » qui permet de synchroniser une propriété du ViewModel avec une propriété d’un composant graphique de la View (y compris les événements : click, changement de sélection,…).  Cette technique devient très vite appréciable : code minimal, rafraichissement  automatique  dans les 2 sens entre la View et ViewModel.

De plus, du fait de sa faible dépendance entre les interfaces graphiques et le code métier, MVVM facilite les tests de code et la séparation des taches des développeurs et des designers. J’en profite pour faire un petit point sur les outils mis à disposition. Tout d’abord, on trouve l’incontournable IDE pour les technologies Microsoft, Visual Studio auquel est associé le Windows Phone Developer Tools (SDKs + Emulateur). Pour moi, l’environnement s’est avéré être très complet : parmi les choses appréciables, on trouve un petit éditeur d’interfaces graphiques, le déploiement sur l’émulateur ou sur un device, un débuggeur pas à pas (dans les 2 cas de déploiement). Il est possible d’effectuer tout le développement dans Visual Studio, toutefois, dans le cadre d’un projet où un designer a un rôle à part entière à jouer, il peut utiliser l’outil Microsoft Expression Blend pour créer les interfaces graphiques sans se soucier du code métier qui tournera derrière. Pour ma part, je pense que Blend est un « jouet de luxe » et qu’on peut rapidement s’en passer.

Voici un petite liste des concepts que j’ai pu utiliser et qu’il est judicieux d’évoquer :

• L’ IsolatedStorage est un espace de stockage de données propres à chaque application et qui est abstrait du reste de système de fichiers et facile d’utilisation.
• L’application possède plusieurs points d’entrées (launched ou actived) et de sorties (closed et deactivated) dans lequel on peut faire des traitements différents selon que l’utilisateur ferme ou mette en background l’application. On trouve aussi  une méthode Application_UnhandledException qui permet d’effectuer des actions importantes (sauvegarde du contexte par exemple) avant que l’application se ferme dans le cas d’une exception non traitée (donc crash) et cela s’avère très utile.
• Dans l’attente de la gestion du multitâches, le développeur doit gérer la sauvegarde du contexte de l’application lors de sa « mise en background » et le rétablissement de ce contexte lors de la réactivation de l’application. Ce procédé appelé le tomstoning est assez fastidieux puisqu’il faut sauvegarder unitairement toutes les données nécessaires, mais il est toutefois inévitable dès lors que l’application possède des données persistantes. Dans le cadre de mon projet, c’était un point essentiel à respecter et une grande partie des tests y était consacrée.

Avec tout cela, on peut donc réaliser des applications avec des interfaces graphiques très riches sans produire beaucoup de code car le pattern MVVM très puissant quand on a compris les bonnes pratiques. J’ai pu aussi m’appuyer sur un MSDN très complet et plutôt bien présenté.

Pour moi, le principal aspect négatif est que le framework manque parfois de composants graphiques ou de propriétés dans les composants existants. Cela a entraîné que j’ai vite eu le besoin de créer des composants « custom ». Un des autres faits est que la plateforme manque encore de contributeurs. J’ai été confronté à quelques problèmes techniques qui n’ont pas trouvé de réponse sur les forums appropriés.  Enfin, j’ai pu constater qu’on obtenait vite de mauvaises performances  si l’application est mal architecturée ou si on ne se soucie pas de décharger un maximum le thread principal.

Après une  expérience de 3 mois sur un projet WPF et un peu de recul, le MVVM que j’ai pratiqué sur WP7 n’était pas optimal (trop de code behind). Il s’avère que, à l’heure actuelle, le framework Silverlight pour WP7 n’est pas complet pour pratiquer un bon MVVM et que si l’on souhaite mettre en place une vraie architecture MVVM, il faut utiliser l’outil MVVM Light Toolkit et complexifier un peu son code.

En conclusion, et pour donner un avis tout à fait personnel, le développement d’applications sur Windows Phone 7 s’appuie sur de bonnes bases (Silverlight pour des interfaces interactives riches, MVVM pattern, environnement de développement complet et pratique),  mais laisse rapidement transparaitre une grosse lacune : le framework WP7 n’est pas assez riche par rapport à ces aînés (Silverlight et .NET). Beaucoup de personnes pourront vite être repoussé par l’étiquette Microsoft, mais pour moi, le développement d’applications sur WP7 est aussi intéressant que le développement sous Android (pour avoir pratiquer les 2). Microsoft doit toutefois, selon moi,  enrichir son framework et l’interface de son OS car elle présente un excès de sobriété.

Nouvelles versions

• Actuellement, on trouve la version de l’OS 7.5 « Mango » : Multitâches complet, IE9, copier-coller, … et la version 7.1 du SDK Windows Phone.
• A venir, l’OS nom de code « Tango » (date inconnue) avec certainement un nouveau SDK.

Les liens utiles

• AppHub, l’incontournable : http://create.msdn.com/en-US
• Le MSDN : http://msdn.microsoft.com/en-us/library/ff402535(v=VS.92).aspx

Voici une question qui revient régulièrement lorsque j’interviens sur des projets.

En avant-propos, vous trouverez ici l’article de la msdn qui présente partiellement le problème. Ce qu’il faut retenir :

• besoin d’afficher une vue liée à une classe du modèle ? une vue fortement typée vous apportera de la productivité via la complétion. La compilation des vues, si vous l’activez, vous apportera de la sérénité dans le refactoring. Les étapes :
  • définir une action du contrôleur qui récupère une instance de la classe du modèle cible et qui transfère cette instance à la vue. On peut utiliser par exemple la méthode View(object). L’objet passé en paramètre correspond à l’instance du modèle.
  • définir une vue fortement typée. Généralement, on utilise la directive  @model dans la vue Razor pour définir le type du modèle qui sera utilisé. Cette instruction permet d’utiliser la propriété WebViewPage.Model et d’avoir la complétion (WebViewPage<T> est un générique).
• besoin d’afficher une vue générique, non liée à une classe du modèle ? une vue faiblement typée apportera simplicité (moins de classe) et/ou dynamicité (possibilité de fournir à la vue des données issues d’une introspection). Les options :
  • utilisation du dictionnaire de données WebViewPage.ViewData. Il s’agit d’un dictionnaire dans lequel les données sont identifiées par une clé de type « magic string ».
  • utilisation du type dynamic avec la propriété WebViewPage.ViewBag. Ce principe a pour conséquence d’alléger la syntaxe  du dictionnaire.

Techniquement il est possible de mixer les approches (vue fortement typée + vue faiblement typée), mais n’est-ce pas le reflet d’un problème de conception ?

Pour ceux qui ne sont pas au courant, du 13 et 16 septembre à Anaheim, California, Microsoft a organisé la conférence BUILD 2011.

L’objectif principal de cette conférence a été le lancement de la future version de Windows 8 et Windows 8 Server. Bien sûr, ce qui nous intéresse est la nouvelle plateforme de développement appelée WinRT (pour Windows Runtime) introduite dans cette version de Windows et qui change (encore une fois!) la façon dont on développe nos logiciels sur Windows. Mais d’abord…

Lire la suite…

Cette classe, comme son nom l’indique, permet au développeur d’exécuter un travail synchrone ou asynchrone dans un thread séparé. Elle offre pas mal d’avantages par rapport aux autres classes bien connues comme le BackgroundWorker comme la possibilité d’annuler une tâche, la possibilité de créer des sous-tâches sous forme arborescente, la possibilité de choisir l’enchaînement des tâches, de lancer des tâches en parallel etc. En échange ce que vous retrouverez dans BackgroundWorker et vous ne retrouverez pas dans Task est la possibilité de rapporter le progrès de l’exécution. Heureusement c’est une fonctionnalité qui est assez facilement réalisable en utilisant encore une classe Task. Cliquez ici pour voir une belle implémentation de comment faire cela. Sur ce blog vous pouvez également comparer deux implémentations équivalentes en utilisant Task et BackgroundWorker.

Task se trouve dans le namespace System.Threading.Tasks. Cette classe et les types associés font partie d’un ensemble de types publics appelé TPL (Task Parallel Library). TPL représente un nouveau modèle de programmation introduit par Microsoft dans .Net Framework 4.

Pour plus d’informations je vous invite à aller visiter MSDN sur la page dediée à TPL (Task Parallel Library).

Je ne vais pas insister avec beaucoup d’exemples de code, mais voici un court exemple issue de MSDN qui montre comment instancier et utiliser une seule instance de la classe Task:

Lire la suite…

L’intégration d’applications spécifiques avec des ERP fait partie du quotidien d’Objet Direct depuis l’intégration avec Viseo.

Dans son article, Ioan nous avait montré comment récupérer des données stockées dans un ERP Dynamics AX depuis une application .NET avec le Business Connector. A mon tour de présenter l’approche proposée par SAP avec son connecteur 3.0, diffusé en début d’année.

Les fondements du connecteur SAP : Remote Function Call

Que ce soit en version 3.0, diffusée en début d’année, ou en version précédente, le connecteur repose sur une approche RFC, Remote Function Call. Des fonctions métier sont implémentées en ABAP et déployées sur un serveur SAP. Les applications distantes utilisent ces fonctions en leur fournissant des paramètres en entrée et en récupérant des résultats. Les aspects techniques tels que les connexions, la sérialisation sont pris en charge par le connecteur, simplifiant ainsi le code des applications distantes.

Contrairement à la version précédente où l’outil générait à partir des fonctions ABAP des classes C# statiques de type proxy, la version 3.0 adopte un modèle plus dynamique qui permet notamment d’accéder à la description des fonctions. Comme nous allons le voir, ce modèle repose essentiellement sur des magic string (API faiblement couplé, noms de fonctions/paramètres résolus par des chaines de caractères).

Plusieurs patterns de messaging sont supportés par le connecteur. Dans cet article, nous détaillerons le pattern request-reply synchrone : l’application .NET invoque une fonction ABAP et attend le résultat.

Dans notre application, un seul serveur SAP est ciblé. Une destination, une instance de RfcDestination permet d’identifier un serveur SAP.  Cette instance est configurée au démarrage de l’application et elle est fournie à notre code applicatif. Je détaillerai dans un autre article les éléments de configuration.

Passons au code :

Nous souhaitons invoqué une méthode ZZ_ECHO dont la description est la suivante

* »———————————————————————-
* »* »Local Interface:
* »  IMPORTING
* »     VALUE(INPUT) TYPE  CHAR1
* »  EXPORTING
* »     VALUE(OUTPUT) TYPE  CHAR2
* »     VALUE(S_OUTPUT) TYPE  ZZOUTPUT
* »  TABLES
* »      T_OUTPUT STRUCTURE  ZZOUTPUT
* »———————————————————————-

Et voici le code C# correspondant :

// récupération d’une Repository qui contient la définition des fonctions
var rfcRepository = RfcDestination.Repository;

// récupération d’un descripteur de fonction correspondant à la fonction ZZ_ECHO disponible sur le serveur SAP
IRfcFunction echoFunction = rfcRepository.CreateFunction(« ZZ_ECHO »);

// la fonction prend en entrée un paramètre de type chaine de caractères nommé « INPUT »
echoFunction.SetValue(« INPUT », « A »);

// invocation de la fonction distante en mode synchrone en fournissant les coordonnées du serveur via l’objet destination
echoFunction.Invoke(RfcDestination);

// récupération du résultat : cette fonction renvoie un paramètre nommé « S_OUTPUT » qui est une structure
IRfcStructure param = echoFunction.GetStructure(« S_OUTPUT »);

// l’un des champs de cette structure est nommé « OUTPUT », c’est une chaine de caractères
var result = param.GetString(« OUTPUT »);

Quelques remarques complémentaires :

1. Plusieurs types de données peuvent être utilisés :
   • types primitifs : chaines de caractères, décimaux, ….
   • type structure : types complexes permettant d’agréger des champs, chaque champ ayant un nom et un type
   • type table : structure permettant de stocker une liste d’éléments, tout comme une table d’une base de données
2. Contrat de fonction documenté : le contrat fourni par les fonctions ABAP doit être clairement détaillé, et notamment le nom et le type des paramètres, les structures et les tables utilisées. En cas de doute, le plus simple est de lancer l’application en mode DEBUG et de positionner un point d’arrêt lorsqu’une instance de IRfcFunction est récupérée. On peut alors visualiser dynamiquement les méta données de la fonction. Mais cela reste moins pratique qu’une description textuelle partagée par toute l’équipe.
3. La repository joue également un rôle de cache : lorsque l’on demande la définition d’une fonction qui est déjà enregistrée dans la repository, aucun appel n’est réalisé sur le serveur SAP

Conclusion :

Ce cas d’école montre comment invoquer une méthode distante déployée sur un serveur SAP. On constate notamment que le code nécessaire reste relativement simple.

J’ai eu l’occasion d’intervenir sur un projet utilisant Entity Framework 4.1 avec une approche Model First. Je profite de ce billet pour faire part de mes premiers retours.

Contexte technique du projet

• une trentaine d’entités, dont une dizaine stéréotypées référentiel
• des règles métier
• un workflow de validation
• une approche domain driven

Rappels sur les principes de l’approche Model First

Je ne vais pas détailler ces rappels car il existe de nombreux articles sur le sujet. Je vous propose celui-ci qui me parait intéressant.

Dans les grandes lignes, le processus de développement consiste en deux étapes :

1. définition d’un modèle du domaine, appelé modèle conceptuel dans Entity Framework. Cette définition est généralement réalisée à partir d’un designer graphique, outil permettant de créer visuellement un pseudo diagramme de classes. Pour les plus courageux (ou quand l’outil a atteint ses limites), il est également possible de modifier le fichier XML sous-jacent. Mais soyons clairs : le fichier de mapping XML de NHibernate est peu complexe par rapport au fichier EDMX proposé par EF !
2. transformations de modèles. A partir du modèle conceptuel, EF nous propose des outils permettant de générer les modèles relationnels et objets ainsi qu’une partie de la couche d’accès aux données. Ces transformations reposent sur les T4 Text Templates, outil simple et efficace de génération de code.

Quelques principes adoptés sur le projet

• Domain driven : un modèle du domaine riche, contraint, contenant notamment les règles métier.
• L’IHM, réalisée avec ASP.NET Web forms et jQuery n’a alors en théorie plus qu’à venir se greffer sur le modèle
• patterns context-per-request et conversation utilisée dans seam
• utilisation partielle du scaffolding pour les entités de référence

Avantages

• Outillage productif intégré dans Visual Studio
• Adaptation de la génération avec les T4Templates. Voici un exemple d’adaptation : partant du principe qu’une contrainte sur le domaine apporte de la richesse et évite des erreurs d’incohérence, j’insiste sur le fait de marquer les contraintes. Si une entité Livre a nécessairement un titre, le constructeur de Livre devrait avoir un paramètre non optionnel « titre » et la visibilité du setter de la propriété « Titre » devrait être réduite. Quelques lignes dans le T4Template et cette règle est généralisée à l’ensemble du domaine !
  

  Relation ManyToOne requise

• Refactor facilité : Approche agile, permettant de refactorer pour améliorer la sémantique du domaine et donc sa compréhension. Le travail à réaliser est opéré sur le modèle conceptuel. Domaine, repository, schéma de BD sont générés : ça ne coute donc presque rien. Un peu de rework est parfois nécessaire dans les couches supérieures, en fonction du refactor apporté.

Limites rencontrées

• Mécanisme de Facets non extensible. Les Facets permettent d’apporter des précisions sur les propriétés des entités : par exemple si la propriété est Nullable, sa longueur maximale… Certaines facets sont manquantes, typiquement la facet unique. Certes, les équipes de Microsoft travaille dessus, mais je doute qu’ils puissent couvrir tous les cas de figures. Ce qui je pense pourrait être intéressant, serait introduire un point d’extension permettant aux développeurs de définir de nouvelles Facets. Les développeurs pourraient alors exploiter ces Facets dans les templates.
• Méta données des entités non extensibles. Certaines entités jouent des rôles particuliers, nécessitant une implémentation qui leur est propre. C’est par exemple le cas des entités de référence (les unité de mesure, les catégories de produits, …). Ces entités ont une particularité : les interfaces d’administration sont des interfaces de type CRUD. Le scaffolding est une bonne option pour ce type d’interface. Pour l’activer, il faut tagguer les classes C#. Je trouve dommage qu’on ne puisse pas tagguer ces entités directement dans le modèle avec une annotation custom. Dans l’exemple, l’annotation aurait été Referential. Dans la transformation de modèle, on aurait alors pu rajouter une règle : toutes les entités stéréotypées Referential supportent le scaffolding. A défaut, nous avons utiliser le mécanisme des classes partielles pour apporter cette information. 
  
• Stratégie d’héritage globale : il existe plusieurs stratégies pour mapper un héritage objet dans un modèle relationnel (table par type, table par classe concrète, table par hiérarchie). Le choix d’une stratégie doit être traitée au cas par cas : dois-je privilégier la performance sur une requête polymorphe ? dois-je promouvoir le faible couplage ? Malheureusement dans l’outil, le choix est unique pour tout le modèle . La encore, un mécanisme d’extension de type stéréotype aurait été le bienvenu.
• Namespace globale. Actuellement avec l’outil, on ne peut définir qu’un seul Namespace pour un modèle EDMX.

Ma conclusion

Je trouve cette approche productive pour des projets nécessitant peu de spécificités (comprendre sortir du cadre prévu par Microsoft) et dont la complexité du modèle du domaine reste raisonnable. Comme toutes les approches Model Driven, la modification des templates n’est intéressante que si le nombre d’entités est significatif . La limite majeure pour des projets plus conséquents, c’est le manque de points d’extension. Je terminerai par un dernier constat qui est également vrai pour les outils de ce type : ne pas se laisser berner par la facilité apparente !

Industrialiser, faciliter le développement d’une application Web en utilisant un outillage adapté au projet est appréciable. De manière générale, limiter les tâches à faible à valeur ajoutée, par exemple en les outillant, est une bonne pratique reprise dans les méthodes dites « agiles », telles que Scrum, ou bien XP.

Dans le cycle de vie d’une application Web, le packaging et le déploiement sont de bons candidats à l’automatisation. C’est d’autant plus vrai si l’équipe travaille par itération, en livrant une version régulièrement (sur nos projets, c’est généralement 3 semaines).

Visual Studio 2010 va nous aider à faciliter ces déploiements. En réalité, Visual Studio fournit une interface permettant de configurer une brique disponible sur iis.net : le web deploy. L’objectif de cette brique est de packager une application Web, en fournissant des scripts d’installation, en permettant d’inclure par exemple des scripts SQL de création de table ou d’insertion de données. L’ensemble des livrables est rassemblé dans un répertoire. Pour déployer sur une machine distante, il faut copier ce répertoire sur la machine cible et lancer le script. Pré-requis sur la machine cible : web deploy doit être installé.

Détaillons le travail à réaliser dans Visual Studio.

Première étape : configurer le packaging d’un projet de type application Web.

Lancement de la configuration du packaging d'un projet de type application Web

Deuxième étape : configurer le packaging

Configuration du packaging

Cet écran de configuration permet notamment d’indiquer :

• la configuration du build. Généralement, on lance l’application en mode Debug lors du développement, ce qui permet d’avoir entre autres choses des traces d’exécution. En revanche, le déploiement sur l’environnement de production est réalisé en mode release. Web deploy permet de définir des paramètres différents selon la configuration souhaitée. L’exemple type, c’est la connexion à la base de données dont les paramètres sont différents en mode développement ou en mode production.
• l’URL cible d’accès à l’application Web. Dans notre exemple, si le site par défaut IIS est un serveur localhost, l’application cible sera disponible sous  http://localhost/ProtoGraphique_deploy
• les fichiers SQL à exécuter sur le serveur de base de données avant de lancer l’application : création du schéma de base de données, insertion des données de référence, …
• le chemin où notre livrable sera disponible. Parmi les livrables, figurera un script à exécuter en ligne de commande sur le serveur. Ce script peut être lancé avec l’option /T qui simulera le déploiement. Pour réellement jouer le déploiement, il faut exécuter le script avec /Y. Il est également possible de jouer le déploiement directement à partir de IIS manager, avec la commande « Import »

Une fois la configuration terminée, il reste à sélectionner la configuration de build souhaitée dans l’IDE et d’exécuter la commande « Build Deployment Package », disponible dans le menu présenté ci-dessus.

Derrière cette interface, plusieurs fichiers texte sont générés. Ils peuvent d’ailleurs être édités manuellement comme le décrit cet article. Je vous rassure, ce n’est pas le cas d’usage. En revanche, le fait que tout ce mécanisme soit décrit dans des fichiers texte offre deux avantages :

1. les fichiers peuvent être stockés dans le gestionnaire de sources et partager par toute l’équipe
2. si vous avez un mécanisme d’intégration continue, que ce soit avec Team Foundation Server ou avec une usine logicielle libre telle que Jenkins, la génération du packaging peut être automatisée !

J’avais présenté succinctement NuGet dans ce billet, en montrant comment importer une librairie externe par un simple click droit.

Il est également possible de travailler en ligne de commandes, en ouvrant le Package Manager Console (Tools > Library Package Manager). Le premier point d’entrée : « get-help NuGet », qui permet de connaitre l’ensemble des commandes disponibles. En voici quelques-unes:

• Install-Package
• Uninstall-Package
• Get-Package, avec notamment le paramètre -Remote permettant de lister les packages disponibles en ligne
• Update-Package
• …

Vous pouvez retrouver le détail de ces commandes ici.

On m’a récemment demandé un avis sur l’architecture d’une application Windows écrite en .NET. Bien que l’exercice soit toujours difficile car cela dépend bien évidemment du contexte, je profite de ce billet pour donner quelques pistes de réflexions quand au choix des briques logicielles. Le demandeur venant du monde Java, mon discours sera orienté dans ce sens.

• Outil de mapping objet relationnel : à mon sens, il y a aujourd’hui 2 alternatives en .NET :
  1. NHibernate, le cousin germain de Hibernate. Pour éviter la configuration dans les fichiers XML, je conseille le mode fluent ainsi que l’API de requêtage  LINQ . Un début de présentation est disponible ici. Sinon, il y a aussi les slides de la formation en soirée qui a été animée l’automne passé.
  2. Entity Framework. La dernière version reprend des principes de NHibernate, dont notamment la programmation par POCO (Plain Old C# Object), le lazy loading (chargement tardif). Comme je le mentionnais dans ce billet, plusieurs modes sont disponibles : Database first, Model First et maintenant Code First, très proche de Fluent NHibernate. Un atelier en soirée aura lieu fin mai sur ce thème.
• Spring.NET : je trouve la question délicate, car cela dépend vraiment du besoin (IoC, programmation par aspects, boîte à outils,  framework MVC …). Comme son cousin Java, c’est une véritable boîte à outils très (trop ?) riche. Cette richesse est parfois synonyme de complexité et de lourdeur, par rapport à d’autres conteneurs IoC tels que NInject, Autofac, StructureMap, Castle Windsor ou Unity. Son principal inconvénient était sa configuration « XML based ». Ce point devrait être adressé avec la sortie de CodeConfig. Sa proximité avec son cousin est souvent un critère de choix pour des équipes mixtes (Java/NET).
• NUnit : très proche de son cousin Java JUnit, il est également basé sur des attributes. Dans le monde ouvert, j’apprécie également MBUnit maintenant inclus dans le framework Gallio. Pour intégrer ces frameworks open-source dans un IDE tel que Visual Studio, je conseille test driven.net. Microsoft fournit également son propre framework,  qui ressemble beaucoup à NUnit et qui est très bien intégré dans Visual Studio. J’avoue l’utiliser très souvent. J’aime particulièrement la structuration par projet, qui fonctionne également pour tester des classes « internal ». J’aime également la facilité avec laquelle on peut écrire des tests orientés données, en prenant un fichier CSV pour indiquer les paramètres d’entrée et les paramètres de sortie.
• Un équivalent à Mockito. Ne l’ayant pas utilisé sur un projet, la réponse risque d’être déplacée. Néanmoins, j’utilise parfois moq ou NMock. Je suis preneur d’un comparatif
• Pour la base de données, encore une fois je penche pour la facilité d’intégration et donc pour une solution SQL Server Express, ou SQL Server Compact, selon l’usage. Les deux solutions sont gratuites.

Je termine par un outil que je trouve très utile, qui est maintenant intégré à Visual Studio 2010 SP1 et qui permet de gérer des librairies externes, un maven like light : NuGet.

Je profite de ce billet pour diffuser l’annonce de la sortie de Entity Framework 4.1.

Entre autres choses, cette version inclut le mode « code first » que j’avais présenté ici. De fait, Entity Framework supporte maintenant trois approches :

1. Database First : approche initialement utilisée par EF dans laquelle nous travaillons sur un modèle relationnel pour en déduire les modèles conceptuel et objet.
2. Model First : approche implémentée dans EF 4 dans laquelle nous travaillons sur un modèle conceptuel. A partir du modèle conceptuel et de templates  personnalisables, les modèles objet et relationnel sont générés.
3. Code First : on écrit d’abord des bonnes vieilles classes C#, les modèles conceptuel et relationnel sont déduits de classes de mapping, basées sur des expressions Lambdas.

Pour les ingénieurs d’Objet Direct Grenoble, nous aurons l’occasion de revenir sur les fonctionnalités apportées par cette version lors de la présentation technique qui aura lieu fin mai.