IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Entity Framework Discussion :

Best practice pour application Winform Entity Framework


Sujet :

Entity Framework

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    88
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Août 2006
    Messages : 88
    Points : 62
    Points
    62
    Par défaut 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 !

  2. #2
    Invité
    Invité(e)
    Par défaut
    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.

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    88
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Août 2006
    Messages : 88
    Points : 62
    Points
    62
    Par défaut
    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 :
    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
    (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 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 )

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    88
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Août 2006
    Messages : 88
    Points : 62
    Points
    62
    Par défaut
    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

  5. #5
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par zesamoth Voir le message
    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 Voir le message
    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.

    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 Voir le message
    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 Voir le message
    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.

  6. #6
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par zesamoth Voir le message
    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 Voir le message
    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.

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    88
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Août 2006
    Messages : 88
    Points : 62
    Points
    62
    Par défaut
    Merci pour ta réponse, je comprend ton incompréhension () par rapport à ce que tu dis :
    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

    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

    En tout cas merci pour ton aide !

  8. #8
    Membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    88
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Août 2006
    Messages : 88
    Points : 62
    Points
    62
    Par défaut
    Citation Envoyé par h2s84 Voir le message
    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 Voir le message
    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

  9. #9
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par zesamoth Voir le message
    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 Voir le message
    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.

  10. #10
    Membre du Club
    Profil pro
    Inscrit en
    Août 2006
    Messages
    88
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Savoie (Rhône Alpes)

    Informations forums :
    Inscription : Août 2006
    Messages : 88
    Points : 62
    Points
    62
    Par défaut
    Oui je me suis effectivement mal exprimé 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.

  11. #11
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2009
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 048
    Points : 2 201
    Points
    2 201
    Par défaut
    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).

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Flex] Recherche de Best Practice pour l'alignement
    Par eXiaNazaire dans le forum Flex
    Réponses: 5
    Dernier message: 11/02/2008, 17h14
  2. Best practice pour un insérer/remplacer
    Par Antoun dans le forum SQL
    Réponses: 2
    Dernier message: 09/01/2008, 14h10
  3. Réponses: 4
    Dernier message: 17/11/2006, 11h46
  4. Réponses: 11
    Dernier message: 16/06/2006, 14h46
  5. Réponses: 4
    Dernier message: 23/05/2006, 15h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo