verwendetes Datenbanksystem: IBM DB2 - es geht aber um alle DBMS allgemein
Hallo zusammen,
ich arbeite mich momentan in das ORM "Dapper" ein.
Wir haben hier u.a. ne IBM DB2 und da gibts Tabellen mit 70 und mehr Spalten.
Da habe ich ne kurze Frage zur besten Design-Herangehensweise.
Ist es so, dass die Models immer komplette Tabellen abbilden, oder kann man auch Models erstellen, die z.B. nur einige Spalten aus SQL-Selektionen beinhalten.
Oder man hat Views oder Abfragen mit mehreren Joins über verschiedene Tabellen und möchte die Abfrageergebnisse in einem Model darstellen.
Das macht m.E. nur bei Anwendungen Sinn, die ausschließlich lesend auf die DB zugreifen, sollte aber da funktionieren.
Praktiziert ihr das auch, oder modelt ihr immer konsequent und nachhaltig alle Tabellen in eure Datenmodelle (POCOs)?
Welche Vorteile/Nachteile seht ihr an dieser Vorgehensweise?
LG
Eigentlich solltest dein POCO, was die Daten in der Tabelle abbildet i.d.R. alle Spalten als Properties haben.
Wie diese später dann angezeigt/verwendet werden solltest du am besten über MVC/MVP durch die View Models festlegen.
Es kann aber auch Fälle geben wo es aus Performance Sicht sinnvoll ist ein kompaktes POCO zum laden von einem Teil der Spalten aus einer Tabelle.
Hängt dann aber von der Situation ab.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Ist es so, dass die Models immer komplette Tabellen abbilden, oder kann man auch Models erstellen, die z.B. nur einige Spalten aus SQL-Selektionen beinhalten.
Weit verbreiteter Ansatz (und manche nennen es Best Practise):
Im Endeffekt also nur zwei verschiedene Klassen, die man Dapper beim Query übergibt.
So machen wir das in unseren Projekten auch.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Ich würde auch die ganze Tabelle als Klasse abbilden, schon allein um es erst Mal zu haben. Ich persönlich schaue auch lieber in der POCO-Klasse nach, wenn ich etwas suche, da hab ich Referenzen und Kommentare, das habe ich in der Datenbank nicht.
Danach kann man immer noch kompaktere Varianten davon bauen, sofern das tatsächlich einen Vorteil (z.B. im Bezug auf die Performance) bringt.
Ich sehe allerdings auch keinen Nachteil darin, nur eine große Klasse zu nutzen. Ich finde eine große Tabelle viel umständlicher in der Handhabung als eine große Klasse, wobei in diesem Fall das ORM die meiste Arbeit übernimmt.
Soweit ich mich erinnere, hat EF Core ein Feature mit gebracht, womit man eine POCO-Klasse aufteilen kann. Damit kann man einstellen, dass eine Klasse eine Referenz auf eine zweite Klasse nutzen kann und die Properties dieser zweiten Klasse können dann in die selbe Tabelle gemappt werden.
Ob es etwas vergleichbares auch für Dapper gibt, weiß ich nicht, für EF Core ist es hier erklärt.
Man kann sicher hervorragend darüber streiten, ob das so gut ist, aber ich könnte mir vorstellen, dass es bei Werten, die sich zwischen Tabellen widerholen oder die inhaltlich gut in eine eigene Klasse passen würden (z.B. Adressen), durchaus sinnvoll ist.
Wenn Performance kein Knackpunkt ist, würde ich aber sowieso EF Core nutzen, das nimmt so unfassbar viel Arbeit ab.
Ich sehe allerdings auch keinen Nachteil darin, nur eine große Klasse zu nutzen. Ich finde eine große Tabelle viel umständlicher in der Handhabung als eine große Klasse, wobei in diesem Fall das ORM die meiste Arbeit übernimmt.
Man soll immer nur die Spalten laden, die man auch wirklich braucht. u.a. deswegen gilt auch SELECT * als Bad Practise.
Der Performance-Vorteil ist aus prozentualer Sicht immens.
würde ich aber sowieso EF Core nutzen, das nimmt so unfassbar viel Arbeit ab.
Ich werfe mal in den Raum: wenn man EF nicht wirklich nutzen muss, würde ich EF mit dem aktuellen Stand überhaupt nicht nutzen.
Absolute Empfehlung von meiner Seite: Dapper mit Dapper.Contrib.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code