Grâce à la DropBox pour Sharepoint, Stephane Eyskens vous propose de pouvoir associer des documents directement à votre profil sous Sharepoint, par simple glisser-déplacer.

La DropBox intègre également une gestion des quotas.

Toutes les informations dans la vidéo explicative, la doc, et l’article blog associé.

Voici le premier tutoriel de la série d’articles qui introduit les technologies de développement actuelles, dans le cadre d’un projet de gestion de cave à vins.

Je ne fournirai probablement pas tout le projet en pas à pas de manière exhaustive, mais j’essaierai de le faire pour toutes les parties clés.
Les tutoriels figurent à part des articles classiques pour que les étapes ne soient pas noyées dans la théorie et soient ainsi plus faciles à suivre.
Je vous conseille vivement de lire l’article technique qui replace le tutoriel dans le contexte du projet avant d’attaquer l’implémentation :

1. Développer un projet aujourd’hui : comment faire, par où commencer ?
2. Architecture et découpage du projet
3. Stockage des données avec Sql Server, EF Code First et Azure (article correspondant à ce tutoriel )
4. La publication des données
5. La migration dans Azure
6. L’application Windows Phone basique
7. Ajout de la fonction d’aide à l’achat
8. Ajout des notifications sur les vins en promotions
9. L’application Silverlight

Tutoriels:

- CaveAVins Tutoriel 1 : L’accès aux données avec Sql Server et EF Code First (vous êtes ici )
- CaveAVins Tutoriel 2 : La publication des données en OData avec WCF Data Services 
- CaveAVins Tutoriel 3 : Migration d’une base SQL Server vers SQL Azure
- CaveAVins Tutoriel 4 : Hébergement du service WCF Data Services dans Azure

Dans ce tutoriel, nous utiliserons Entity Framework Code First pour décrire notre modèle objet de données par code, sous la forme d’objets simples (POCO).
Entity Framework utilisera ces classes pour en déduire une structure de base de données qu’il créera automatiquement dans Sql Server.

Je montrerai volontairement une manière très basique d’utiliser Code First et Entity Framework car le but de cet article n’est pas d’approfondir cette technologie mais de présenter ce qu’elle permet de faire.
Pour approfondir le sujet et aller plus loin : cliquez ici

A la fin de ce tutoriel, nous aurons réalisé une couche de données grâce à une base de données dans Sql Server et son mapping ORM.

Pour faciliter la mise en pratique de ce tutoriel, nous commencerons par mettre en place les données dans Sql Server, pour les faire migrer plus tard dans Sql Azure. Ainsi, nous obtiendrons un projet qui fonctionnera aussi bien On Premises que dans le Cloud. Cela permettra également de montrer la simplicité avec laquelle des solutions existantes peuvent évoluer vers un hébergement Cloud.

Téléchargez les sources:

Les prérequis

Pour ce tutoriel, vous aurez besoin d’installer :

- Visual Studio 2010 Express, Premium ou Ultimate (pour tester les diagrammes d’architecture, Use Case, …)

- Entity Framework 4.1

- EF Power Tools (CTP 1).

Création de la solution Visual Studio

Démarrez Visual Studio 2010 et créez une nouvelle solution vide que vous appellerez CaveAVins:

Ajoutez un projet de type Class Library appelé CaveAVins.Db:

Ajoutez une référence vers Entity Framework 4.1:

Création des classes de données

Avec Entity Code First, on définit directement par code les classes à partir desquelles le moteur de mapping déduira et génèrera la structure de la base de données.

Voici le diagramme des classes que nous allons créer:

Ajoutez les classes suivantes au projet:

Fichier Wine.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace CaveAVins.Db
{
    public class Wine
    {
        public int WineId { get; set; }
        public string Name { get; set; }
        public int Year { get; set; }
        public string PictureUrl { get; set; }
        public string Address { get; set; }
    }
}

Fichier MyWine.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace CaveAVins.Db
{
    public class MyWine
    {
        public int MyWineId { get; set; }
        public string Review { get; set; }
        public int Notation { get; set; }
        public int Count { get; set; }
        public Wine WineInfos { get; set; }
    }
}

Remarquez que les classes sont de simples POCOs et ne possèdent pas d’attributs particuliers. Nous utilisons la convention de nommage par défaut : la propriété de la classe dont le nom est suffixé par “Id” sera interprété comme la clé de la table correspondante dans la base de données.
Il y a différents moyens de configurer le mapping de manière plus avancée, avec des custom attributes ou fluent.

Fichier CaveAVinsContext.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Entity;

namespace CaveAVins.Db
{
    public class CaveAVinsContext : DbContext
    {
        public DbSet<MyWine> Bottles { get; set; }
        public DbSet<Wine> Wines { get; set; }
    }
}

Cette fois, nous utilisons des objets spécifiques à Entity : DbContext et DbSet pour le définition des entités. La classe CaveAVinsContext matérialise le contexte d’accès aux données. La première fois que l’on utilisera le contexte, la base de données sera créée. Pour cela, nous allons ajouter un projet de type Application Console, qui nous servira uniquement à faire un premier accès au contexte pour forcer la création de la base.

Génération de la base de données

Ajoutez un projet de type Application Console:

Ajoutez une référence  à Entity Framework 4.1 comme pour le projet précédent, et ajoutez également une référence au projet CaveAVins.Db:

