Best practice pour application Winform Entity Framework

Version imprimable

03/12/2011, 02h57
zesamoth

Best practice pour application Winform Entity Framework

Bonjour à tous,

En fait ma requête est toute simple. Je chercher à créer une application winform multi-utilisateur basée sur Entity Framework.
Pour l'instant je ne connais pas encore entity Framework et j'ai encore du mal à voir comment gérer l'accès et le partage de données par plusieurs instances d'une même application.

Je maitrise plutôt bien LINQ to SQL et j'ai construit plusieurs applications ASP.NET multiuser mais là le contexte de données LINQ etait partagé entre les utilisateurs puisqu'il etait déclaré et géré au niveau de l'application IIS (en singleton). Dans une winform il y a autant d'appli que d'utilisateurs donc je vois pas encore comment ça se passe (contexte géré à part, réinstancié à chaque appel, rafraichi à chaque requête, etc....)

Donc si quelqu'un pouvait m'orienter vers la documentation qui va bien pour répondre à ce genre de besoins je lui en serait fort gré !

Sur ce je vais me coucher et souhaite une bonne nuit à ceux qui lirait ce message avant de faire de même. Pour les autres ce sera Bonne journée !
03/12/2011, 11h07
Invité

Concernant la durée de vie du contexte EF je te conseille de lire cet article. Comme mentionné dans l'article, l'idée d'utiliser un singleton même dans du Linq To SQL n'est pas une bonne pratique.

Si tu choisis de gérer le contexte par formulaire comme moi, le seul problème que tu devrais avoir à prendre en compte est de gérer les conflits au niveau des données parce les données peuvent être modifiées alors qu'elles sont en cours d'utilisation par d'autre utilisateurs. Pour cela dans EF, l'exception OptimisticConcurrencyException te permet de les détecter.
03/12/2011, 12h22
zesamoth

Bonjour,

Je viens de lire l'article que tu m'as conseillé et il me semblait déjà avoir vu ce genre de choses.... Petite précision, mes applis portent sur potentiellement 1 600 users mais c'est rarement plus de 200/jours voir moins de 10 en simultané. Et les serveurs sont rebootés chaque nuit (donc vidage du context). Jusqu'à présent (environ 1 an de recul) on a pas eu de pbs.

Par contre si je peux me permettre de te demander quelques explications car il ya des choses que j'ai un peu de mal à comprendre.... Typiquement la dualité entre les deux phrases ci dessous :

Citation:

If we dispose the context after every database
manipulation or query we won’t enjoy the all the features it holds
(for example change tracking).

Citation:

Web applications – use the context per request

(encore qu'en l'écrivant je viens, je pense, de comprendre que la deuxième phrase parle de requête web je pense et la première de query. Donc une requête web peut comprendre plusieurs queries, ça se tient... ;) En relisant ça doit vraiment être ça. Me --> tout bidon :aie: Par contre utilisant AJAX des requêtes y'en a pas mal....

Ensuite au niveau des applications winform je me doutais un peu qu'il allait falloir gérer mes exceptions de conflit de base moi même.... Mais même sans ça, si je prend un énorme raccourci je pensais que la fonctionnalité "Cache" d'un contexte permettait, par exemple, ce genre de choses : Chargement d'une source de données via une requête (stockage mémoire en context), affichage dans un form par exemple, modification de la donnée, réaffichage de la grille SANS refaire toutes les requêtes de sélection puisque la modif est connue par le contexte. Dans le cas d'un contexte partagé cela peut fonctionner très bien. Est ce que je me fourvoit complétement ?

Et puis enfin tu me diras si je me trompe, mais le fait de gérer le contexte par formulaire ou par appli dans le cas d'une winform ne change pas forcément grand chose au fait que j'ai à gérer les conflits entre utilisateurs (ici seulement 4 ou 5 simultanés potentiels), right ?

Merci d'avance pour tes réponses (ou d'autres s'ils veulent participer :lol:)
03/12/2011, 12h28
zesamoth

En relisant ton message je me dis tu dois effectivement bien connaitre puisque tu a l'air de pratiquer aussi. Donc je voulais savoir pour ta part comment tu gérais les applications multiuser. Si je prend un cas concret par exemple. Une form avec une liste de données provenant d'une table. Tu as plusieurs utilisateurs qui peuvent potentiellement modifier les données. Tu as la possibilité de trier ta liste. POur t'assurer de la fraicheur des données.

A chaque chargement de la liste tu réinterroges la base ?
A chaque action sur la liste tu réinterroges la base (action = modif par ex ou tri) ?
Tu proposes un bouton "Rafraichir" ?

Merci d'avance pour ce que tu pourras me dire, j'avoue être encore un peu dans le flou :oops:
03/12/2011, 12h53
Invité

Citation:

Envoyé par zesamoth

Petite précision, mes applis portent sur potentiellement 1 600 users mais c'est rarement plus de 200 voir moins de 10 en simultané. Et les serveurs sont rebootés chaque nuit (donc vidage du context). Jusqu'à présent (environ 1 an de recul) on a pas eu de pbs.

D'après ton 1er post ton application est un client lourd en Winform donc installé sur les machines clientes et par sur un serveur. Chaque client exécute une instance sur sa machine à lui et le contexte (je parle du contexte EF) est utilisé par cette seule instance de ton application et il n'est pas partagé avec les autres instances s'exécutant sur d'autres machines clientes. Donc le fait que tu reboutes le serveur toutes les nuits c'est juste que la base de données (si elle est installée sur le seveur) ne sera pas disponible durant quelques minutes. Tout ça pour te dire que je ne vois pas le rapport entre ton serveur et ton contexte EF vu que tu bosses en Winform et c'est ce dernier qui stocke le contexte. À moins que tu sois en architecture 3-tiers Ex : Winform + Serveur d'application utilisant WCF hébergeant ta DAL EF + SGBDR. Là vu que t'as un serveur d'application on peut encore se poser la question sur le partage du contexte EF mais cela ne change en rien dans ce qui est dit dans le lien que je t'ai fourni.

Citation:

Envoyé par zesamoth

If we dispose the context after every database
manipulation or query we won’t enjoy the all the features it holds
(for example change tracking).

Web applications – use the context per request

La première phrase parle de l'inconvénient de faire un Dispose sur le contexte à chaque fois qu'une requête EF (Linq To Entities par exemple) est effectuée vers la base. Le fait de détruire le contexte après chaque requête EF nous empêche de bénéficier des fonctionnalités telles que le tracking des changements des entités etc parce que seul le contexte gère ces genres de trucs. :ccool:

La deuxième phrase est une solution que l'auteur fourni mais vu que tu l'as sorti de son contexte en la rattachant à un inconvénient qu'il avait déjà cité cela change la compréhension du problème.
L'auteur a fourni 2 solutions en fonction que tu sois en client lourd (Winform, WPF etc) ou en client léger (ASP.Net, ASP.Net MVC etc). Pour le cas d'un client lourd l'auteur propose d'avoir un contexte EF par formulaire et pour un client léger d'en créer un à chaque requête HTTP vers le serveur.

Citation:

Envoyé par zesamoth

Dans le cas d'un contexte partagé cela peut fonctionner très bien. Est ce que je me fourvoit complétement ?

Va falloir faire gaffe avec cette méthode vu que les entités sont chargées par un seul et même contexte durant toute la durée de vie de ton application, tu risques de charger toute ta base de données sur le client au fur et à mesure que l'utilisateur parcours les formulaires.

Citation:

Envoyé par zesamoth

Et puis enfin tu me diras si je me trompe, mais le fait de gérer le contexte par formulaire ou par appli dans le cas d'une winform ne change pas forcément grand chose au fait que j'ai à gérer les conflits entre utilisateurs (ici seulement 4 ou 5 simultanés potentiels), right ?

Dans le cas de client lourd on privilégie un contexte par formulaire et non par application. Sinon je suis d'accords avec le reste.
03/12/2011, 12h58
Invité

Citation:

Envoyé par zesamoth

A chaque chargement de la liste tu réinterroges la base ?

Je ne pense qu'on ait besoin d'interroger la base de données à chaque fois qu'on a besoin de faire un tri. Cela se fait en locale vu que tu as déjà les données en mémoire.

Citation:

Envoyé par zesamoth

A chaque action sur la liste tu réinterroges la base (action = modif par ex ou tri) ?

Cela n'est pas une bonne méthode je pense. Laisse l'utilisateur effectue ces modifications et une fois finie il cliquera sur le bouton qui servira à rapatrier les données vers la base. Si lors de lenvoi des données vers la base tu rencontres une exception du type OptimisticConccurencyException tu lui informes que les données ont été modifiées par une personne et qu'il faut qu'il rafraîchissement ces données.
03/12/2011, 13h45
zesamoth

Merci pour ta réponse, je comprend ton incompréhension (:lol:) par rapport à ce que tu dis :

