Discussion :

[randriano]

Bonjour,

Ce que je pense à faire c'est la simulation de transactions côté Entity Framework mais pas côté base de données puisque je travaille avec MySql mais pas SQL Server ou Oracle.
Une fenêtre de mon application ouvre une sous-fenêtre où on effectue des actions, cette sous-fenêtre peut encore ouvrir une autre sous-fênetre. En principe il faut donc un transaction différente pour chaque sous-fenêtre, c'est donc la fenêtre mère qui détient le pouvoir de stocker toutes les modifications vers la base de données.
Mon soucis c'est que je transfère comme suit le contexte d'une fenêtre WPF à une autre:

Code vb.net :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
Private Sub EditDetailPlan() Handles btnDetailsPlan.Click
	Dim Win As New WinPlanningDetails
 
	Win.Context = Context
 
	Win.Owner = PlanningWizardStep3.ParentWindow
	Win.ShowDialog()
End Sub

Context est l'entité correspondant à un fichier EDMX (mediaEntities).
Est-ce que c'est bon ce que je fais là, juste passer le contexte à la classe de la sous-fenêtre dont le code est:

Code vb.net :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
Imports System.Collections.ObjectModel
Imports System.Windows.Interop
Imports System.ComponentModel
Imports System.Data.Objects.DataClasses
Imports System.Threading
 
Partial Public Class WinMediaPlanningDetails
    Public Context As mediaEntities
....................

Le soucis maintenant c'est que je ne sais pas gérer la transaction: j'ai déjà un bouton Enregistrer qui a pour action SaveChanges() mais cela ne sert à rien puisque même si on ferme la sous-fenêtre c'est enregistré!

[Invité]

Le soucis maintenant c'est que je ne sais pas gérer la transaction: j'ai déjà un bouton Enregistrer qui a pour action SaveChanges() mais cela ne sert à rien puisque même si on ferme la sous-fenêtre c'est enregistré!

N'oublie qu'une transaction est automatiquement crée lorsque tu fais appel à la méthode SaveChanges de ton context.

Pour ce qui est de l'enregistrement c'est impossible que ça soit le cas si on ferme la fenêtre à moins tu n'appelles SaveChanges dans l'évènement de fermeture.

Pour info, pour annuler les modifications apportées aux entités de ton context, tu fais appelle à la méthode RefershChanges

[randriano]

En fait, j'utilise SaveChanges pour sauvegarder les modifications effectuées sur le contexte c'est à dire avant Close() dans le bouton OK de ma fenêtre!

Le soucis c'est que quand je fais Alt+F4 les modifications sont toujours affectées c'est à dire que si je ré-ouvre la fenêtre, j'ai toujours la fenêtre, mes données que j'y avais saisies sont encore là! Normal puisque c'est le même contexte que la fenêtre mère mais je cherche comment éviter cela???!!

Concernant la fonction Refresh(), je ne sais pas comment l'utiliser puisqu'il demande un 2ème argument IEnumerable dont je ne sais pas quoi y mettre

[Invité]

ALT + F4 correspond à la fermeture de ta fenêtre alors ce que tu devrais faire c'est d'ajouter un gestionnaire de l'évènement Closing et dans celui tu ajoutes

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
context.Refresh(lobjet_sur_lequel_annulé_les_modifications);

Pour infos Refresh possède deux surcharges, l'une pour annuler les modifications sur un graphe d'objet implémentant IEnumarable et l'autre pour annuler les modifications sur un objet.

[randriano]

Mon Context.Refresh ne veut que 2 arguments sinon ça ne compile pas:

Overload resolution failed because no accessible Refresh accepts this number of arguments

Il semble aussi que ma situation n'est pas encore clair, j'aimerais annuler tous les changements effectués sur Context dans la fenêtre mais pas sur lobjet_sur_lequel_annulé_les_modifications uniquement.
Il s'avère que c'est difficile voire impossible puisque c'est le même contexte que la fenêtre mère:

Code vb.net :

Sélectionner tout - Visualiser dans une fenêtre à part

Win.Context = Me.Context 'Me = fenêtre mère/parent

Je ne sais pas mon lobjet_sur_lequel_annulé_les_modifications dans ce cas car les changements que je fais c'est:

Code vb.net :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Context.AddTomessages(msg)
...................
Context.DeleteObject(objParution)
...................

Autre question: pourquoi TransactionScope est toujours "is not defined" chez moi?

[Invité]

Je ne sais pas ce que t'as pas compris mais peut-être en lisant ça tu pourras résoudre ton problème.

[randriano]

Mon problème n'est pas d'ordre accès concurrentiel mais d'ailleurs concernant cette page, il y a la ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

context.Refresh(RefreshMode.ClientWins, orders)

C'est quoi "orders"?

Pensez-vous que ce que je cherche n'est pas la transaction?

[anthyme]

Sinon il y a une autre solution, ne pas utiliser un seul object context mais en utiliser un différent dans chaque fenêtre comme cela les interactions sur les objets d'un écran à l'autre ne sont pas impacté.