Complétez le Main par le code suivant, qui ajoute une ligne dans la table des vins Wines.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Entity;

namespace CaveAVins.Db.Setup
{
    class Program
    {
        static void Main(string[] args)
        {
            Database.SetInitializer<CaveAVinsContext>(new DropCreateDatabaseIfModelChanges<CaveAVinsContext>());

            using (var db = new CaveAVinsContext())
            {
                if(! db.Wines.Any())
                {
                    var wine = new Wine() { Name = "Test" };
                    db.Wines.Add(wine);
                    db.SaveChanges();
                }
            }         
        }
    }
}

Définissez le projet de type console comme projet de démarrage (clic droit sur le projet : Set as Startup Project).

Compilez et exécutez la solution.

La première ligne Database.SetInitializer<CaveAVinsContext>(new DropCreateDatabaseIfModelChanges<CaveAVinsContext>());
permet de supprimer la base de données si elle existe déjà (pour ne pas déclencher d’exception, dans le cas où vous exécuteriez plusieurs fois l’application alors que vous avez modifié la structure des données).

Vérification

Si tout s’est bien déroulé, la base de données a été créée. Pour le vérifier, ajoutez une nouvelle connexion dans l’explorateur de serveurs de Visual Studio:

Entrez “.\SQLEXPRESS” pour Server Name et choisissez le nom de la base de données CaveAVins.Db.CaveAVinsContext qui devrait apparaitre dans la liste déroulante.

Et voici notre base de données ! :

Avec notre unique ligne dans la table Wines:

Pour faciliter la manipulation et la maintenance de votre mapping de type Code First, vous pouvez télécharger les EF Power Tools (CTP 1) accessibles dans l’extension Manager de Visual Studio.

Redémarrez Visual Studio et rechargez la solution.

Faites un clic droit sur le fichier CaveAVinsContext.cs, sélectionnez Entity Framework/View Entity Data Model

Le modèle objet apparait par dans l’outil de modélisation de Visual Studio .

Conclusion

Voici notre architecture actuelle:

Téléchargez les sources:

La prochaine étape sera la publication des données en OData avec WCF Data Services. Les données seront ainsi accessibles par les applications clientes, ou par des services métiers de plus haut niveau qui pourront être hébergés dans Azure.

Dépassé par les technos ? Pas le temps de faire de veille ? Trop de boulot pour passer du temps à vous former sur ce qui ne vous concerne pas directement ? 
Un nouveau projet à démarrer ?

Et quand bien même vous décideriez de remettre le pied à l’étrier et rattraper le temps perdu, par où allez-vous commencer ? 
Creuser les technos une à une, sans savoir vraiment comment elles se positionnent dans le cadre d’un projet concret…avouons que c’est assez décourageant.

Cette suite d’articles se propose d’introduire les techniques de développement actuelles, dans le cadre d’un besoin et d’un projet concret. 
Notre prétexte métier est un projet de gestion de cave à vins, avec des applications pour le poste de travail et pour Windows Phone. 
Retrouvez la description du besoin dans le premier article de la série.

Pour faciliter la mise en pratique de la série de tutoriels, nous commencerons par mettre en place un fonctionnement OnPremises, pour faire migrer la solution plus tard dans Sql Azure. Ainsi, nous obtiendrons un projet qui fonctionnera aussi bien On Premises que dans le Cloud. Cela permettra également de montrer la simplicité avec laquelle des solutions existantes peuvent évoluer vers un hébergement dans Azure. 

Rappel de l’architecture visée

- L’hébergement des données, des services et applications se fera dans Windows Azure et Sql Azure
- La publication des données sera faite en OData avec WCF Data Services pour rester interopérable avec une grande variété de plateformes clientes
- Les applications clientes seront développées en Silverlight
- Nous nous efforcerons de conserver un maximum de code commun entre les 2 applications grâce à la Portable
Library
- Les promotions seront notifiées sur le téléphone par un service de gestion des promotions et des notifications Push

Nous commençons par nous intéresser au stockage des informations puisque c’est autour des données que va structurer notre solution.

Le stockage des données se fera dans une base de données relationnelle “cloud” de Microsoft : Sql Azure.
Le choix du “cloud” et de la plateforme Azure en général est étayé dans l’article précédent, au chapitre “Hébergement des données, des services et des applications”.

Avant de partir tête baissée vers une solution Azure, il est prudent de vérifier le cout financier qu’engendre ce choix. Plusieurs outils sont à votre disposition pour vous aider à l’évaluer:

- Pricing Calculator pour déterminer le cout mensuel des éléments Azure utilisés
- TCO Calculator pour une estimation du ROI

Mais avant de choisir quels éléments de la plateforme vont nous êtes utiles, il faut déterminer les types d’informations dont nous aurons besoin.

Pour ne pas alourdir les articles, nous partons sur un scénario simplissime.

Un vin est défini par:

• un nom

• une année

• une photo de la bouteille

• une adresse de producteur

Une cave à vin est définie par une liste de vins avec pour chacun:

• un nombre de bouteilles

• une note et un commentaire

