.NET GUI

Hallo,

beschäftige mich seit ein paar Monaten mit dem Entity Framework v1 und WinForms mit MVP Pattern. Bin nun auf WPF umgestiegen mit MVVM und stoße an die Grenzen von MVVM oder dem EF. Kommt drauf an was zuerst da war ;-)

Mit MVVM habe ich ja ein Model z.B. Customer welches IDataErrorInfo implementiert usw. die Models die mir vom Entity Framework generiert werden sind anders.

Nun könnte ich für jede EF Entität ein Pendant machen für mein ViewModel , schauen obs valide ist, wenn ja das MVVM Model dem CustomerRepository übergeben. im CustomerRepository dann das EF Customer Model instanziieren und die Daten wie Vorname, Nachname des MVVM Models dem EF Model object zuweisen anschließend den Context.Save() machen damits in der Datenbank gespeichert wird.

1.) Würdet Ihr das so auch machen, oder ist das EF ungeeignet für MVVM? Gibt es Alternativen mit denen das ganze richtig geht ohne das ich 2 Customer Klassen haben?

Dieser Link beschreibt genau mein Problem: http://groups.google.com/group/altnetseattle/browse_thread/thread/008aeeb41ceca551

2.) Nehmen wir an ich hätte 10 MVVM Models (nicht EF). Muss ich alle 10 Models in einer MainWindowsViewModel Klasse instanziieren? Wie in dem Beispiel: http://msdn.microsoft.com/de-de/magazine/dd419663.aspx

oder brauche ich das MainWindowsViewModel nicht? Und ich erstelle mir 10 XXXViewModel Klassen mit je einem Repository. Sehr verwirrend das ganze mit dem EF zu verquicken...

ok es scheint so, dass das EF auch auch INotify on Properties hat: http://blog.nicktown.info/2008/12/02/entity-framework-doesnt-support-inotifypropertychanged-on-some-properties.aspx

Das würde ja bedeuten ich könnte anstatt MVVM Model die EF Models nehmen und im CustomerViewModel eben eine Customer Instanz erzeugen mit den entsprechenden Properties die gemappt sind auf die Tabellenfelder der Customer Tabelle.

Dann würde ich das _customer object an mein CustomerRepository.AddCustomer(_customer); übergeben nur das ist irgendwie sinnlos jetzt, denn außer einem:

public void AddCustomer(Customer customer)
{
      context.AddToCUSTOMER(customer);
      context().SaveChanges();
}

würde ich ja nicht viel machen, kann ich ja gleich im ViewModel machen, wenn dort das Domänenmodel eh bekannt ist ... was ich aber nicht möchte!

Hallo,

Was das Interface IDataErrorInfo betrifft: Dieses solltest du im ViewModel implementieren und nicht im Model. Daher kannst du die vom EF generierten Models ohne Probleme und ohne Änderung verwenden.

Was generell deine ViewModels betrifft: Du hast für jede View ein ViewModel. Deine View kann nun ein Fenster, eine Seite oder ein Steuerelement sein. Wie granular du dies handhabst, bleibt dir überlassen.

Über das ViewModel kannst du dein Repository ansprechen. Idealerweise hast du hier eine eigene Schicht, welches die Anforderungen für dich erfüllt und somit nur mehr geringen Aufwand im ViewModel verursacht.

Ich denke, du siehst den Begriff des MVVM Model zu eng. Das Model ist dein Datenobjekt. Das kann natürlich ein EF Objekt sein, keine Frage. Wichtig ist für dich das ViewModel, welches die Validierung vornimmt (hierzu gibt es in der nächsten Ausgabe 04/09 der Visual Studio One einen langen Artikel von mir mit einem generischen Ansatz), das Laden/Speichern/Löschen der Daten antriggert und auf andere Aktionen reagiert.

Ich hoffe, das hilft dir mal soweit weiter.

 

 

sehe ich das richtig, die Ausgabe erscheint im Juni 09 ? Ist natürlich sofort gekauft!!!!!!! Danke dir!

