Bonjour;
Je travaille en architecture 3 tiers, et dans mes tables j'ai des champs qui doivent être unique, je voudrais savoir dans quelle couche je dois vérifier cette unicité.
si vous me donner d'autres conseils, c'est encore mieux.
Merci beaucoup.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Architecture 3 tiers et contrainte d'unicite
Bonjour;
Je travaille en architecture 3 tiers, et dans mes tables j'ai des champs qui doivent être unique, je voudrais savoir dans quelle couche je dois vérifier cette unicité.
si vous me donner d'autres conseils, c'est encore mieux.
Merci beaucoup.
Ca dépend.
* Si toutes ta table est chargée dans ta couche interface (pas de pagination), tu peux faire une validation client pour éviter un A/R serveur, mais il te restera un cas d'erreur (deux utilisateurs différents)
* Si toutes ta table est chargées dans ta couche métier, tu peux vérifier au niveau métier, si tes données sont en static (elles seront communes à tous les utilisateurs)
* Sinon, le mieux à mon avis, en faisant proprement ta requête/store proc d'insertion, tu lui fais remonter un code d'erreur si on tente d'insérer un doublon.
Sinon, la méthode crado utilisée dans 95% des cas, mais qui diminue les perfs de ton serveur, ça consiste à faire l'insertion et à gérer l'exception remontée par ton SGBD.
Un autre conseil ?
Brosse toi les dents tous les soirs avant d'aller te coucher
Le DataSet Typé permet de gérer cette contrainte avant d'accéder au server SQL et dans ce cas, selon l'utilisation que tu fais de ton DataSet se sera soit dans la couche métier soit dans la couche d'accès aux données
On parle bien d'un application web ?Envoyé par stephane.net
Le DataSet Typé permet de gérer cette contrainte avant d'accéder au server SQL et dans ce cas, selon l'utilisation que tu fais de ton DataSet se sera soit dans la couche métier soit dans la couche d'accès aux données
concernant ma réponse Oui ?
Scénario à la con :
=> on veut assurer l'unicité sur un nom de login dans une page de gestion des utilisateurs.
T0 - L'utilisateur A se connecte et charge la page des utilisateurs.
T1 - L'utilisateur B se connecte et charge la page des utilisateurs.
T2 - L'utilisateur A entre le login "Robert", il valide, ça l'insère en base.
T3 - L'utilisateur B (qui n'a pas rechargé la page des utilisateurs) entre le login "Robert" et valide.
Comment ton DataSet il peut savoir que "Robert" n'existe pas en base sans se connecter ?
Désolé de casser ta réponse précédente, mais soit j'ai pas compris, soit tu t'es mal exprimé (c'est un peu pareil), soit tu as dit une connerie
merci Mose pour ta réponse
mais c'est comme tu l'as dis : "ça dépend"
Pas d'accord là dessus
Donc pas de souci de ce côté là
Bonjour Ditch,
Tu peux expliquer ce que ça signifie stp ?Pas d'accord là dessus
Qu'y a-t-il de compliqué? Si la c'est une variable d'application c'est ok... Je saurais pas dire autrement
Tu as des variables à plusieurs niveaux:
- Application (accessible à tous)
- Session (accessible à l'utilisateur en cours)
- Page (uniquement dans la page)
- ...
je vais m'arrêter là
Ouais mais ça dépend comment l'appli est codée.Pas d'accord là dessus
Donc pas de souci de ce côté là
Si l'insertion ne peut se faire QUE par un point d'entrée unique ou par ledit DataSet, alors oui, c'est cool.
Mais pour peut que ce soit mal codé, qu'il y ait une procéduree automatique d'insertion, etc... ça peut être le dawa.
Bref, On est d'accord au final : ça dépend
Désolé je ne fais que coder correctementOuais mais ça dépend comment l'appli est codée.
Si l'insertion ne peut se faire QUE par un point d'entrée unique ou par ledit DataSet, alors oui, c'est cool.
Mais pour peut que ce soit mal codé, qu'il y ait une procéduree automatique d'insertion, etc... ça peut être le dawa.
Bref, On est d'accord au final : ça dépend
Nulle intention de te vexer Ditch.
C'est juste qu'à force de faire du consulting sur des applis codées par des ==CENSURE== qui développent comme des pieds, on devient parano
Le problème principal c'est que souvent y'a 10 codeurs qui sont passés avant et qui ont tous des façons de faire différentes, qui rajoutent couches sur couches et souvent tu te tapes des effets de bords monstrueux paske t'as eu la flemme de lire les 8000 lignes de code dans les 18 fichiers différents, sans une ligne de commentaire, qui permettent de gérer une fonctionnalité que tu peux faire en 50 lignes quand tu codes bien.
Si tu savais ce que j'ai vu. La dernière fois, y'avait 6 façons différentes pour modifier/accéder à la base de donnée dans une seule et même appli :
* des requêtes directes dans la couche interface (aspx)
* des requètes construite dans la "couche métier" (on peut plus l'appeler comme ça), redescendues dans la couche donnée pour appel
* des store procs en T-Sql
* des store procs en CLR (bonjour les pb de conversion de types, notamment avec le Type decimal)
* des TableAdapter construits automatiquement à partir de DataSets (xsd)
* des tâches plannifées qui faisaient des traitements journaliers dans la base
Et le pire c'est qu'il y avait des feintes : des procs qui semblaient correctes, mais qui n'étaient jamais appelées (remplacées par des requètes directes), des méthodes jamais appelées, etc...
Bonjour le mic-mac. Je vous jure, ça donne envie de pendre du developpeur.
Surtout quand t'as fait une sous-estimation du temps de travail, que t'es freelance et que c'est toi qui doit payer pour les conneries des autres.
D'où ma suggestion de faire une proc sympa qui fait la vérif niveau BDD, comme ça tu es sûr que ça va marcher
Maintenant si tu es le premier sur le projet, alors effectivement, je vote la solution de Ditch, c'est la moins lourde.
Je répondais à ca uniquement... Enfin soit, passonsScénario à la con :
=> on veut assurer l'unicité sur un nom de login dans une page de gestion des utilisateurs.
T0 - L'utilisateur A se connecte et charge la page des utilisateurs.
T1 - L'utilisateur B se connecte et charge la page des utilisateurs.
T2 - L'utilisateur A entre le login "Robert", il valide, ça l'insère en base.
T3 - L'utilisateur B (qui n'a pas rechargé la page des utilisateurs) entre le login "Robert" et valide.
Comment ton DataSet il peut savoir que "Robert" n'existe pas en base sans se connecter ?
Désolé de casser ta réponse précédente, mais soit j'ai pas compris, soit tu t'es mal exprimé (c'est un peu pareil), soit tu as dit une connerie
Attention, je n'ai pas listé l'ensemble des mauvaises pratiques.
Ce que je critique c'est d'utiliser 10 approches différentes, ça rend le code très difficile à maintenir, paske ça le rend contre-intuitif.
Pour les DataTableAdapter , c'est un moyen très simple et graphique de faire une liaison avec une base de donnée. Voici un lien en anglais qui montre comment faire, avec des screenshots.
http://weblogs.asp.net/bradygaster/a...-Forehead.aspx
Ditch : dsl pour le troll... mauvais projet... client exigent... code pourri... fatigué... m'en fous je change de taf
Merci Ditch et Mose.
Je crois que la meilleur solution et de combiner les deux idées, c-à-d, utiliser une variable d'application qui m'évite d'envoyer une requête d'insertion alors que la contrainte n'est pas vérifiée, et d'ajouter une méthode BDD au cas où quelqu'un fait des insert automatiques. Comme ça on évite tout problème, et on ne fait aucun jalous
Merci beaucoup.
Désolé de rajouter de l'huile sur ce feu bouillantQu'y a-t-il de compliqué? Si la c'est une variable d'application c'est ok... Je saurais pas dire autrement
Tu as des variables à plusieurs niveaux:
- Application (accessible à tous)
- Session (accessible à l'utilisateur en cours)
- Page (uniquement dans la page)
- ...
je vais m'arrêter là
En effet, il est possible de tout gérer en passant par un dataset unique partagé au niveau de l'application soit grâce à l'objet "Application" soit grâce à l'objet Cache. Dans ce cas, on travaille en mode déconnecté, càd que l'on met le dataset à jour et à un instant T, on envoie les update à la DB en passant par un adapter quelconque. C'est en effet en théorie tout à fait possible mais en pratique très peu souvent utilisé bien que Microsoft vante le mode déconnecté, je pense qu'il ne cadre pas tout à fait avec l'architecture Web et je dois dire que je ne l'ai encore jamais rencontré personnellement.
D'après l'expérience que j'ai, les développeurs WEB utilisent le dataset pour l'acquisition de données(par facilité et/ou réutilisation comme la liaison à plusieurs contrôles) et gèrent les mises à jour via une DAL (data access library) dont les méthodes sont appelées directement après une MAJ. Ces méthodes utilisent des procédures stockées.
Donc, on est en mode déconnecté en ce qui concerne la "lecture" des données mais dès qu'il s'agit de faire une mise à jour, le dataset est généralement "bypassed". A mon sens le mode déconnecté est plus approprié pour des applications de type "serveur" en winform ou console.
Vous avez souvent rencontré des développements Web utilisant le mode déconnecté à 100%?
Bonjour Stephane,
J'utilise le dataset en mode deconnecté y compris pour les mises à jour.
L'utilisateur de l'application travaille par exemple sur un formulaire dans lequel les différentes opérations qu'il peut effectuer reviennent à faire des CRUD sur le DataSet ( comme le DAL le ferait sauf que là on est sur un cache de données ).
Comme au sein d'une transaction, une fois le travaille terminé, l'utilisateur valide ses modifications : ça se traduit par l'appel des méthodes tableAdapter.Update() regroupées dans une fonction MyDataSet.Save implémentée dans la classe partiel de MyDataSet.
Ou bien il peut annuler et revenir à l'état initial : DataSet.RejectChanges().
Je ne pense pas que ce soit techniquement la solution la plus efficace à mettre en oeuvre mais bon, après tout, cela se justifie sans doute...mais bon, je suis plutôt d'accord avec ceci:
Répondre avec citation
Partager