A ce stade, nous n’intégrons pas de gestion des utilisateurs dans le système et donc les notations seront anonymes. Nous pourrons envisager d’utiliser des comptes d’identité existants (Live, Google, Facebook, …) grâce à Access Control Services (ACS) disponible dans Azure AppFabric. Cela évitera à l’utilisateur de créer un énième compte qui serait spécifique à cette application, et nous libère de l’aspect gestion des comptes, stockage de mots de passe.

Toutes ces informations sont de type simple et peuvent potentiellement servir de critères de filtre…sauf une et non des moindres : la photo de la bouteille de vin !
Nous pourrions imaginer stocker les photos directement dans la base de données sous la forme d’un type binaire, mais dans la plupart des cas c’est une mauvaise idée pour différentes raisons dont:

• la taille des images fait rapidement grossir la base, sans pour autant que ce contenu puisse bénéficier du moteur de requêtage : pas mieux que des fichiers plats
  
• le tarif d’une base de données dépend souvent de sa taille et c’est la cas pour Sql Azure (cf point précédent )

• pas de possibilité d’accéder directement aux images sans passer par le serveur de BDD

Heureusement, Azure propose plusieurs autres mécanismes de stockage de données, dont le Blob, qui nous permettra de stocker les images comme des fichiers plats.
Un autre avantage du blob pour les fichiers volumineux  : l’option CDN (Content Delivery Network) qui permet d’optimiser l’accès aux données stockées dans les blobs par un mécanisme de cache réparti géographiquement.
Pour finir de vous convaincre, voici la différence de tarif estimée avec Pricing Calculator entre :

- un stockage Sql Azure pur de 11 Go

- un stockage Sql Azure de 1 Go pour les données et Blob de 10 Go pour les photos

Ce qui nous donne $199.80 contre $11.49 par mois : à nous les blobs !

Nous aborderons dans un prochain post d’autres éléments qui entrent en ligne de compte dans la facturation.

Structure des données

A présent, définissons la structure des données que nous stockerons dans la base. Mais avant de se lancer dans du bon vieux Merise , voici une précision complémentaire:

Si une base de données est composée de tables et de relations, notre code est écrit dans un langage orienté objet où les données sont représentées par des collections d’objets. Pour permettre cette transformation qui n’est pas très naturelle, il existe des technologies dites de “mapping objet-relationnel'” (ORM pour Object Relational Mapping). Un outils ORM permet d’effectuer cette transformation dans un sens comme dans l’autre : de la base de données relationnelle vers un modèle objet et inversement.

Il y avait pourtant bien une vie avant l’ORM, non ?

Ben oui, comment faisait-on avant de direz-vous ? Eh bien on se fabriquait son propre mapping (voir framework de mapping) à partir d’objets d’accès aux bases de données tels que ADO.Net.
En résumé, on le faisait soi-même sans le savoir !
L’inconvénient dans ce cas, c’est que le code de notre application est fortement lié à la structure de la base de données. De plus, les requêtes dont écrites en SQL qui n’est pas compilé, ce qui entraine de risques d’erreurs non contrôlées, à l’exécution.

Microsoft propose 2 technologies de type ORM pour Sql Server/Azure:

• Linq To Sql
• Entity Framework

Entity Framework est plus souple et plus complet que son homogue car il permet de réaliser des mappings complexes. En effet, alors que Linq To Sql permet un mapping 1 table <-> 1 classe, Entity Framework dispose d’une couche d’abstraction intermédiaire : 1 classe <-> un modèle conceptuel <-> des tables.
Cela peut sembler plus complexe, mais dans les faits, même pour des scenarios de mapping simples, la complexité de mise en oeuvre est la même pour les 2 technologies : clic clic clic dans Visual Studio .
C’est pourquoi Linq To Sql tend à être de moins en moins utilisé dans les nouveaux projets, même simples : la mise en oeuvre est la même que pour Entity tout en laissant la porte ouverte à des évolutions plus complexes de votre scenario d’accès aux données.

Avec l’un comme l’autre, vous pourrez utiliser Linq pour requêter vos données à la source. En effet, c’est le provider approprié qui transformera votre requête Linq en SQL !
Pour les stressés (qui ont parfois raison de l’être ), il est possible d’être plus intrusif pour vérifier et contrôler comment cette transformation est effectuée mais ce n’est pas le sujet de cet article.

Mais pourquoi parler d’ORM avant même d’avoir créé la structure de la base de données ?

Avec Entity Framework 4.1, lorsque l’on souhaite créer une base de données, il est possible d’adopter 3 approches:

- Database First : Créer la base de données, les tables, relations, contraintes d’intégrité dans Sql Server/Azure et en déduire le modèle objet et les classes correspondantes

- Model First : Créer le modèle de données (entités, propriétés de navigation, …) dans le designer Visual Studio et en déduire la structure de la base de données ainsi que les classes correspondantes

- Code First : Créer les classes, propriétés par code et en déduire le modèle relationnel correspondant et la structure de la base de données.

Il n’y a pas de bon ou mauvais choix. Tout dépend de la complexité de votre modèle de données, du fait que vous partez de 0 et de votre sensibilité (plutôt profil dev ou DBA ?).
Dans le cas de notre cave à vins, la structure est assez simple et je n’ai pas d’existant. J’ai donc envie d’utiliser l’approche Code First, c’est à dire de créer des classes POCO (Plain Old CLR Object)…parce que j’aime bien maitriser mes classes et qu’elles aient le moins de dépendances possible, pour pouvoir éventuellement les exposer et/ou les réutiliser dans des projets qui n’utiliseraient pas Entity. Cette approche vous plaira certainement si vous avez déjà des classes existantes.