Wie zwischen ViewModel und Repository eine eigene Schicht nochmals?

Ja, sollte im Juni erscheinen.

Zu meinen ViewModel-Ausführungen: Haben sie dir weitergeholfen?

ups du warst etwas schneller im schreiben als ich im editieren ^^

Wie zwischen ViewModel und Repository eine eigene Schicht nochmals erstellen? Wie wird diese Schicht genannt?

Über das Repository beziehst du deine Daten, korrekt?

Du hast ein ViewModel, dieses kommuniziert mit dem Repository, lädt Daten nach, speichert darüber Daten etc. Die Daten selbst liegen in einem Model (das kann ein einzelnes Datenobjekt, oder eben auch eine Liste sein). D.h. wenn das Repository für dich schon alles macht was du brauchst, dann brauchst du keine weitere "Zwischenschicht" :)

Das ist genau das was ich meinte, ich habe das ViewModel hier führe ich meine _customerRepository.AddCustomer(customer); und in der AddCustomer mache ich context.AddCustomer(customer); context.submit/save

 Von was für einer Zwischenschicht hast du geredet?

Ich persönlich abstrahiere den Zugriff auf solche Dinge wie Repositories etc. immer, um dies einfach austauschen zu können. Das hatte ich gemeint, kannst du aber ignorieren :)

hm...  den Zugriff auf das CustomerRepository auch noch abstrahieren? Demnach  rufst du in deiner ViewModel Klasse zwischenschicht.AddCustomer(customer); auf und in der zwischenschicht klasse dann customerRepository.AddCustomer(customer);

??

Das ist ja "dreifach" gemoppelt. Was hat das für einen Sinn? Also ich für meinen Fall weiß, dass ich nicht die DB wechsle sondern bei z.B. SQL CE oder Firebird bleibe (sqlite kann man getrost vergessen so am Rande)

Naja, wenn direkt das Repository drinnen hängt, dann müssen bei Änderungen des Repositories gegebenenfalls alle ViewModels geändert werden. Gibt es hier einen zusätzlichen Abstraktionslevel, der lediglich Facade o.ä. spielt, dann muss eine etwaige Änderung nur an dieser einen Stelle nachgezogen werden.

Wie gesagt, das hängt stark von den Anforderungen und Gegebenheiten ab und muss von dir jetzt nicht berücksichtigt werden.

Norbert Eder:

welches die Validierung vornimmt (hierzu gibt es in der nächsten Ausgabe 04/09 der Visual Studio One einen langen Artikel von mir mit einem generischen Ansatz),

Das mit dem Validieren ist mir soweit klar... sah das erst jetzt richtig. Ich denke ich poste hier mal ein MVVM + EF sample und dann kannst hackstücken ;-)

Ich bin schon gespannt :)

