Entity Framework aktuelle Datentechnologie ?

Hallo Leute,

ich bin ganz neu im Gebiet Entity Framework was neu mit .NET 4 und VS2010 gekommen ist.
Nun wollte ich fragen, sind die "alten" Technologien wie ADO.NET nicht mehr präsent bzw. werden zukünftig nur Objektmodelle verwendet?

Wenn z.B. eine 3 Tier Webanwendung entwickelt wird, Presentation, Business- und Data Layer, wie wird das neue Modell im DL implementiert?

Mit den ADO.NET habe ich je nach Implementierung den SqlDataReader, SqlCommand verwendet die in Funktionen wie GetCusters() gekapselt waren. Wie sieht es mit dem neuen Modell aus, habt ihr ein Beispiel für mich.

Das kommt ganz auf das Design der Lösung an.

Viele setzen auch heute noch ADO.NET ein, da OR-Mapper nicht ganz so performant sind.

Beispiele für EF findest Du hier.

Ich stelle mich jetzt mal blöd, warum sind OR-Mapper nicht performant?
Warum werden sie dann soviel benützt?

Ich stelle mich jetzt mal blöd, warum sind OR-Mapper nicht performant?

Kurz gesagt: Weil man nicht mehr die Kontrolle über das SQL Statement hat.

Wobei O/R Mapper wie Hibernate schon sehr sehr gute Statements zusammenbauen.

Wegen 'falschen' SQL-Statements sind OR-Mapper langsame, die machen ja auch nicht mehr als ein Select, Cross Joins können wahrscheinlich eh die wenigstens und kommen eh keine kompliziereten SQL-Statements raus.
Oder bin ich da jetzt komplett falsch?

Für die seltenen Fälle in denen aktuelle O/R Mapper wie zB NHibernate schlechte SQL-Statements bauen, gibts es immer noch die Möglichkeit direkt einzugreifen...

Persönlich halte ich das EF nicht für "aktuelle" Datentechnologie, da es für einen O/R Mapper einfach noch nicht ausgereift genug ist.
Auch schaue ich jetzt verstärkt darauf ob ich in neuen (oder alten) Projekten nicht eine NoSQL Datenbank zum Einsatz bringen kann um mich von der Geisel Tabellen+Spalten zu befreien. 😉

Hmm.. ich dachte die Communication zwischen datenbank und OR-Mapper ist der geringere Flaschenhals!? Ich sah die Schwächen eher beim transfomieren der Daten von einer DataTable (o.ä) zu den DTOs (oder BOs)
Zumindest versuche ich bei meinem OR-Mapper genau dabei so schnell wie möglich zu halten, auf die Dankbank wäre ich nicht gekommen.

ich dachte die Communication zwischen datenbank und OR-Mapper ist der geringere Flaschenhals!?

Da die Datenbank normalerweise nicht auf dem gleichen Rechner liegt auf dem der OR-Mapper "läuft", geht jeder DB-Zugriff übers Netzwerk.
Und wenn etwas übers Netzwerk geht, dann ist das normalerweise automatisch der Flaschenhals.

ok dass das Netzwerk der langsamste Teil der Geschichte ist, ist klar, wenn auch noch nicht so angedacht, aber klar.
Bei meinem liegt der OR-Mapper selbst auf dem gleichen Rechner wie die Datenbank (hinter einem WCF-Service) also habe ich mir von daher keine Gedanken gemacht. (bzw. kann man sich das aussuchen ob man einen Service benutzen will oder die {Connection} local liegt)

Den WCF-service kann man ein 'bisschen' pimpen aber Netzwerk ist Netzwerk.

Ich habe mein Hauptaugenmerk darauf gelegt, keine Reflection zu verwenden, da die bei uns in der Firma fast am meisten Zeit kostet, bzw. man da viel rausholen kann. Natürlich wenn der Rest mies programmiert ist, hilft das auch nicht, aber ich glaube mein Teil sieht gut aus, ist aber auch noch recht schlank, kann mom. nur einzelne DTOs holen oder Listen von DTOs
IdentityMap, speichern und Transaction kommen nach dem schreiben der Tests für den bereits fertigen Code.

Oder bin ich da jetzt komplett falsch?

Eigentlich nicht. Wie gesagt, z.B. Hibernate baut sehr saubere Statements. Wenn es aber in dem Bereich des Reportings geht und man Datenquellen für den Report zusammenbaut, versagen die O/R Mapper meist alle. Gut, da kommt es natürlich drauf an was man macht. Aber bei CTEs, PIVOTs und Konsorten hört es halt auf 😃