D’un point de vue plus pragmatique, la pure codeuse que je suis reste plus à l’aise et plus rapide à taper du code que de faire clic clic dans l’éditeur pourtant très convivial de Visual Studio .

Par contre, l’approche Code First est assez récente et tous les outils ne sont pas encore disponibles en version finale : si vous êtes frileux, vous pouvez tout à fait tabler sur l’une des 2 autres approches qui ont plus de vécu.

Création de la couche de données : Sql Server et Entity Framework

Voici le tutoriel (écrit à part pour ne pas alourdir cet article) qui vous permet de réaliser:

- la création des classes de données en utilisant la syntaxe Code First
- la création automatique de la base de données grâce au mapping ORM d’Entity Framework

A partir des classes dont voici le diagramme:

Entity déduit le modèle suivant:

Et crée automatiquement les 2 tables correspondantes dans une base de données Sql Server.

Architecture réalisée à ce stade

Version On Premises (suite au tutoriel 1)

Version Cloud (après migration de la base de données)

 Pour faciliter la mise en pratique de la série de tutoriels, nous commençons par mettre en place un fonctionnement OnPremises, pour faire migrer la solution plus tard dans Sql Azure. Ainsi, nous obtiendrons un projet qui fonctionnera aussi bien On Premises que dans le Cloud. Cela permettra également de montrer la simplicité avec laquelle des solutions existantes peuvent évoluer vers un hébergement dans Azure.

A suivre…

La prochaine étape sera la publication des données en OData avec WCF Data Services. Les données seront ainsi accessibles par les applications clientes, ou par des services métiers de plus haut niveau qui pourront être hébergés dans Azure.

Tutoriels:

• CaveAVins Tutoriel 1 : L’accès aux données avec Sql Server et EF Code First (tutoriel correspondant à cet article )
• CaveAVins Tutoriel 2 : La publication des données en OData avec WCF Data Services
• CaveAVins Tutoriel 3 : Migration d’une base SQL Server vers SQL Azure
• CaveAVins Tutoriel 4 : Hébergement du service WCF Data Services dans Azure

Dépassé par les technos ? Pas le temps de faire de veille ? Trop de boulot pour passer du temps à vous former sur ce qui ne vous concerne pas directement ?
Un nouveau projet à démarrer ?

Et quand bien même vous décideriez de remettre le pied à l’étrier et rattraper le temps perdu, par où allez-vous commencer ?
Creuser les technos une à une, sans savoir vraiment comment elles se positionnent dans le cadre d’un projet concret…avouons que c’est assez décourageant.

Cette suite d’articles se propose d’introduire les techniques de développement actuelles, dans le cadre d’un besoin et d’un projet concret.
Notre prétexte métier est un projet de gestion de cave à vins, avec des applications pour le poste de travail et pour Windows Phone.
Retrouvez la description du besoin dans le premier article de la série.

Développer un projet aujourd’hui : comment faire, par où commencer ?
1. Architecture et découpage du projet (vous êtes ici )
2. Le Stockage des données
3. La publication des données
4. La migration dans Azure 
5. L’application Windows Phone basique
6. Ajout de la fonction d’aide à l’achat
7. Ajout des notifications sur les vins en promotions
8. L’application Silverlight

Une série de tutoriels accompagnera ces articles pour mettre en place la solution from scratch.

Les cas d’utilisation

A ce stade, nous pouvons en tirer le schéma suivant, qui reste plus fonctionnel que technique:

Affinons quelque peu ce besoin en nous intéressant aux cas d’utilisation des applications :

La gestion de sa cave à vins (ajouter/supprimer une bouteille/choisir une bouteille dans sa cave) se fera plus naturellement à partir du téléphone, tout simplement parce qu’on l’a toujours sous la main : pas besoin de démarrer la machine, ouvrir une session, démarrer l’application…soyons honnêtes, une cave à vins sur une application PC sera rarement à jour. De plus, l’ajout d’une bouteille dans la cave se fait en prenant la bouteille en photo, donc encore une fois avec le téléphone.
De la même manière, les notifications de promotions sont pertinentes sur le téléphone, puisque c’est bien lorsque l’on part faire ses courses que l’on a envie de connaitre les promotions du moment.
A l’inverse, le grand écran de notre poste de travail sera très pratique pour se balader dans le catalogue complet des vins et visualiser une grande quantité de données selon des critères et des filtres que l’on aura précisé.

Dans un premier temps, nous répartissons donc nos cas d’utilisations entre les 2 plateformes, de la manière suivante :

Avec Visual Studio 2010 Ultimate, vous avez la possibilité de créer des diagrammes d’architecture, bien pratiques pour la gestion et la documentation de votre projet.
A ce stade, il est recommandé de faire un diagramme de Use Case (disponible aussi dans la version Premium de Visual Studio) qui reste très général. Le but est de garder une trace des fonctionnalités principales de chacune des applications, qui pourront être complétées par des use cases plus détaillés au fil de l’analyse.
Cela permet également de se poser les bonnes questions ! 
Ici par-exemple, le vendeur de vin va pouvoir lancer des campagnes de promotions, mais…nous n’avions pas prévu de composant permettant au vendeur d’interagir avec le système…
Ce genre d’oubli arrive assez fréquemment, et les diagrammes de use cases sont l’occasion de clarifier le besoin et les différents éléments du système, en accord avec le marketing ou le client.
C’est d’autant plus important de ne rien oublier, que l’on doit commencer souvent bien vite (trop vite) à plancher sur un chiffrage .