oh sei nicht zu gespannt sonst ist die Enttäuschung zu groß ;-) so mal was hingefrickelt..., ging recht fix, da ich net weit kam, denn plötzlich kamen mir wieder 1000 Zweifel, aber sieh selbst: Nun ich habe mehrere Fragen: 1.) Ich kann mein Model (SNIPPET) nicht in der eigenen Klasse validieren, so wie du es in der Customer.cs machst, denn ich habe keinen Zugriff auf meine EF Models im Sinn von einer quellcode.cs Datei. Demnach schreibe ich (was anderes fällt mir nicht ein) private Methoden in meine ViewModel Klasse -> ätzend 2.) Das Objekt _snippet erzeuge ich im ViewModel was eigentlich Quark ist, denn das Objekt müsste bei jedem AddSnippet(..) Aufruf in der Methode instanziiert werden, da ich ja nicht auf das alte Objekt zugreifen möchte. Bei optional einzugebenden Properties kann dies ein Problem werden, wenn alte Werte ausgelesen wurden. 3.) Wie reagierst du darauf, wenn in der AddSnippet Methode vom Repository eine Exception auftritt, z.B. die Entität kann nicht gespeichert werden? Klar try/catch drum doch der Benutzer soll eine anständig aussehende und verständliche Fehlernachricht präsentiert bekommen. Vom Repository hin zur View ist es ein weiter weg... Gibt es da eine Binding Lösung? z.B. Fehler tritt auf als bekommt ein bisher textloses label eine Fehlernachricht... 4.) Eines ist sicher eine SNIPPET Instanz benötige ich in dem ViewModel, denn Properties wie Name müssen ja wo eingelesen werden. Doch ich will das Model nur im jeweiligen Repository haben... Das ganze hat soviele Widersprüchlichkeiten, dass es mir graust , ich frage mich gerade ob Microsoft zu sich selbst inkompatibel ist XD public class SnippetViewModel : INotifyPropertyChanged { private SnippetRepository _snippetRepository = new SnippetRepository(); private SNIPPET _snippet = new SNIPPET(); private DelegateCommand saveSnippetCommand; public SnippetViewModel() { } public void Save() { // Anstatt _snippet.IsNameValid... geht ja nicht, da EF-Model nicht zugreifbar ist in dem Sinne... if (!IsNameValid) // Hier müsste man eine Fehlermeldung in der View anzeigen oder man macht es wie John Smith und //zeigt erstmal an, dass alle Eingaben falsch sind ist aber sehr verwirrend else _snippetRepository.AddSnippet(_snippet); } public string Name { get { return _snippet.name; } set { if(_snippet.name != value) { _snippet.name = value; OnPropertyChanged("Name"); } } } public ICommand SaveCommand { get { if (saveSnippetCommand == null) saveSnippetCommand = new DelegateCommand(Save); return saveSnippetCommand; } } private bool IsNameValid { get { return !String.IsNullOrEmpty(_snippet.name); } } protected virtual void OnPropertyChanged(string propertyName) { if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } public event PropertyChangedEventHandler PropertyChanged; } public class SnippetRepository { public void AddSnippet(SNIPPET snippet) { var context = new SnippetManagerEntities(); context.AddToSNIPPET(snippet); context.SaveChanges(); } } ups was ist mit dem Text los, alles an einem Stück?

Also wenn ich mir das so durchlese: http://dotnet-gui.com/forums/p/407/1683.aspx#1683 ist einfach das EF dran Schuld, weil der Designer die Models generiert... So wie es scheint, muss ich also doch für jede Entität ein identische Customer oder Snippet Klasse erstellen. Grrrr... Ist ja doppelt Arbeit vor wirds frickelig wenn etwas geändert wird und synchron sein muss... naja frickeln bin ich ja gewohnt lol Ich habe mir grad ein Beispiel ausgedacht da könnte ich mir das zweite selbige Model ersparen, in dem ich die Business Rules im Repository machen und die Bindung an die Properties in der ViewModel Klasse aufs Repository umleite so: public class SnippetViewModel : INotifyPropertyChanged { private SnippetRepository _snippetRepository = new SnippetRepository(); private DelegateCommand saveSnippetCommand; public SnippetViewModel() { } public void Save() { if (!_snippetRepository.IsNameValid) throw new Exception("Error"); else _snippetRepository.AddSnippet(); } public string Name { get { return _snippetRepository.GetSnippet.name; } set { if (_snippetRepository.GetSnippet.name != value) { _snippetRepository.GetSnippet.name = value; OnPropertyChanged("Name"); } } } } public class SnippetRepository { private SNIPPET _snippet; public void AddSnippet() { var context = new SnippetManagerEntities(); _snippet = new SNIPPET(); context.AddToSNIPPET(_snippet); context.SaveChanges(); } public bool IsNameValid { get { return !String.IsNullOrEmpty(_snippet.name); } } public SNIPPET GetSnippet { get { return _snippet; } } }

scheint doch ne brauchbare Lösung in Sicht zu sein ^^ http://devtalk.dk/CategoryView,category,EntityFramework.aspx muss ich halt mit ner Beta arbeiten... Gibts schon einen ca. Release Termin für .net 4.0 bzw. EF 4.0 ?