Entity Framework-Klassen und Darstellung in der View

Darüber denke ich auch sehr oft nach...

So bin ich sonst immer vorgegangen:
Model (POCO-Klassen) erstellt und INotifyPropetyChanged implementiert
Wenn es berechnete Properties (z.B. Menge * Einzelpreis = Gesamtpreis) sind, die nicht zur Datenbank gehören, benutze ich das [NotMapped]-Attribute.
Dieses Model benutze ich dann mit dem EntityFramework als Entität
Bei mir sind die Views meist Fenster, dafür erstelle ich separate ViewModels. Diese ViewModels besitzen dann aber meist ein Objekt mit einer Instanz einer Entität, die ich jetzt ebenfalls an die View binden kann, oft auch eine ObservableCollection einer Entität.

Damit bin ich bis jetzt immer gut zurecht gekommen.
Man liest aber immer wieder, dass das "nicht richtig" oder "schlecht" sei...

Darum überlege ich mir zur Zeit dieses Konstrukt:

Die Entitäten (wieder POCO-Klassen) besitzen wirklich nur die Properties, die sie wirklich abspeichern wollen
Zu jeder Entität gibt es eine abstrakte Basis-ViewModel-Klasse, die alle Properties der Entität 1:1 nachbilden, zusätzlich aber noch INotifyPropertyChanged implementieren
Diese Basisklassen würde ich mir über eine T4-Vorlage automatisch erzeugen lassen...
Dann gibt es zu jeder Entität mindestens ein ViewModel, welches von der Basisklasse erbt, zusätzlich aber noch weitere Properties zur Verfügung stellt (z.B. Menge * Einzelpreis = Gesamtpreis)

Dann gibt es wieder für jedes Fenster ein ViewModel, welches mindestens eine Instanz der Entity-ViewModels besitzt. Also dasselbe wie oben, nur dass nicht direkt auf die Models gebunden wird, sondern noch die VM-Klasse dazwischen liegt.

Wäre das vielleicht ein "richtigerer" weg? ;-)

Danke erstmal für eure Antworten.

Umfeld wäre C# + WPF + MVVM + EF6 + MSSQL 2014

Ich denke aber dass sich das Asp.Net Beispiel recht gut übertragen lässt.

Mein vorgehen wäre dann wahrscheinlich wie schon im ersten Post angedeutet:

DAL gibt Entitäten zurück und im BL erzeuge ich mir daraus meine Objekte für die View und reiche diese entsprechend bis ins ViewModel.

Aber wo ist der große vorteil die Objekte von ein paar Properties zu befreien und wie oft kommt es vor, dass eine Entität Daten enthält, die die View nicht braucht?

Mein vorgehen war bisher EF6 CodeFirst und ich habe mir hier überlegt, was ich für Daten brauche. Rausfallen für die View, würde zum Beispiel die entsprechende ID, aber rechtfertigt die ID den Mehraufwand? Kann sich hier vielleicht jemand ein Praxis bezogenes Beispiel eines bestimmten Objektes (z.B. wie oben beschrieben PersonEntität wird zu Person --> was kann wegfallen/kommt hinzu) in diesem Umfeld aus den Fingern "saugen"?

Alles klar, das ergibt auf jeden Fall Sinn. Automapper hätte ich auch nicht im DAL gehabt, sondern im BL. Ich würde im BL dann die Entitäten aus der Datenbank über den DAL bekommen und hier ein Mapping für die View vornehmen.

Allerdings scheint laut den Links Automapper nicht die beste Variante für EF zu sein. Bzw. erfordert es sehr viel "undurchschaubaren" Code. Darf ich Fragen wie du/ihr dies in einer WPF + MVVM + EF Anwendung realisiert?

Der Artikel ist zwar etwas älter, aber dazu folgende Frage. (Kann gerne abgeleitet werden, sofern sinnvoll).

Nehmen wir folgendes Repository...

C#-Code:

public interface IRepository<TEntity>     {         TEntity FindById(int id);         ....     }

Möchte ich nun irgendwo nur bestimmte Daten dieser Entität nutzen, kann ich diese entsprechend mappen. Dies ändert aber nichts an der Abfrage die gegen die Datenbank läuft.

Abt sagte, dass sie vollständig auf IQueryable setzen. Folglich sähe das Repository so aus ?:

C#-Code:

public interface IRepository<TEntity>     {         IQueryable<TEntity> FindById(int id);         ....     }

Ist es nun der sauberere Weg, dies so zu tun und z.B. im BL entsprechend die gewünschte Projection vorzunehmen?

Oder nutzt ihr, da Tools wie AutoMapper (mittlerweile) ja auch mit IQueryable entsprechend umgehen können diese im DAL, sodass ein Repository z.B. so aussieht und kein IQueryable verfügbar gemacht wird:

C#-Code:

public interface IRepository<TEntity>     {         TModel FindById<TModel>(int id);         ....     }

Hmmm, die Verwendung von OData ist an der Stelle doch aber nur bedingt relevant. Die eigentliche Frage ist ja, wann und wo ich eine Entität des DALs in eine entsprechend DTO/ViewModel wandle?

Der OData Fall spräche allerdings für das zweite Beispiel, also das mein Repository immer IQueryable liefert und (um bei ASP.NET zu bleiben) der Controller die Projektion durchführt, welche selbst ja auch wieder ein IQueryable ist.