Nous ajoutons donc un élément du système en charge de la gestion des promotions : Promotions Service.

Maintenant que le besoin est identifié, voyons comment architecturer notre développement.

Architecture

Les applications clientes

Nous avons besoin d’évaluer les possibilités en terme de technologie pour le développement des applications. 
Plusieurs technologies pourraient potentiellement répondre à mon besoin:

- WPF
- Silverlight
- Html5

WPF

J’élimine immédiatement WPF car cette techno présente plusieurs inconvénients dans notre cas:
- Je ne peux pas développer en WPF sur Windows Phone, donc cette techno serait réservée à l’application PC.
- Comme notre application est publique, il vaut mieux partir sur une technologie web, c’est à dire une application qui ne nécessite pas d’installation spécifique et qui s’exécutera dans un navigateur. Ce n’est pas le cas de WPF pour lequel il faut prévoir une procédure de déploiement (jeu d’installation).

Un gros avantage d’une technologie web, est que les mises à jour successives de l’application sont transparentes pour l’utilisateur. Dans le cas d’une application lourde, il faudrait notifier les utilisateurs à chaque nouvelle version, pour qu’ils réinstallent l’application (quoique cette procédure peut être allégée si on utilise des mécanismes tels que ClickOnce).
WPF reste une technologie de choix pour le développement d’applications d’entreprise, qui pourront bénéficier du maximum de fonctionnalités avec un accès complet à .Net et aux périphériques locaux.

Silverlight

Avec Silverlight 5, on atteint un bon compromis fonctionnel et technique grâce à une technologie web qui se rapproche de plus en plus de WPF : mode out of browser, accès aux API non managées par P/Invoke,  mode plein écran, accès aux ressources locales de la machine et au disque dur pour les applications signées…
Silverlight fonctionne dans les principaux navigateurs (IE, Safari, Firefox, Chrome) et tourne aussi sur Mac.
Sur Windows Phone, Silverlight est la techno de développement la plus adaptée pour les applications et permet donc de mettre à contribution les mêmes connaissances sur les 2 plateformes.
Avec Mango – la nouvelle version de Windows Phone disponible à l’automne 2011 -, c’est la version 4 de Silverlight qui sera disponible. (Elle prend mieux en charge certains éléments dont nous aurons besoin comme le client WCF Data Services pour l’accès aux données).

Html5

Html5 apporte quant à lui la facilité de déploiement sur des plateformes hétérogènes et donc une excellente portabilité. Malheureusement, cette technologie pêche encore grandement par son manque d’outillage. Ses spécifications ne sont pas encore finalisées et si les plateformes clientes sont adressées facilement, c’est bien la compatibilité de l’application avec les différents navigateurs qu’il va falloir vérifier. Cela doit être pris en charge directement dans notre code et entraine un surcout sensible de la phase de tests.
En effet, l’interopérabilité d’Html5 se paie par le fait que le rendu final dépend de l’implémentation qui est faite par le navigateur…et qui serait donc potentiellement différent (ou pas !) pour chaque navigateur. Là où le plug-in Silverlight garantit un rendu identique cross-browser, Html5 nécessite d’être testé sur chaque navigateur et même sur chaque version d’un même navigateur. En fonction des résultats, il faudra prévoir des mécanisme de “fallback” dans le code, c’est à dire de mode dégradé pour les éléments Html5 mal interprétés ou non supportés.

Dans tous les cas, même si je décide de partir sur Html5 pour développer une application unique disponible sur mes différents devices (PC, tablette, téléphone, …), le facteur de forme sera très différent en fonction du device et je serai certainement obligée de faire un développement spécifique pour la partie UI pour garantir une bonne expérience utilisateur.
Au final, ce que l’on a vraiment intérêt à factoriser ce sont les cas d’utilisation communs, le modèle, l’accès aux données et aux services métier !!!

Choisir aujourd’hui, ne signifie pas que l’on se trompe pour demain

Aujourd’hui, sans hésiter, je me tourne vers Silverlight puisque cette technologie me permet de développer pour Windows Phone ainsi que pour PC/Mac.
La productivité est excellente grâce à des outils, frameworks et contrôles très évolués et les techniques de développements me sont familières (.Net, XAML, …).
Les ergonomies de chacune des applications seront différentes mais les cas d’utilisation communs pourront être factorisés.
Rien ne m’empêche de développer une nouvelle application par la suite, dans une technologie différente (application Html5 pour une tablette par exemple), qui saura tirer parti du code fonctionnel que j’aurai écrit côté serveur.
Ainsi, on garde la notion d’interopérabilité au mieux entre les clients ayant des plateformes compatibles (assembly ou code commun), et au minimum entre le client et le serveur (services web interopérables, http REST, …).

D’où l’intérêt de bien réfléchir à la répartition du code métier entre le client et le serveur.

L’accès aux données