Mir ist der Begriff Reporting nicht geläufig
Bin ja Zimmerergeselle, könntest Du in 2 Sätzen erklären was das bedeutet.
Wahrscheinlich hab ich es schon gemacht nur weis ich nicht wie es heist.

Naja, Reports müssten dir doch was sagen, oder?

Irgendwelche Berichte, wie Statistiken über bestimmte Daten. Oder z.B. auch Rechnungen. Alles was man halt auf Papier bringen kann.

Da gibt es halt einfache Reports (einfache Listen (Namenslisten)), oder halt extrem komplexe Reports (z.B. Dashboards). Die Datenquelle für solche Reports sind meist DataTables, bzw. DataSets. Je nachdem wie komplex nun so ein Report ist, kann man die Daten auch per O/R Mapper besorgen. Bei wirklich komplexeren, ist halt der Zug für O/R Mapper abgefahren.

Ah, Berichte! Ok, da hätte ich auch selbst drauf kommen können 😃

Ich habe mir für meinen in diese Richtung noch nichts überlegt, aber als ersten Ansatz würde ich in der Datenbank eine View (Abfrage) erstellen und die dann 1:1 mappen. Denke es würde auch von der Geschwindigkeit besser sein wenn das Zusammensammeln die Datenbank übernimmt. Vorallem so wie es bei unserer Anwendung in der Firma ist, kann der Client mit 'nicht BusinessObjects' garnicht umgehen, da hängen soviele Sachen drauf, Validierung, Highlighting und das ganze Zeug das die Formulare garnicht wüssten was sie mit einer DataTable machen sollen. ... Ich glaube unserer Server hat garkeine Möglichkeit DataTables zu liefern.

Sollte man nicht eher versuchen, nur eine Sorte von DatenContainer (BO oder Dt) zu verwenden? Mischungen erfordern ja auch eine Mischung in der Art der Programmierung, bzw. das Konzept wird 'unnötig' aufgeweicht wenn einerseits nur Hardtypisierte Dinge herumschwirren und dann kommt doch ein DataTable?

Hallo,

Sollte man nicht eher versuchen, nur eine Sorte von DatenContainer (BO oder Dt) zu verwenden? Mischungen erfordern ja auch eine Mischung in der Art der Programmierung, bzw. das Konzept wird 'unnötig' aufgeweicht wenn einerseits nur Hardtypisierte Dinge herumschwirren und dann kommt doch ein DataTable?

Hängt IMHO stark davon ab, was man machen will. Will der Kunde zusätzliche Spalten auf ein Report haben, scheiden BOs sofort aus. Du willst ja nicht für jeden Kunden eine extra Version bauen. Sind die Reports immer fest (was meist höchst unwahrscheinlich ist), kann man die Daten natürlich auch über BOs zusammenstellen.

Es ist immer eine Frage des: Was will ich genau machen?

Wir haben (in der Firma) für jeden Kunden ein eigenes DomainModel.
das einzige was fix ist, ist der Save-Button.
Ist zwar eine eigenartige Struktur die man beim ersten Mal nicht ganz versteht aber es geht 😉

Was will ich haben?
ein Customizable Standard-DomainModel
auf Deutsch:
eine Eier legende WollmilchSau

Die Frage hinsichtlich der Geschwindigkeit ist aber schon längstens beantwortet.

Danke

Vielleicht hilft euch das Query Object Pattern an der Stelle weiter.

Hmm, bin mir jetzt nicht ganz sicher ob ich es richtig verstanden habe, aber es sieht mir so aus, als müsste ich in den Forms (oder an einer geeigneteren Stelle) an meinem Standardmodel 'herumfragen'.
Nein, ich glaub da ist mir mein erweiterbares Standard-DomainModel lieber.

Mein StandardModel:

public partial class BusinessObjectName
{
}

bei einem KundenModel wird ein neues Projekt erstellt und die 'echte' cs verlinkt (!) und eine zusätzlich Datei erstellt wo man die Kundenfelder dazulinken kann.
Ist auf den Ersten Blick nicht ganz durchsichtig, aber so kann man eigentlich beliebig erweitern.

...und eine zusätzlich Datei erstellt wo man die Kundenfelder dazulinken kann.

Bei sowas hilft auch ein EAV Modell weiter. Wobei das Reporting dann etwas eklig wird.

Hmm, bin mir jetzt nicht ganz sicher ob ich es richtig verstanden habe, aber es sieht mir so aus, als müsste ich in den Forms (oder an einer geeigneteren Stelle) an meinem Standardmodel 'herumfragen'.

