Discussion :

[Benallasiham]

bon j'ai une decision à faire : connecté ou déconnecté je veux commencer le dévloppement de mon application vb.net et mysql

c'est déstiné à etre utilisé par plusieurs personnes donc la base de données doit gérer leur requete simultanément alors je pense que mode déconnecté n'est pas un bon choix mais au meme temps je crois que mode connecté va
diminuer l'efficacité de réponse au niveau du temps ou si vous voulez performance .je dois me décider et je ne sais pas vraiement ,j'aimerai bien avoir votre avis vous les experts

[callo]

J'étais confronté à un choix pareil il y a de cela quelques années . Peut-être que mon ancien topic pourra t'orienter.

[Benallasiham]

lol le résultat c'est mode connecté mais je suis déçu la, ce topic est ancien alors il me faut combien du temps pour être pro lool quand ça sera vous allez être dans l'espace entrain de programmer hhhh juste pour rigoler merci bcp pour votre reponse

[callo]

lol le résultat c'est mode connecté mais je suis déçu la

déçu? pourquoi?

ce topic est ancien alors il me faut combien du temps pour être pro

En parlant de topic ancien, je viens de tomber sur celui ci qui pourra très bien t'éclairer aussi.

[Benallasiham]

deçu par ce que je sens que je suis dépassé la c'est juste pour rire pas plus merciiiii bcpppppp ah! quel était votre choix ?

[callo]

quel était votre choix ?

J'avais finalement opté pour le mode déconnecté. D'autres contraintes ont été ajoutés et après étude, j'ai vu que le mode déconnecté était plus approprié.

[Pol63]

je m'attendais à me trouver dans les liens ^^

et je n'ai pas tellement évolué depuis, qu'appelez vous mode connecté ?

[callo]

Bonjour Pol63,

Généralement, quand on parle de mode connecté, la première chose qui vient à l'esprit c'est le DataReader. Le DataReader offre un accès direct et connecté aux données. Dans les scénarios où il faut effectuer une simple consultation de données, le DataReader est plus performant que le Dataset. Il agit comme un pointeur sur les données en lecture seule permettant ainsi d'alléger l'accès au serveur.

Le mode déconnecté --> DataSet : il agit comme un cache de données. C’est en quelque sorte une copie en mémoire de la base de données. On peut donc manipuler les données qu'il contient comme des enregistrements d'une table. Une fois les données chargées dans le DataSet, l'on peut effectuer des requêtes comparables à des filtres sans se reconnecter systématiquement à la base de données. Tout comme dans une vrai base de données, les données peuvent être relationnelles ou non.

Le DataSet est rempli via un DataAdapter. Ce dernier établit la connexion entre le DataSet et la base de données et rend possible les mises à jour.

Le choix entre les deux modes dépend de bien de paramètres et contraintes.

Prenons un cas où on peut avoir 100 personnes utilisant en permanence un programme. ça te fait 100 connections ouvertes en permanence sur ta base. Imaginons donc pour 500, 1000 users .... Dans un tel cas, le mode déconnecté serait plus approprié.

[Kropernic]

Et si je vous dit que je fais du mode déconnecté sans dataset et avec des datareaders ?

Article (en cours de traduction par rv26t)

[youtpout978]

La plupart du temps on utilise le mode connecté quand on a une connexion a la bdd disponible, mais si l'application est amenée à être utilisée dans des cas où aucune connexion à la bdd est disponible le mode déconnecté est justifié pour continuer à pouvoir utiliser l'appli (souvant pour des applis destinées à des appareils portable comme des pda ou autre).
Quand on est en mode connecté on garde pas la connexion ouverte pour tous les utilisateurs on l'ouvre que quand quelqu'un en a besoin et on la réutilise.
Le mode déconnecté amène des problèmes de stockage et mise à jour des données, comment je stock mes données sur mon appareil, qu'est ce que je stock, comment je synchronise mes données une fois connecté ...
Si ta 10 utilisateurs simultanés sur ton appli peut importe le moteur de bdd il devrait pas plier à moins d'avoir un serveur/connexion merdique ou une bdd codée avec les pieds.

[Pol63]

mouais, donc pour info le dataadapter utilise un datareader pour remplir le dataset, le datareader étant le seul objet permettant de lire des données

le datareader ne sert qu'à lire les données, en aucun cas ca ne saurait être du mode connecté pour moi

le vrai mode connecté tel qu'on l'avais dans v6b il me semble c'est l'histoire des pessimistic optimistic et autre, on avait réellement un objet connecté aux données, avec un curseur qui restait réellement ouvert

mais le datareader c'est un foward only, et tous ceux qui l'utilisent stockent forcément les données, lire des données pour ne rien en faire c'est dommage, et traiter les données pendant la lecture est une mauvais idée, ca garde la connexion ouverte plus longtemps que stockage puis traitement
donc pour moi en .net on fait du déconnecté un point c'est tout

le dataset au contraire bien que je le connaisse peu intégrerait un gestion de connecté, car en cas de modif il refait une requete pour voir si la valeur est toujours la même, nous laissant ainsi gérer le cas

et en mode déconnecté on peut aussi gérer un rafrachissement des données

[azstar]

Pour le choix du mode connecté ou déconnecté dépend en fait de quel axe tu veux améliorer rapidité ...

Pour moi un mode déconnecté :

avantage : minimiser les trafics réseau...
inconvénient : application peux ramer dans le cas ou tu a des grosses quantités de données à charger dans un dataset...


Pour moi un mode connecté :

avantage :Application ne charge pas une grosse quantité de données bien sur dans un cas tu ne fait pas de grosse requête....

NB: tu peux aussi charger tes données référentielles dans des enumerations vu que ces données sont peu changées.
inconvénient : beaucoup de trafics réseau....

J’espère que j'ai rien dis de bêtises