On souhaite une technologie d’accès aux données interopérable : c’est bingo avec OData et WCF Data Services qui permet justement de publier des données manipulables et requêtables à la source par toutes sortes de plateformes clientes. Petite piqure de rappel : Mais c’est quoi à la fin OData ?

Toute plateforme qui sait communiquer via http et parser un flux xml sera capable de requêter et manipuler ces données.
La publication des données en OData nous permet de respecter la notion d’interopérabilité entre les clients et le serveur, ce qui laisse la possibilité à de futures applications d’y accéder facilement quelle que soit la plateforme utilisée.

Plus de détails sur cette partie dans l’article qui lui est consacré.

Restent à positionner les services fonctionnels qui s’appuieront sur la couche d’accès aux données et qui seront utilisés par les différentes applications clientes.
Le but sera de pouvoir réutiliser au maximum les cas d’utilisation communs dans les 2 applications pour ne pas coder, tester et maintenir n fois la même fonction dans n applications. La répartition de ces services entre le côté client et le côté serveur se fera lors de l’analyse plus poussée dans les articles suivants.

Les services développés côté serveur devront pouvoir être utilisés par les différentes plateformes clientes (services web interopérables).

Pour la partie cliente, les versions de Silverlight ne sont pas les mêmes sur les différentes plateformes qui partageront du code :

- pour WP7, on utilise une version basée sur Silverlight 3
- pour Mango qui sortira cet automne, mais dont les outils de développement sont déjà disponibles en version bêta, c’est Silverlight 4
- pour le poste de travail, c’est Silverlight 4 ou Silverlight 5 en version bêta

A cet effet, le nouveau type de projet : Portable Library permet de partager du code métier entre différentes technologies (WPF, XNA, Silverlight, WP). Choisissez les plateformes cibles concernées par la librairie qui ne pourra ensuite référencer que des assemblies .Net communes à ces plateformes. En gros cela correspond aux fonctionnalités bas niveau du système en passant par la sérialisation, les ObservableCollection (top pour partager des ViewModel ), mais en excluant tout ce qui attrait à l’UI. Nous verrons ce point plus en détail lorsque nous aborderons l’architecture en couches de nos applications clientes.

Notifications des vins en promotion

Selon notre cahier des charges, les alertes promotionnelles sont destinées à l’application Windows Phone.
La plupart des smartphones supportent des mécanismes de notifications asynchrones. C’est le cas pour Windows Phone avec les notifications Push.
Ce mécanisme permet à une application WP de réagir en fonction d’informations provenant d’un service Microsoft de Push, lui-même prévenu par un service métier fait maison, se chargeant de déterminer et envoyer des évènements de notification. Les notifications Push à destination d’une application arrivent indépendamment du fait que celle-ci soit ou non en cours d’exécution. Ce fonctionnement permet de bénéficier d’une notion d’asynchronisme dans une application sans pour autant vider la batterie du téléphone avec un thread en tâche de fond.

Hébergement des données, des services et des applications

J’ai besoin de serveurs, mettant à disposition mes données et services, en faisant en sorte qu’ils soient disponibles tout le temps. Tout ce petit monde se doit de se porter comme un charme,  peu importe le nombre d’utilisateurs. Au démarrage, il y aura certainement peu de clients, mais comme mon concept et mes applications sont révolutionnaires , mon système doit pouvoir supporter la montée en charge. Pour le moment en tout cas, je n’ai aucune idée de la manière dont je devrais dimensionner mes serveurs.
En fait, ce qui m’arrangerait, c’est de ne pas avoir de serveurs à installer, maintenir, configurer. Après tout, ce n’est pas mon métier, je préfère mon concentrer sur les applications.

C’est justement ce que permet de faire Windows Azure, la plateforme Cloud de Microsoft.
Qui dit plateforme, dit que toute la partie infrastructure est déjà prête à l’emploi, mettant à disposition un environnement, un framework de développement et des services.
Par-rapport à un développement qui est hébergé sur un serveur au sens classique du terme, on utilisera des éléments inhérents à la plateforme Azure, en terme de stockage et de publication.
Vous me direz, la belle affaire, mais pourquoi y aurait-il des différences entre mon développement classique et un développement Azure ?
Eh bien justement, tout simplement pour pouvoir garantir la possibilité au système de monter en charge, de supporter les pannes matérielles, sans impacter sa disponibilité. Avec un développement classique hébergé sur un serveur, vos données sont stockées localement. Il faut prévoir au minimum des mécanismes de redondance pour supporter une panne matérielle. Si vous avez besoin de plus de ressources et décidez d’ajouter un serveur, comment allez vous répartir la charge sur ces serveurs, partager les données, sans interrompre l’accès à vos services ? 

Avec Azure, le principe est de ne pas faire de stockage local sur une machine (on parle en fait d’instance), mais sur des éléments persistants fournis pas la plateforme Azure, qui seront accessibles par les différentes instances quel qu’en soit le nombre. Si une instance redémarre, le système fonctionne toujours et c’est transparent pour l’utilisateur.
Finalement, on s’abstrait de la notion de machine et on se concentre sur les applications et les services ainsi que les systèmes de stockage. 

