Version imprimable
En .Net, il y a en général deux modes de connexion : mode connecté et mode déconnecté.
Pour un projet winform avec une base de données (mysql ou SQL Server), quels sont les facteurs qui doivent déterminer le choix du mode de connexion à utiliser ?
Dans quels cas faut-il utiliser l'un ou l'autre ? quels sont leurs avantages et inconvénients ?
Merci d'avance pour vos apports.
cela va dépendre de plain de choses entre autres : ta strategie de deploiement (donc l'emplacement de tes differents composants), des scenarios d'utilisation de ton application (et de son architecture),...
Je peut pas te conseiller un mode en particulier...
En gros, tu peux comparer ces modes à des appels synchrones / asynchrone.
Quelles sont les caractéristiques et contraintes de ton système ?
Mon application C# se connecte à une base de données mysql. Pendant toute la journée de travail (de 7h30 à 16h30) 5 caissiers, 2 laboratins, 1 magasinier, 1 administrateur et 1 superviseur seront en permanance connectés à la BD. Puis après fermeture des caisses, des états seront imprimés.Citation:
Envoyé par SaumonAgile
Je pencherais pour de l'O/RM dans les traitements standards.
Pour ce qui est de la consultation pure, sans interaction, tu peux renvoyer des datatables pour ne renvoyer que les données nécessaires.
Peux-tu être un peu plus explicite ? :koi: Je ne suis pas sûr d'avoir bien compris ta suggestion. MerciCitation:
Envoyé par SaumonAgile
En général, le mode deconnecté est conseillé pour les grands cas d'utilisation, telsque les bases de données des banques. Ces sociétés utilisent des bases de données reparties et la connection à travers la base de données centrale et les autres autres bases de données est generalement couteuse, puisqu'elle passent generalement par des sociétés privées.
Pour minimiser les couts, le mode deconnecté est conseillé ( travailler sur le dataset, et a la fin une mise a jour).
Mais pour ton cas (les petites applications) je pense que le probleme ne se pose pas, tu peux soit utiliser l'un, soit utiliser l'autre.
Personnellement, je te conseille le mode connecté, pour eviter les "updateCommand" qui est souvent la bete noite...
regales toi:king:
je m'incruste, comment vous faites du mode connecté en .NET ?
Citation:
Envoyé par sperot51
Code:DataReader et compagnie
le datareader n'est pas déconnecté ??
Mode déconnecté = DataSet = Conteneur de données image exacte de la source, tu travailles sur la copie déconnectée et tu synchronise après.
Mode connecté = DataReader = tu n'as pas de copie locale des données (même si tu fais de l'O/RM), et tu dois travailler directement sur la source de données.
Les objets que tu peux générer avec de l'O/RM à partir des données de la source ne sont pas considérés comme une copie locale des données. Conceptuellement, il s'agit d'une représentation spécifique non liée à la source.
Bonjour,
Je dirais que cela dépend de la nature de ton application :
- cette appli effectue-t-elle principalement des traitements de données (ex : affichage de listes, renseignement de champs sur des fiches, etc.) ou fera-t-elle des calculs (ex : bcp de règles de gestion ou d'algo) ?
- les données sont-elles privées, propre à chaque utilisateur (ex : je remplis ma fiche et je l'enregistre) ou sont-elles partagées entre tous les utilisateurs (ex : accès concurrent aux mêmes données) ?
- quelle réactivité souhaites-tu ? Le superviseur doit-il visionner en temps réel l'activité ou les états imprimés la nuit suffisent-ils ?
- etc.
Ces considérations t'aideront à déterminer si ton application peut être :
- un client lourd : chaque client manipule directement les données
- un système distribué : chaque client manipule des objets fournis par un serveur d'appli qui se charge de manipuler les données de manière centralisée (une seule connexion).
Je dirais que "connecté" ou "déconnecté" ne sont pas nécessairement les bons termes de l'équation. Car si tu optes pour une appli distribuée, la couche données sera forcément centralisée. Dès lors, cette couche d'accès aux données se débrouillera avec sa connexion à la base sans que cela ne concerne les autres composants de l'application. Par contre, si tu optes pour un client lourd, pourquoi t'embêter à te déconnecter de la base ?