Unser Framework erlaubt es über Query Objects, das jeder Benutzer sich Sichten auf Daten bauen kann, wie er Sie gerne hätten. Es gibt bei Auslieferung also nur ein Set an Standartsichten. Auch bei uns hat jeder Kunde x Zusatzfelder pro BO. Die Query Objects laufen auf einer Metadaten-Basis. D.h., das jede Klasse mit ihren Properties nochmal 1:1 in der DB abgebildet ist. Somit können sogar zur Laufzeit BOs abgeändert werden, ohne den Code anzufassen. Diese Sichten können dann ebenfalls 1:1 auf Reports abgebildet werden. Da man allerdings nicht mehr weiß, was für Daten ein Query zurückliefert, hängt dieser Part an einer simplen DataTable (wobei wir noch mit Proxy-Objekten arbeiten usw...).

Also kurz gesagt: Man "sucht" nicht die BOs selber, sondern nur deren Metadaten. Aus dem Metadatenmodell, wird schlussendlich das SQL generiert.

Wenn ich Deinen Link richtig verstanden habe, verwenden wir sowas ähnliches.
Ich nenne es mal 'Frei definierbare Zusatzdatenfelder'.
Kunde klickt auf Hinzufügen -> Geburtstag vom Type DateTime und Magic:
In der Adressenverwaltung entsteht bei jeder Adresse ein neues Feld 'Geburtstag'
Intern ist die 'Spalte' Geburtstag in einer Tabelle und in einer anderen Tabelle ist ein Datensatz pro Adresse mit einem Key auf 'Geburtstag' aus der anderen Tabelle (und dem Datum)
Dieses Pattern versuche ich zu vermeiden. Hab jetzt zwar keine guten Argumente dagegen, aber es gefällt mir einfach nicht.
Auch wenn es keine schöne Lösung ist, gefällt mir das mit den partial classes und linken besser, ich finde es irgendwie verständlicher.

Euer System klingt nach Linq to SQL?
Ok, vielleicht muss ich noch erwähnen das bei mir privat ich nicht vorhabe dass der Kunde selbst was programmiert. Das bleibt alles in meiner Hand. Ich möchte aber so flexibel wie möglich sein um spezielle Kundenwünsche mit so wenig Aufwand wie möglich zu machen und dabei updatebar bleibe.
Zurück zum Thema. Was ist euer OR-Mapper?
"Aus dem Metadatenmodell, wird schlussendlich das SQL generiert."
Zur Laufzeit?

Auch wenn es keine schöne Lösung ist, gefällt mir das mit den partial classes und linken besser, ich finde es irgendwie verständlicher.

Verständlicher mag es vielleicht ja sein. Aber was machst du bei > 10 Kunden. Hat jeder Kunde eine eigene komplette Solution? Und was wenn sich nur eine Kernkomponente ändert? Müssen dann x Updates für x Kunden bereitgestellt werden? Wenn ich ehrlich bin, flexibel finde ich das so nicht. Aber wenn ihr damit so zurecht kommt, ist es ja in Ordnung.

Euer System klingt nach Linq to SQL?

Gott bewahre 😃 Linq to SQL ist ein netter Ansatz, hat aber IMHO im Bereich Enterprise Solutions nichts verloren.

Was ist euer OR-Mapper?

Tja, das ist nicht ganz so einfach...
Historisch bedingt, gibt es an sich kein O/R Mapper. Es liegt eine eigene kleine Implementation vor. Das liegt hauptsächlich daran, das unser System extrem flexibel ist und sich innerhalb von kurzer Zeit an Kundenwünschen anpassen lässt. Mag jetzt veraltet klingen - ist es vielleicht sogar - aber es funktioniert. Und das sogar sehr gut. Ein weiterer Punkt ist auch, das sich halt das Datenmodell von Kunde zu Kunde ändern kann. Da kommt kaum ein O/R Mapper mit. NHibernate kann das zwar mit Dynamic Mappings erreichen, da war es aber zu spät 😃

Dazu kannst du dir mal, wenn du den Zugriff darauf hast, mal das MS CRM anschauen.

Für kleine Projekte nehme ich (Fluent) NHibernate. Das Ding ist sehr mächtig und ist dem Entity Framework von MS noch weit vorraus.

Zur Laufzeit?

Ja, zur Laufzeit. Ein Parser geht einfach über das Query Objektmodell und bastelt daraus das SQL.