Car même si le refresh peu résoudre certains problèmes, il ne les résoudra pas tous.

Imaginons :
- tu lance l'application
- tu ouvres une fenêtre 1 avec un objet A
- tu modifies l'objet A
- tu ouvres une fenêtre 2 avec un objet B
- tu modifies l'objet B
- tu fais "ok" sur la fenêtre 2 (elle se ferme)
- tu fais "cancel" sur la fenêtre 1

Le résultat attendu est que l'objet B est modifié et que l'objet A est resté comme avant de lancer l'application.

Pourtant si tu utilises un seul object context pour toute l'application, lors du "ok" de la fenêtre 2 tu aura sauvegarder les modification de l'objet B ET l'objet A.

Voila pourquoi un objectcontext ne devrait jamais être un singleton qu'on soit en web ou en client lourd

[randriano]

Un Object Context différent à chaque fenêtre, ça m'est aussi passé par la tête!
J'étends ton imagination sur quatre (4) couches au lieu de 2 car c'est mon cas:
- tu lance l'application
- tu ouvres une fenêtre 1 avec un objet A
- tu modifies l'objet A
- tu ouvres une fenêtre 2 avec un objet B
- tu modifies l'objet B
- tu ouvres une fenêtre 3 avec un objet C
- tu modifies C
- tu ouvres une fenêtre 4 avec un objet D
- tu modifies D
- tu cliques OK pour enregistrer sur D, et la fenêtre 4 se ferme
- tu cliques Annuler sur la fenêtre 3 et elle se ferme, les modifications sur la fenêtre sont donc 4 perdues
- etc ....

Comment gérer cet empilement des contextes? car dans ton exemple, on peut avoir objet B sauvé et objet A annulé donc perdu!

[randriano]

Voila pourquoi un objectcontext ne devrait jamais être un singleton qu'on soit en web ou en client lourd

D'abord je suis en client lourd!
Dans mon cas, je pense préférer rester en singleton puisque si je crée un contexte différent, les données de la fenêtre D sont sauvées dans la base de données tandis que je cliquerais Annuler dans la fenêtre B, celles de B perdues.

Le fait est que les données de ces fenêtres correspondent à leur emboîtement (tables filles et parents)

[anthyme]

Ok comme tu le sens

[randriano]

Ok comme tu le sens

mais je suis toujours dans le vide

Le fait d'utiliser un singleton me rend impossible l'Annuler!!!
Je me demande comme fais-tu si un context à chaque fenêtre alors que ces fenêtres utilisent des données emboitées c'est-à-dire dépendant l'un de l'autre.
Par exemple comme j'avais dit, avant (actuellement) en singleton, je fais des Context.AddTomessages(msg) et Context.DeleteObject(objPar), c'est pour ça que Refresh() n'est plus possible puisqu'on ne sait plus quoi mettre comme IEnumerable et que ni StoreWins ni ClientWins ne sert à rien puisqu'aucune donnée n'est encore placée dans la BD!!

Officiellement, je suis à la recherche d'un "sample" (exemple) plus détaillé d'utilisation d'Ado.Net Entity Framework. J'ai beau cherché sur MSDN mais je n'ai trouvé que "Course Management" qui n'est qu'un hello world! J'aimerais m'inspirer de leurs techniques de gérer des tables qui s'emboîtent mais surtout de l'Annuler

[anthyme]

Perso quand je bosse sur des application WPF, elles sont en général en mode ntier, donc mes entités n'ont aucun lien direct avec la base de données.

La plupart des gens que j'ai vu faire du WPF => EF directement ont eu pas mal de soucis (binding des navigation property 1 => n, bug dans les notify propertychanged sur les entités attaché, etc ...)

Si l'option mutli contexte ne te tente pas (et les contextes ça ne "s'empilent" past) tu peux essayer une autre approche qui me semble la plus propre (mais avec un "surcoût") : travailler uniquement sur des entités détachés.

tu créer une couche de services avec des methodes par entités GetAll/Create/Update/Delete/Refresh/commit etc ... et quand tu envoie des entités dans ces méthode tu les attach et quand tu fais sortir des entités de cette couche tu les dettach

Comme ca tu peux gérer ce qu'il se passe exactement comme tu veux et tu n'auras pas d'impact entre les fenêtres entre les mais c'est à toi d’appeler les bonnes méthodes

[randriano]

Tu créer une couche de services avec des méthodes par entités GetAll/Create/Update/Delete/Refresh/commit etc ... et quand tu envoies des entités dans ces méthodes tu les attach() et quand tu fais sortir des entités de cette couche tu les detach()

Oui c'est un peu comme ça que je voudrais procéder mais étant nul en EF, est-ce que tu peux me filer un bout de code?

Bref, d'un point de vue barbare, ce que cherche à faire c'est donc créer une copie du contexte avant d'entrer dans une fenêtre, travaillez sur cette copie dans cette sous-fenêtre car pour l'instant je travaille pas en copie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Win.Context = Context

, ce n'est pas une copie mais le contexte lui-même (singleton dit-on?)