Les questions d’hébergement, de redondance, d’installation et de maintenance de serveurs n’existent plus en tant que tel. On a intégré ce besoin d’élasticité et de disponibilité directement au niveau de la conception des applications. Notre application et nos services sont prêts une fois pour toute à fonctionner aussi bien au ralenti qu’à pleine charge, en fonction du nombre et de la taille des instances qui leur auront été attribués. La tarification se fait en fonction des critères de volume, bande passante, nombre et taille des instances : plus d’information sur la tarification.

Autre avantage : l’environnement Azure est intégré dans Visual Studio, ce qui permet au développeur de travailler dans un seul et même outil que ce soit pour le développement ou le déploiement de ses applications.

Aucun dépaysement pour le développeur en ce qui concerne le stockage de données puisque la base de données SQL Azure s’utilise exactement comme son cousin SQL Server. On peut utiliser les outils classiques de SQL Server pour administrer une base de données “dans les nuages”, simplement en précisant la chaine de connexion SQL Azure correspondante.

Pour tester gratuitement Azure et SQL Azure pendant 30 jours, profitez de l’offre Azure Pass.

Pour faciliter la mise en pratique des tutoriels qui accompagnent ces articles, nous commencerons par mettre en place les données dans Sql Server, pour les faire migrer plus tard dans Sql Azure. Ainsi, nous obtiendrons un projet qui fonctionnera aussi bien On Premises que dans le Cloud. Cela permettra également de montrer la simplicité avec laquelle des solutions existantes peuvent évoluer vers un hébergement dans Azure.

Récapitulatif

On se retrouve avec le diagramme d’architecture “grosses mailles” que voici:

• L’hébergement des données, des services et applications se fera dans Windows Azure et SQL Azure
• La publication des données sera faite en OData avec WCF Data Services pour rester interopérable avec une grande variété de plateformes clientes
• Les applications clientes seront développées en Silverlight
• Nous nous efforcerons de conserver un maximum de code commun entre les 2 applications grâce à la Portable Library.
• Les promotions seront notifiées sur le téléphone par un service de gestion des promotions et des notifications Push

Y’a plus qu’à !

Passez aux articles suivants:

Dépassé par les technos ? Pas le temps de faire de veille ? Trop de boulot pour passer du temps à vous former sur ce qui ne vous concerne pas directement ?
Un nouveau projet à démarrer ?

Et quand bien même vous décideriez de remettre le pied à l’étrier et rattraper le temps perdu, par où allez-vous commencer ?
Creuser les technos une à une, sans savoir vraiment comment elles se positionnent dans le cadre d’un projet concret…avouons que c’est assez décourageant.

Cette suite d’articles se propose d’introduire les techniques de développement actuelles, dans le cadre d’un besoin et d’un projet concret.

1. Développer un projet aujourd’hui : comment faire, par où commencer ? (vous êtes ici )
2. Architecture et découpage du projet
3. Le Stockage des données
4. La publication des données
5. Migration dans Azure
6. L’application Windows Phone basique
7. Ajout de la fonction d’aide à l’achat
8. Ajout des notifications sur les vins en promotions
9. L’application Silverlight

Une série de tutoriels accompagnera ces articles pour mettre en place la solution from scratch.

Introduction

Un poste de développeur, de chef de projet, d’architecte, un projet, un planning, des délais trop courts, des besoins qui changent tout le temps, des tests, une maintenance perpétuelle de l’application et des mises à jour…

Effectivement, bien souvent on travaille d’arrache-pied sur un projet, la tête dans le guidon, et lorsqu’enfin on finit par la relever, des mois voir des années ont passé. Entre temps, beaucoup de choses ont évolué, aussi bien du côté des usages que du côté des technologies.
Tout le monde ne peut pas se payer le luxe de faire une veille technologique de fond et/ou à large bande. D’autant plus que l’on consacre souvent notre peu de temps de veille, à creuser des sujets qui nous concernent directement et qui sont donc très ciblés.

Les techniques de développement d’aujourd’hui ne sont plus celles d’hier, même si les concepts généraux restent valables.
Mais alors qu’entend-on par “le développement d’aujourd’hui” ? C’est simplement l’intégration de nos usages et contraintes actuelles à savoir :

D’un point de vue fonctionnel:

- des applications disponibles sur le poste de travail, mais aussi sur nos appareils nomade (téléphone, tablette,…)- des applications qui savent mieux exploiter leur environnement de fonctionnement (interaction avec d’autres applications connexes ou communautaires)

- de plus en plus de données en ligne, pour les partager de manière publique ou privée

- une meilleure réactivité (exploitation de nos machines multi-cores)

- une ergonomie “sexy” et pensée pour l’utilisateur

- des services disponibles depuis n’importe où et tout le temps

D’un point de vue technique:

- l’avènement des application web

- l’arrivée de plateformes et de services dans les nuages

- les applications naissent/vivent/évoluent/co-existent/meurent mais les données perdurent

- le besoin d’une architecture générique et adaptable (adaptation au développement agile)

- une meilleure lisibilité du code

- une meilleure testabilité

- une amélioration du confort de développement et de la productivité du développeur

Bref, tout un programme !

Si vous démarrez un développement aujourd’hui sans prendre en compte ces concepts devenus légion, vous risquez fort d’obtenir un résultat décevant et peu pérenne.

Tout un programme !

Comme je vous le disais, nous allons partir sur un cas concret en essayant de répondre à un besoin fonctionnel, à savoir :

CaveAVins : Une application de gestion de cave à vins et d’aide à l’achat en boutique.

Bon j’en vois déjà qui lèvent les yeux au ciel : elle parle encore de vins !
Ben oui, et alors ? Déjà j’aime bien ça (quelque chose me dit que je ne suis pas la seule) et surtout cela évite d’expliquer en long en large et en travers le besoin fonctionnel que l’on comprend immédiatement, ce qui fait gagner un temps fou à tout le monde .
Ce prétexte métier de cave à vins peut être remplacé par n’importe quel autre, qui s’appuierait sur un catalogue de données et fournirait des services et applications autour de celui-ci. 
Finalement, cela correspond à la majorité de nos applications.

Cahier des charges fonctionnel

Alors là je joue le rôle du client…

Besoin 1: Gestion de ma cave à vins

- Ajouter/supprimer des bouteilles dans ma cave
- Filtrer, trier les bouteilles selon les cépages, les prix, les années, les mets qui s’y accordent…
- Noter les bouteilles et pouvoir partager cet avis avec les autres utilisateurs

Besoin 2: Aide à l’achat en boutique

Je ne sais pas pour vous, mais quand je vais au supermarché choisir une bouteille de vins, je vis un grand moment de solitude. Quel vin vais-je choisir ?
Bon j’ai mes préférences, mais si je dois choisir une bouteille de Bordeaux, comment savoir laquelle des 25 bouteilles proposées entre 4 et 6 euros sera la meilleure ?
D’où l’idée de pouvoir prendre une bouteille en photo avec son téléphone et de visualiser les notes que lui ont données les autres amateurs de vins disposant de la même application que moi.

Besoin 3: Bénéficier des meilleurs tarifs

Etre notifié de promotions sur mes vins préférés, par le producteur ou le distributeur.

Voilà pour mon besoin. C’est déjà pas mal pour un début.
En fonction du temps que je peux octroyer à ces articles, de l’actualité, et aussi de vos attentes, nous pourrons compléter ces besoins par d’autres scenarios.

Analyse technique

Un petit schéma de l’idée générale à ce stade:

Passons au premier débriefing technique après avoir pris connaissance du besoin. Les idées arrivent en vrac, de manière décousue…
J’utiliserai volontairement des termes techniques correspondant à des technologies mais pas de panique, inutile de savoir à quoi elles font référence à ce stade:

Besoin 1:

- Pour stocker les données (vins, caractéristiques, notes…) on va bien évidemment utiliser une base de données.
A la base, il n’y a pas de catalogue de bouteilles existant, ce sont les utilisateurs qui enrichissent la base de données au fil de leurs achat et de leur notation.
Les données devront donc être mutualisées et non pas être stockées localement sur leur poste de travail et/ou leur téléphone, avec un catalogue présent dans une base de données distante.
Je pense à SQL Server, SQL Azure

- Nous aurons besoin d’une techno qui nous permet de requêter efficacement ces données, si possible qui fonctionne depuis plusieurs plateformes clientes (doit fonctionner sur le poste de travail et sur le téléphone).
Je pense à Entity Framework, Linq, OData, WCF Data Services

- Les données et services doivent être hébergés et accessibles facilement
Je pense à Azure et SQL Azure

- Nous devrons développer 2 applications : l’une pour le PC, l’autre pour notre cher Windows Phone.
Les cas d’utilisation sur le PC et sur le téléphone ont l’air assez similaires, mais certains usages se révèleront être inutiles sur les deux plateformes.
En tout cas, nous essaierons de factoriser un maximum le code des deux applications
Je pense à Silverlight, Portable Library, Html5

- Une manière sexy de représenter un catalogue de données sur PC, avec filtrage, tri, regroupement.
Je pense à Pivot Viewer

Besoin 2:

- Prise de photo pour interprétation du code barre et/ou de l’étiquette de la bouteille
Je pense aux services OCR (Reconnaissance optique de caractères)

Besoin 3:

- Pouvoir être notifié des bonnes affaires sur les vins que je préfère ?
Je pense aux notifications Push sur Windows Phone

Les éléments techniques introduits en bleu correspondent aux premières associations d’idées. Ca ne veut pas dire que dans les faits, ils correspondront le mieux aux besoins du développeur et du client.
Nous découvrirons au fil des articles, quels choix techniques seront retenus et quelles seront les solutions les plus adaptées.
Je risque également de modifier la liste des besoins: soit parce que trop compliqué à mettre en œuvre dans des articles “basiques”, soit parce qu’un autre scénario auquel je n’avais pas pensé se révèlera être plus intéressant à expliquer.
Vous l’aurez compris, j’écrirai cette suite d’articles en temps réel.

Voici le premier jet pour le sommaire de cette série d’articles :

1. Développer un projet aujourd’hui : comment faire, par où commencer ? (vous êtes ici )
2. Architecture et découpage du projet
3. Le Stockage des données
4. La publication des données
5. Migration dans Azure
6. L’application Windows Phone basique
7. Ajout de la fonction d’aide à l’achat
8. Ajout des notifications sur les vins en promotions
9. L’application Silverlight

…sachant que je risque de revoir la décomposition de tout cela en fonction de la longueur des articles et des notions en plus ou en moins que j’aborderai.

Tchin tchin !