Discussion :

[Invité]

Bonjour, en fait mon post à plus trait aux bibliothèque de classes.

J'en ai créé une pour gérer mes objets métiers entres mes projets ASP.NET, WinForms et WPF. J'arrive depuis ma bibliothèque à accéder par exemple dans le cadre d'un Projet ASP.NET à l'objet HTTPContext pour obtenir le contexte HTTP courant, et piocher dans les variables sessions depuis ma bibliothèque de classes.

J'aurais aimé savoir s'il était possible de la manière d'accéder depuis cette bibliothèque à l'application courante, dans le cas cette fois d'une application WPF et non plus d'un projet ASP.NET. J'y arrive depuis mon projet WPF par Application.Current, mais pas depuis ma bibliothèque.

Merci beaucoup.

PS : Ou plus généralement si vous savez comment accéder à un moyen de gérer un dictionnaire de données à la fois accessible depuis ma bibliothèque de classes et mon application WPF.

[Thomas Lebrun]

J'aurais aimé savoir s'il était possible de la manière d'accéder depuis cette bibliothèque à l'application courante, dans le cas cette fois d'une application WPF et non plus d'un projet ASP.NET. J'y arrive depuis mon projet WPF par Application.Current, mais pas depuis ma bibliothèque.

En termes d'architecture/design, je déconseille: ta bibliothèque doit travailler avec des types simples, correspondant aux valeurs de propriétés de la classe Application mais c'est tout....

[Invité]

Je l'ai conçu pour avoir des objets métier indépendants au mieux, l'objectif dans le cas présent est uniquement d'avoir une méthode partagée qui donne accès à la connexion courante à la base de donnée, que je n'ai pas à l'ouvrir sur chaque fenêtre de mon application. J'ai utilisé ce principe dans mon projet ASP.net en stockant la connexion courante en variable de session, cela fonctionnait assez bien. Je ne sais pas si je suis assez clair.

[Thomas Lebrun]

l'objectif dans le cas présent est uniquement d'avoir une méthode partagée qui donne accès à la connexion courante à la base de donnée, que je n'ai pas à l'ouvrir sur chaque fenêtre de mon application.

Cela va à l'encontre même des principes de .NET où la connexion doit-être ouverte le plus tard possible et refermer le plus tôt possible.... Mais en aucun cas restée ouverte.

[Invité]

Ok , c'est spécifique à .NET ? En fait j'ai toujours lu que c'était l'ouverture de la connexion qui prenait le plus de ressources. Pour quelle raison ça coince ?

[MetalGeek]

Ce n'est pas vraiment spécifique à .NET, c'est juste qu'il est d'usage de travailler en ce qu'on appelle le 'mode déconnecté'. Tu créés un objet 'requête' en mémoire, éventuellement un objet gérant une transaction, tu te connectes juste le temps de récupérer les données, ensuite tu bosses avec tes données représentées en mémoire (dataset, entities, classes perso...), et tu te reconnectes juste le temps t'envoyer la requêtes de MàJ à la BDD.

[Invité]

Merci pour la réponse, je savais pour le mode déconnecté en fait j'ai déjà travaillé avec des dataset et j'ai développé pour mon application un modèle CRUD, n'ayant pas accès au framework entities plus complet de VS 2010 et n'ayant pas spécialement de formation. En fait ce stockage de connexion venait du fait qu'on m'avait toujours dit que c'est l'ouverture de la connexion qui prenait le plus de ressources et qu'il valait mieux les limiter, d'où cette tentative. Après je n'ai jamais su à quel point, et si ce n'est pas si important niveau performance je ne m’embêterais plus.

Si vous avez une réponse par rapport aux performances je prends.