Citation:

D'après ton 1er post ton application est un client lourd en Winform donc installé sur les machines clientes et par sur un serveur

Non non, d'après mon premier post je fais bien des applications en ASP.NET qui tournent sous un serveur IIS pour un intranet local. Et c'est bien ce IIS qui est rebooté chaque nuit et non le SQL, le contexte à donc une durée de vie d'un jour. D'ou le fait comme tu dis que tu vois pas le rapport avec le contexte EF partagé (bon dans mon cas c'est du LINQ to SQL mais il est bien partagé sur une seule instance d'application IIS). Avec cette incompréhension mutuelle du coup je vais faire l'impasse sur tout ton premier paragraphe :zoubi:

Par contre c'est bien toute la base de ma réflexion sur le fait qu'en Winform, ce que je cherche à faire à partir de maintenant, il n'y a effectivement pas de partage de contexte (sauf si je faisais du 3 tiers ce que je n'ai pas l'intention de faire - encore que je n'exclu pas à 100% la possibilité)

Je vais donc m'orienter vers un contexte de données par form avec la possibilité pour l'utilisateur de rafraichir les données via un bouton ou ce genre de choses. Je comprend en fait ce que tu dis. Le but est de charger les données dans le contexte indépendamment pour chaque utilisateur et de laisser le contexte EF tracer les conflits sur la base pour éventuellement proposer le rafraichissement à l'utilisateur (voire le faire tout seul automatiquemennt tant qu'à faire ?). Dans un sens avant que j'utilise les ORM c'était déjà bien ce que je faisais :D

En tout cas merci pour ton aide !:ccool:
03/12/2011, 13h48
zesamoth

Citation:

Envoyé par h2s84

Je ne pense qu'on ait besoin d'interroger la base de données à chaque fois qu'on a besoin de faire un tri. Cela se fait en locale vu que tu as déjà les données en mémoire.

Clairement, remarque absurde de ma part....

Citation:

Envoyé par h2s84

Cela n'est pas une bonne méthode je pense. Laisse l'utilisateur effectue ces modifications et une fois finie il cliquera sur le bouton qui servira à rapatrier les données vers la base. Si lors de lenvoi des données vers la base tu rencontres une exception du type OptimisticConccurencyException tu lui informes que les données ont été modifiées par une personne et qu'il faut qu'il rafraîchissement ces données.

OK
03/12/2011, 13h49
Invité

Citation:

Envoyé par zesamoth

En fait ma requête est toute simple. Je chercher à créer une application winform multi-utilisateur basée sur Entity Framework.
Pour l'instant je ne connais pas encore entity Framework et j'ai encore du mal à voir comment gérer l'accès et le partage de données par plusieurs instances d'une même application.

Bah ! Là tu dis bien que tu cherches à créer une application Winform et EF et que c'est ton problème actuellement.

Citation:

Envoyé par zesamoth

Je maitrise plutôt bien LINQ to SQL et j'ai construit plusieurs applications ASP.NET multiuser mais là le contexte de données LINQ etait partagé entre les utilisateurs puisqu'il etait déclaré et géré au niveau de l'application IIS (en singleton). Dans une winform il y a autant d'appli que d'utilisateurs donc je vois pas encore comment ça se passe (contexte géré à part, réinstancié à chaque appel, rafraichi à chaque requête, etc....)

Là tu dis tu as déjà fait de l'ASP.net etc... etc.. et qu'en Winform tu as des problèmes que tu n'as pas eu en faisant de l'ASP.Net.

Bref, bonne recherche pour la suite et bon code. :ccool:
03/12/2011, 14h07
zesamoth

Oui je me suis effectivement mal exprimé :oops: Je fais actuellement de l'ASP.NET et je cherche à faire dans un futur proche du winform pour lequel je subodore que je rencontrerais des problèmes que je n'ai pas avec ASP.NET sous IIS.

En tout cas merci pour ton aide je tope en résolu, y'a des pistes dans ce post.
07/03/2012, 15h11
sinople

Discussion très intéressante,

J'ajouterai juste qu'il faut aussi faire attention, dans une application Winforms, à éviter d'avoir 2 contextes en parallèle (avec des sets d'entité commun). Ceci afin d'éviter de créer des problèmes d'accès concurrentiels entre 2 formulaires par exemple (voir à l'intérieur d'un formulaire).

Dans le cas d'une base de donnée de faible taille, il peut aussi être intéressant d'avoir un context commun pour l'entier de l'application (avec un singelton par exemple).