Discussion :

[theMonz31]

Bonjour

Ma situation est assez simple

J'ai une table qui contient des informations sur du matériel et notamment, sur le propriétaire du matériel.

Ce que je veux faire est la chose suivante:

Quand un utilisateur se connecte, je veux qu'il ne puisse voir que le matériel qui lui appartient ET qu'il puisse faire une recherche par n° de série (un des champs de la table).

Actuellement, j'ai fait un truc du genre:

Dans le chargement de la page, j'ajoute à ma requête qui remplit ma base de données:

DbMAtos.selectCommand += "where userID = " + ... et la je mets le userID que j'ai récupéré via le login...


J'ai ensuite une textbox qui est utiliser dans le "filterExpression" de mon Select de DbMatos...

Je me demande si c'est vraiment la meilleure solution et surtout, la plus élégante...



Merci de me dire ce qu'il faudrait, idéalement faire résoudre celà...

[tomlev]

Déjà, évite de faire des requêtes SQL directement dans le code de la page, c'est crade et ça complique la maintenance. Crée plutôt une couche DAL avec les méthodes dont la couche UI aura besoin. Par exemple, tu peux avoir une classe MaterielRepository avec une méthode FindMaterialByUserAndSerial qui renvoie une liste d'objets Materiel. D'autre part, il ne faut jamais construire une requête en concaténant des valeurs qui viennent de l'utilisateur, car en faisant ça tu t'exposes à une attaque par injection SQL ; il faut utiliser des requêtes paramétrées, comme expliqué dans ce tuto.

Sinon, plutôt que d'utiliser directement du SQL, tu peux utiliser un ORM comme Entity Framework. Comme ça tu n'as pas besoin d'écrire une ligne de SQL, et ça te matérialise directement les objets métier. Ou alors tu peux opter pour une solution intermédiaire, en utilisant un micro-ORM comme Dapper : dans ce cas tu écris le SQL toi-même, mais la matérialisation des objets est gérée automatiquement, et l'API est plus pratique que celle d'ADO.NET "normal" (notamment pour le passage des paramètres).

[theMonz31]

Merci Thomas

LE seul hic, c'est que comme je suis derrière un fournisseur 1&1 pour ne pas le citer, je suis un peu limiter pour l'utilisation d'outil...

En tout cas, j'essaye d'éviter au maximum car, par exemple, je voulais générer du PDF depuis mon site, et alors, que celà fonctionnait très bien en test, ça ne
marche pas chez l'hébergeur à cause du niveau de trust disponible chez lui :-(


Et je n'avais pas trop envie d'utiliser un ORM pour quelques tables et quelques actions simples

Mais merci pour ta suggestion.

[tomlev]

Bah avec Dapper t'as pas besoin d'installer quoi que ce soit, il suffit de déployer la DLL avec ton appli. C'est juste ADO.NET avec une API plus simple au final...

[theMonz31]

ok

je vais regarder Dapper

celà dit, en dehors de dapper, une solution en sql ?

[tomlev]

celà dit, en dehors de dapper, une solution en sql ?

En fait je viens de réaliser que tu utilises probablement un SqlDataSource... Du coup si tu veux continuer à utiliser ça tu es un peu condamné à faire du simple SQL de toute façon. Plutôt que de construire manuellement la requête en ajoutant le userId, utilise la propriété SelectParameters de la DataSource pour passer le UserId. Tu peux utiliser un SessionParameter pour le UserId, et un ControlParameter pour le serial number.

La propriété FilterExpression, il me semble que ça filtre les données en mémoire, après qu'elles aient été récupérées de la DB. Tu peux aussi passer des paramètres pour cette expression via FilterParameters, mais dans l'expression il faut les spécifier avec "{0}", "{1}", etc, et non pas avec la syntaxe SQL.

Perso je trouve tout ce sytème de SqlDataSource assez dégueulasse... le code d'accès à la DB n'a rien à faire dans la couche UI. Mais bon, si c'est pour faire du "quick and dirty", ça peut se justifier.

[theMonz31]

bah ca serait plutot que

"quick as quick as possible"...

disons que je maitrise .Net mais pas les aspects base de données (je fais principalement de l'industriel en .Net) ni l'aspect Web...

et comme le site web a pour objectif d'afficher 5 tables.. ça me paraissait ambitieux de prendre un ORM pour faire celà ne connaissant pas grand chose
à ces bestioles là.

Après, ce que je trouve pratique dans VS avec le query designer, c'est que, par exemple, au moment ou tu vas sélectionner ta base de données, tu vas
pouvoir éditer ta requête et voir le résultat de suite avant de valider... et ensuite, ton composant grille qui affiche les colonnes automatiquement et te permet
de choisir le comportement (je travaille avec de l'infragistics), je trouve celà quand même super agréable sans avoir à écrire de ligne de code DAL....

Certes, ca peut être le bordel, mais je trouve celà quand même bien rapide et facile...