IDataErrorInfo

[Flo_Plus]

Hallo,

ist es ratsam bei MVVM und EF als ORM IDataErrorInfo direkt in die EF-Klasse einzubauen?
Sie werden quasi mit Public Partial Class SOWIESO erweitert wie in diesen Beispiel:
http://blogs.msdn.com/b/wpfsdk/archi...on-in-3-5.aspx

Oder macht man das besser anders?

MfG, Flo

[gfoidl]

Hallo Flo_Plus,

ja und idealerweise werden die EF-Klassen selbst erstellt (als POCOs).
Das ViewModel, welches ebenfalls IDataErrorInfo implementiert, reicht dann die Prüfung an die Modell-Klasse weiter.

Ev. interessiert dich somit auch ValidationRules und Attribute zur Validierung.


mfG Gü

[Flo_Plus]

Hallo,

danke für die Antwort! Ich kann aber auch ohne Probleme die Klasse die von EF erzeugt wurde erweitern, oder gibt es irgendwelche Einschränkungen dass ich wie du schreibst mit POCO selbst Klassen erstellen soll?

Würde Sie lieber erweitern!

Gruß Flo

[gfoidl]

Hallo Flo_Plus,

oder gibt es irgendwelche Einschränkungen dass ich wie du schreibst mit POCO selbst Klassen erstellen soll?

Das "idealerweise" in der vorigen Antwort war ein wenig zu ideal gewählt. ;-)
Zum Einen kommt es darauf wie die Anwendung entwickelt werden soll. Wird mit einem leeren Blatt begonnen, so kann Model-First entwickelt werden und dort ist es vorteilhaft POCOs zu verwenden.
Existiert die Datenbank hingegen schon, können auch die EF-generierten-Klassen verwendet werden (und wegen partial auch erweitert werden). Ebenfalls wäre es möglich eigene (POCO-) Klassen mit dem EF zu verwenden (ab EF 4.1. sogar recht einfach) und hier kann schon zu Beginn auf IDataErrorInfo gesetzt werden - das Mapping auf die Datenbank ist nicht sehr aufwändig und bietet zusätzlich den Vorteil von mehr Freiheit.

Zum Anderen haben die POCOs keine Abhängigkeit zu einer Technologie (hier zum EF) und somit bietet das Vorteile wenn diese Klassen über verschiedenste Schichten der Anwendung gesendet werden sollen. Dies ist erst recht vorteilhaft wenn WCF ins Spiel kommt.
Aber auch ohne WCF ist es mMn vorteilhaft. Beispielsweise muss die UI-Assembly somit das EF nicht referenzieren, da eben keine Abhängigkeit dazu besteht, und das ist im Sinne der Schichtentrennung schon mal nicht schlecht.


mfG Gü

[Flo_Plus]

Hallo,

super, dankeschön! Eine Frage zum vollen Verständnis gäbe es noch meinerseits: Ich lese immer wieder im ViewModel wird bereits Validiert, und das ViewModel gibt das dann weiter an das Model, welches nochmal Validiert?? Ist das so richtig, bzw. wie programmiert man sowas? Reicht es nicht nur im Model zu Validieren? Vielleicht hättest da noch einen Tipp für mich!

Danke!

Gruß, Flo

[gfoidl]

Hallo Flo_Plus,

das ViewModel reicht die Validierung einfach an das Model weiter, wenn das Model schon IDataErrorInfo implementiert.
Es reicht im Model zu validieren*, aber damit die View ev. Validierungsfehler mitbekommt, muss dieses ja die Information vom ViewModel bekommen.

* das Model ist der "Kern" dieser Sache und weiß wann es in einem gültigen od. ungültigen Zustand ist. Das ViewModel bereitet das Model nur für die View auf und sollte hier keine Entscheidungen über den Zustand des Model treffen (-> daher Validierung im Model).

