Discussion :

[IAmByB]

Bonjour,

Je travaille sur une application ASP .NET comportant plusieurs pages et une base de données SQL Server.

L'essentiel du code C# se trouvait inclus dans les pages ASP, y compris les méthodes servant à la connexion à la base de données, la récupération des données sous forme de DataSet, le traitement des données et leur affichage dans des grilles. Pour améliorer et optimiser le fonctionnement, j'ai donc mis en place l'architecture suivante :

- Des objets Gestionnaires de Données servant à effectuer les traitements des objets métier sans être perturbés par les événements et PostBacks de la page. Pour récupérer les données, ces objets appellent les méthodes de la Business Layer,
- Une couche Business Layer recevant des datasets de la Data Access Layer et transformant les datasets en objets métier.
- Une couche Data Access Layer servant aux accès à la base de données (procédures stockées) et retournant des DataSet.

Chaque page comporte une référence vers un objet Gestionnaire de Données (sauvegardé en Session pour récupération lors des PostBacks).
Toutes les manipulations de données (y compris tris et filtres) sont effectuées par le Gestionnaire de Données à la demande de la page, et les Gestionnaires de Données fournissent à la demande de la page les données traitées sous forme de listes d'objets métier servant de DataSource à la GridView de la page.

Par exemple, la suppression d'un enregistrement effectué au niveau de la page s'effectue par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
protected void buttonDelete_Click(object sender, EventArg e)
{
Gestionnaire gestionnaireDonnees = Session["Gestionnaire"]; // récupération du Gestionnaire de Données
 
gestionnaireDonnees.DeleteRecord(e.RecordIndex); // le gestionnaire de données supprime l'enregistrement de sa liste d'objets métier
 
gridView.DataSource = gestionnaireDonnees.getData(); // le gestionnaire de données retourne la liste d'objets métier mise à jour
}

Le but est d'accélérer le traitement des données et l'affichage des pages.

J'envisage même d'effectuer des traitements multi-thread dans mes objets Gestionnaires de Données pour optimiser les traitements à effectuer et pouvoir fournir plus rapidement à la page la nouvelle DataSource de la GridView.

Je souhaiterais avoir vos avis et commentaires sur cette architecture, sachant que je n'ai pas la possibilité de me lancer dans des technologies telles que WCF, MVC ou autres.

Merci.

[IAmByB]

PS : Bien entendu, le code comprend aussi le DataBind() de la GridView (oublié dans le message précédent) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
protected void buttonDelete_Click(object sender, EventArg e)
{
Gestionnaire gestionnaireDonnees = Session["Gestionnaire"]; // récupération du Gestionnaire de Données
 
gestionnaireDonnees.DeleteRecord(e.RecordIndex); // le gestionnaire de données supprime l'enregistrement de sa liste d'objets métier
 
gridView.DataSource = gestionnaireDonnees.getData(); // le gestionnaire de données retourne la liste d'objets métier mise à jour
 
gridView.DataBind();
 
}

[DotNetMatt]

Ca a l'air bon

Le but est d'accélérer le traitement des données et l'affichage des pages.

Si tu veux réellement accélérer le traitement de tes données, oublie les DataSets.

J'envisage même d'effectuer des traitements multi-thread dans mes objets Gestionnaires de Données pour optimiser les traitements à effectuer et pouvoir fournir plus rapidement à la page la nouvelle DataSource de la GridView.

S'il y en a réellement besoin, pourquoi pas. Il ne s'agit pas de rajouter de la complexité pour rien As-tu de longs traitements et/ou une grosse volumétrie à traiter ?

[IAmByB]

Ca a l'air bon


Si tu veux réellement accélérer le traitement de tes données, oublie les DataSets.

S'il y en a réellement besoin, pourquoi pas. Il ne s'agit pas de rajouter de la complexité pour rien As-tu de longs traitements et/ou une grosse volumétrie à traiter ?

