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.
Version imprimable
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 :D
On parle bien d'un application web ?Citation:
Envoyé par stephane.net
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 :aie:
mais c'est comme tu l'as dis : "ça dépend" ;)
Pas d'accord là dessus :) Si l'objet est stocké en tant que variable d'application, le problème ne se pose pas ici. Effectivement, à l'ajout dans le DataSet, ca va gueuler ;)
Donc pas de souci de ce côté là :)
Bonjour Ditch,
Tu peux expliquer ce que ça signifie stp ? :PCitation:
Envoyé par Ditch
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à :) ce qui nous intéresse c'est celle qui est partagée par tous, en Application.
Ouais mais ça dépend comment l'appli est codée.Citation:
Envoyé par Ditch
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
Désolé je ne fais que coder correctement :aie:Citation:
Envoyé par Mose
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 8O
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, passonsCitation:
Envoyé par Mose
:) tu peux développer stp ? je débute en asp.net (et même en développement web...) et j'espère n'apprendre que des bonnes manières..Citation:
Envoyé par Mose
Attention, je n'ai pas listé l'ensemble des mauvaises pratiques.Citation:
Envoyé par stephane.net
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 :) (je rigole sur la derniere remarque)
Merci beaucoup.
Désolé de rajouter de l'huile sur ce feu bouillant :aie: mais c'est la première fois que je lis ce topic et il m'intéresse à plusieurs titres:Citation:
Envoyé par Ditch
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:
;)Citation:
Envoyé par 32 auteurs ont écrit
d'après ce que je viens de lire, le defaut de conception est surtout lorsqu'on choisit l'utilisation d'un DataSet en pensant que cela va nous permettre d'augmenter la capacité d'utilisateurs connectés à l'application. :P
Parcontre, dans le cas par exemple de création d'une commande d'articles, est-il nécessaire lorsque tu incrémentes la quantité d'un article commandé de faire un a/r serveur ?
Autre question, le code implémenté dans le DAL n'est-il pas finalement le même que celui implémenté dans le TableAdapter ?
(ce ne sont que des questions, je débute et cherche seulement à acquérir des bonnes pratiques... ;) )
Pour mettre à jour ton dataset tu es de toute façon obligé de faire un aller/retour serveur justement c'est dû à l'architecture web. :). Tu ne peux pas envoyer le dataset au client, que celui-ci le manipule autant qu'il veut et puis qu'il le renvoie une fois pour toute (comme tu pourrais le faire en winform)Citation:
Envoyé par stephane.net
Si bien sûr, c'est le même genre de code à ceci près que tu le contrôles entièrement puisqu'il est de ton cru :) et que si tu codes correctement, tu peux même envisager réutiliser cette DAL dans tout autre type de projet (winform, console, web service).Citation:
Envoyé par stephane.net
Bonjour,
En parlant de transactions, quelqu'un a une idée de la meilleure façon de l'implementer dans ce genre d'appli. Bien sùr, j'utilise un dataset typé et des TableAdapter pour chaque table de ma base de données ?????
Merci pour tout.
Cette question est très pertinente ...Citation:
Vous avez souvent rencontré des développements Web utilisant le mode déconnecté à 100%?
Si on supposes en mode Web l'utilisation d'un dataset unique partagé au niveau de l'application, comment sera il chargé ? Les données de toute la bd seront chargées ou cela va être fait "à la demande" ??
Et du coup après maj la version des données chargée dans le dataset est obsolète ...Citation:
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.
Moi je crois que le choix de travailler en connecté ou déconnecté dépend aussi du type d'application, de la fréquence des mises à jour, de la criticité même de ces mises à jour. Immaginez un ERP où plusieurs personnes travaillent sur base commune et que chacun doit bosser sur une vue des données et mettre à jour pour que ce soit disponible pour les autres ...
Juste une question :
Pour architecture vraiment scalable, si on on veut pouvoir évoluer vers le load balancing, y'a 'il un moyen de gérer les contraintes d'unicité autrement que dans le SGBD ?
C'est à dire, si on a deux serveurs web qui tapent la même BDD...
Le problème pourrait aussi se poser si tu as un système qui fonctionnent avec des sites qui ont leurs données respectives c'est à dire non directement connectées à la base centrale (en temps réel !).
Comment comptes tu vérifier ces contraintes sans passer pas le SGBD central ? (notamment au moment de la réplication).
Sinon le débat est passionnant, des solutions existent peut être ...:)
A ma connaissance seul le SGBD gere l'integrite transactionnelle.Citation:
Envoyé par Mose
J'ai pas tout lu mais si sur un site Web des personnes font des saisies et traitements dans leur coin les donnees ne seront plus a jour apres pour les envoyer dans le SGBD.
Seul le SGBD gere l'unicite vu que c'est lui qui conserve et manipule les donnees
Ce genre d'ERP n'existe pas ou bien on n'a pas la meme notion d'ERP.Citation:
Envoyé par jpelaho
Si tu prends un ERP comme PeopleSoft tu construits des Forms et chaque champs est rattache directement a un SGBD.