ASP.NET Dynamic Data

Un peu d’ASP .NET ! Pourquoi pas ?!!!

Nous parlerons dans ce spot d’une nouveauté au niveau de notre Framework .NET dans sa version 3.5 SP1. Il s’agit d’ASP.Net Dynamic Data.

ASP.NET Dynamic Data est une infrastructure permettant de créer facilement des applications Web, permettant de naviguer automatiquement au travers d’un ensemble de données, contenues dans une source de données, pouvant être une grappe d’objets ou une base de données. Elle est capable de parcourir l’ensemble des informations structurelles sur cette source de données, afin de pouvoir consulter, ajouter, modifier et supprimer les données qu’elle contient. Autrement dit, ASP.NET Dynamic Data permet de créer très rapidement, avec un faible effort de développement une application de gestion de données.

Voici le besoin :

Un client dispose d’un ensemble de tables dans une base de données. On vous demande de développer une application Web permettant la navigation dans l’ensemble des informations contenues dans les tables Bases de données, ainsi que la manipulation de ces données en mode CRUD.

Estimation :

Si votre chef de projet vous demande votre estimation, vous lui répondez ça dépend du nombre de tables contenus dans la base de données ainsi que la complexité et la nature des relations entre tables. Et donc, ça va être de l’ordre de quelques jours.

Avec ASP.Net Dynamic Data, la solution coute quelques minutesJ, Comment cela ?

Solution :

1- Class Library : Composant d’accès aux données

Commençons par créer un projet de type bibliothèque de classe. Ce projet contiendra le modèle d’entités, ainsi que toutes classes permettant d’étendre les classes qu’il contient. (Utiliser Entity FrameWork pour générer le modèle entité)

2- Application Web d’entités Dynamic Data: Site Web

1. Créer une application Web d’entités Dynamique Data
2. Référencer la class Library déjà créée ainsi que la dll System.Data.Entity.dll
3. Ajouter cette ligne

model.RegisterContext(typeof(DotnetTunisieEntities), new ContextConfiguration() { ScaffoldAllTables = true });

DotnetTunisieEntities Etant le type d’Entity Data Model, au niveau du fichier Global.asax (au niveau de la méthode RegisterRoutes, directement après la ligne suivante

MetaModel model = new MetaModel();)

1. 4 Copier la connectionString au niveau de l’App.config de la classe Library qui a été généré automatiquement lors de la création des entités. Elle de cette forme

- < add name="DotnetTunisieEntities" connectionString="metadata=res://*/DotnetTunisie.csdl|res://*/ DotnetTunisie.ssdl|res://*/ DotnetTunisie.msl;provider=System.Data.SqlClient;provider connection string="Data Source=ServerName\SQL;Initial Catalog=DotnetTunisie;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"/>

5. Coller là au niveau du Web.config

Et voilà votre application est prête à utilisation.

Pour plus d'éclaircissement, veuillez consulter ce lien Introduction à ASP .NET Dynamic Data

Bonne lecture!

Stramit SharePoint Caml Viewer

Voici un bon outil pour construire votre requête CAML (http://spcamlviewer.codeplex.com/). Tous les développeurs SharePoint ont besoin un jour ou un autre de construire des requêtes CAML pour interroger des listes SharePoint.

Pour alléger la tache de création des requêtes CAML, à utiliser cet outil en suivant les étapes suivants :

1. Créer sur la liste SharePoint la vue permettant de chercher l’ensemble des informations

2. Se connecter avec Stramit SharePoint Caml Viewer sur la bonne vue

3. Cliquer sur le lien String Builder format C#

Et voilà, votre requête CAML a été générée. Il ne vous reste qu’à copier le code et le coller au bon endroit dans votre code.

Vive CodePlex, et Vive la technologie

Splalgenerator

SharePoint List Access Layer Generator

En implémentant des solutions SharePoint, on est toujours amené à manipuler des éléments dans des listes en mode CRUD.

Le code ci-dessous présente une manière classique de manipulation de Liste :

using (SPSite Site = new SPSite("Url"))

{

using (SPWeb Web = Site.OpenWeb())

{

SPList oList = Web.Lists["MyCustomList"];

SPListItem oListItem = oList.Items.GetItemById(1);

oListItem["MonChamp"] = "NouvelleValeur";

}

}

ou bien

using (SPSite Site = new SPSite("Url"))

{

using (SPWeb Web = Site.OpenWeb())

{

SPList oList = Web.Lists["MyCustomList"];

SPListItem oListItem = oList.Items.GetItemById(1);

oListItem["D91D43BC-179A-44ec-AEE6-E23650EE0"] = "NewValeur";

}

}

La première écriture présente des inconvénients dans le sens ou le développeur doit toujours revenir au site SharePoint pour s’assurer de la bonne écriture du nom du champ.

La deuxième écriture ne donne aucune signification sur le nom du champ à modifier.

La solution propsée au niveau de ce post se repose sur un outil développé au niveau du CodePlex SharePoint List Access Generator (http://splalgenerator.codeplex.com/)

Splalgenerator génére des classes d’accés aux listes pour la manipulation des éléments des Listes. Les classes sont configurées par les paramètres de site c’est-à-dire Url, GuidList et Guid des champs.

Le code ci-dessus devient :

MyCustomList myCustomList = new MyCustomList(1) ;

myCustomList.MonChamp = "NouvelleValeur" ;

Cette manière d’écriture est plus élégante. En plus, elle fait gagner beaucoup du temps lors du développement, car j’ai vu beaucoup de développeurs construisant leurs propres classes de manipulation de List en configurant leurs listes par les guid des éléments. Mais cette solution est couteuse en termes de temps de développement car le développeur est censé maintenir ses classes à jour.

Pour que notre solution demeure valable même en environnement de déploiement chez le client, il est important de créer nos propres content types.