Que veux tu dire par "oublies les datasets" ? Y a t-il un handicap (en termes de performance) à manipuler des data sets ? Quelles est alors la solution recommandée ?
Pour info, dans mes Business Layers, je transforme les datasets en objets métiers, et les Gestionnaires de Données fournissent donc à mes GridViews des listes d'objets métiers pour le binding.

Quant au multi threading, il serait là pour optimiser des traitements longs qui sont actuellement effectués dans l'événement RowDataBound des gridviews et qui ralentissent considérablement l'affichage des pages.

[DotNetMatt]

Que veux tu dire par "oublies les datasets" ? Y a t-il un handicap (en termes de performance) à manipuler des data sets ?

Les DataSets c'est bien pour des petits projets (quand je dis "petits", j'entends des projets basiques à faible volumétrie et/ou pour lesquels les performances ne sont pas importantes).

Tu peux trouver plein de benchmarks sur le net où sont comparés l'utilisation de List<T> et l'utilisation de DataSets. En voici un pour l'exemple : http://www.johnbelthoff.com/articles...aspx?aid=18464

De plus, l'utilisation de List<T> te permettra d'avoir un code beaucoup plus clair.

Quelles est alors la solution recommandée ?

Les DAL les plus performantes sont les DAL dites Ordinales :
- High Performance Data Access Layer Architecture Part 1
- High Performance Data Access Layer Architecture Part 2
- High Performance Data Access Layer Architecture Part 3

Pour info, dans mes Business Layers, je transforme les datasets en objets métiers, et les Gestionnaires de Données fournissent donc à mes GridViews des listes d'objets métiers pour le binding.

Le raisonnement est bon, mais si tu cherches à améliorer les performances, il vaut mieux utiliser autre chose que des DataSets

[nachtigal]

Bonjour,
Au vu des performances des machines d'aujourd'hui, et à moins que tu ne sois dans des applications critiques comme la recherche opérationnelle, les statistiques bancaires ou encore le décryptage d'ADN,... ta première préoccupation doit d'abord porter sur le fonctionnement sans bug de ton application avant de chercher à optimiser quoi que ce soit !!
Ah la belle époque où nous programmions sur ZX81 avec 16 ko de Ram (avec extension stp!)...
1) Bien, tu as donc une base de données SQL Serveur, déjà exception faite de quelques traitements obscurs ou bien où les temps d'accès sont vraiment critiques, moi je prendrai tout simplement EF5. Il te génère déjà une DAL fiable en moins de 6mn... faut vraiment être difficile pour passer à coté !!
2) Ensuite je complète mon modèle avec les SPROC obscurs dont je parlais plus haut. Voilà ta DAL complète !!
3) Faut JAMAIS réinventer le fil à couper le beurre, je prends donc un "Generic Repository for Entity Framework" (google), si si il y en a d'excellent où tu n'as rien à réinventer... l'avantage ici est que tu obtiens une méthode commune d'accès aux données.
4) Pour ma part et dans un soucis de simplification et de segmentation, j'ai rajouté une Factory qui ne comporte que des méthodes statiques appelées par mes pages web. Ma page Web ne dialogue qu'avec la Factory sans jamais se préoccuper d'où proviennent les données et de fait je pourrais très bien changer la DAL par exemple et la brancher sur ORACLE (ce que j'ai déjà fait) ou autre chose sans que ma Factory soit impactée ni ma page Web... Chaque module étant un projet à part !!
Cela fonctionne plutôt bien sans me prendre la tête, et je peux me concentrer uniquement sur la logique métier.
Ah j'oubliais, je ne transfère que des List<T> entre les couches et ne les spécialise en DataTable que si vraiment le besoin terminal me l'impose.
Pour ma pageweb j'utilise des composant d'interface comme les Grid de devexpress (faut jamais réinventer le fil... sans bonne raisons) !!
Peut-être pour l'affichage de page avec plusieurs graphiques et des Grids tu pourrais songer au chargement asynchrone, ou mieux utiliser une librairie JQuery et des appels AJAX (google) !!
Bon tu voulais quelques suggestions, voilà!!
nachtigal