Développer un projet aujourd’hui : Stockage des données avec Sql Server, EF Code First et Azure (3/9)

Article
10/20/2021

Stéphanie Hertrich

Article par Stéphanie Hertrich

Mon rôle est d'animer les relations techniques avec le public développeur. Autrement dit, de renforcer, clarifier, l'accès aux nouvelles technologies de développement par les développeurs et équipes projet.

J'ai une expérience métier de 13 ans dans l'édition de logiciels pour des sociétés industrielles proches de l'informatique embarquée. De par mon profil développeur .Net et chef de projet, j'ai longtemps fait partie de l'audience typique des événements MS.
Ma fonction chez Microsoft me permet de rester au plus près des aspects technique et développement qui me tiennent à cœur. J'aborderai des sujets aussi variés que Sharepoint (côté dev), WPF, WCF, MEF, … au gré de l’actualité et des sujets que j’affectionne.

Retrouvez-moi sur mon blog ainsi qu’en session aux MS Days, TechDays et autres rencontres palpitantes..

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.

Articles:

Développer un projet aujourd’hui : comment faire, par où commencer ?
Architecture et découpage du projet
Le Stockage des données
La publication des données
Les services métier
L’application Windows Phone basique
L’application Silverlight
Ajout de la fonction d’aide à l’achat
Ajout des notifications sur les vins en promotions

Tutoriels:

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.

Sommaire de l'article

Rappel de l’architecture visée
- Informations à stocker
Structure des données
- Il y avait pourtant bien une vie avant l’ORM, non ?
- Mais pourquoi parler d’ORM avant même d’avoir créé la structure de la base de données ?
Création de la couche de données : Sql Server et Entity Framework
Architecture réalisée à ce stade

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 PortableLibrary

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.

Informations à stocker

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
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.