Einfaches Beispiel: Eine Customer-Model-Klasse die IDataErrorInfo implementiert. Das ViewModel schaut dann grob so aus:
[highlight=c#]
public class CustomerViewModel : IDataErrorInfo
{
private readonly Customer _customer;

public CustomerViewModel(Customer customer)
{
_customer = customer;
}

public string Name
{
get { return _customer.Name; }
set
{
if (_customer.Name == value) return;

_customer.Name = value;
this.OnPropertyChanged(() => this.Name);
}
}
//---------------------------------------------------------------------
public string Email
{
get { return _customer.Email; }
set
{
if (_customer.Email == value) return;

_customer.Email = value;
this.OnPropertyChanged(() => this.Email);
}
}

#region IDataErrorInfo Members
public string Error
{
get { return _customer.Error; }
}

public string this[string columnName]
{
get { return _customer[columnName]; }
}
}
}
[/highlight]
Das ganze Beispiel findest du im obigen Link.
Auch in Das Model-View-ViewModel (MVVM) Entwurfsmuster für WPF ist bzgl. Validierung ein praktisches Beispiel zu finden.


mfG Gü

[Flo_Plus]

Soweit ist das ein schönes Beispiel. Und wieso hat das ModelView dann die IDataErrorInfo implementiert, wenn dies das Model macht?

#region IDataErrorInfo Members       
public string Error        
{            
get { return _customer.Error; }        }         
public string this[string columnName]        
{            
get { return _customer[columnName]; }        
}

Diesen Bereich verstehe ich noch nicht ganz, sorry.. :-(

MfG

[Flo_Plus]

Sorry!! Natürlich versteh ichs. Dummheit.. Muss ja implementiert sein, die IDataErrorInfo-Schnittstelle, da sonst auch nichts ankommt.

Sorry, hab ich nicht gut genug geschaut. Vielen Dank für die tolle Hilfe von dir!

Schönen Tag noch!

[Ralf Jansen]

* das Model ist der "Kern" dieser Sache und weiß wann es in einem gültigen od. ungültigen Zustand ist. Das ViewModel bereitet das Model nur für die View auf und sollte hier keine Entscheidungen über den Zustand des Model treffen (-> daher Validierung im Model).

In die andere Richtung passt das aber doch vermutlich auch oder? Das ViewModel trifft Entscheidung über den momentanen Eingabezustand des Views und das potenziell über die IDataErrorInfo Schnittstelle. Darum wird es gegebenenfalls etwas anderes validieren als das Model (der View ist valide das Model aber noch nicht) und nicht immer nur einfach weiterreichen oder überhaupt weiterreichen.

Oder verhält es sich in WPF anders als im allgemeinem Pattern?

[gfoidl]

Hallo Ralf,

der View ist valide das Model aber noch nicht

Die View hat in WPF keinen Zustand (auf Daten bezogen), sondern höchstens das ViewModel (VM) hat einen Zustand. Wenn nun das VM zur Aufbereitung des Models für die View dient, so hat das VM auch den Zustand vom Model wiederzugegeben und somit muss die Prüfung durchgereicht werden. Würde das VM z.B. den Zustand der UI-Eingaben als gültig empfinden und das Model trotzdem in einem ungültigen Zustand sein, passt das Ganze nicht mehr zusammen.

verhält es sich in WPF anders als im allgemeinem Pattern?

Das MVVM-Muster ist sozusagen eine Adaption des Presentation-Model-Musters für WPF. Insofern sind die Grundprinzipien auch gleich.

mfG Gü

[Ralf Jansen]

Die View hat in WPF keinen Zustand (auf Daten bezogen)

Doch. Ich nenne es ViewModel. Eine reine Frage der Sichtweise

Würde das VM z.B. den Zustand der UI-Eingaben als gültig empfinden und das Model trotzdem in einem ungültigen Zustand sein, passt das Ganze nicht mehr zusammen.

Das wäre für mich ein gültiger Case wenn ich eine einzelne Modelklasse in meiner UI als z.B. einen Wizard darstelle. Ein Step (ein ViewModel) mag konsistent sein ohne das das darunterliegende Model bereits valide ist. Erst der über den ViewModels liegende Workflow sollte letztlich(absolut) ein konsistentes Model erzwingen. Gibt das WPF im Standardverhalten erst mal nicht her und erwartet je Workflow genau ein MVVM Konstrukt?