Laden...

Tabellen immer konsequent in POCO abbilden?

Erstellt von NEUMee vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.125 Views
N
NEUMee Themenstarter:in
24 Beiträge seit 2011
vor 4 Jahren
Tabellen immer konsequent in POCO abbilden?

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

T
2.219 Beiträge seit 2008
vor 4 Jahren

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.

16.807 Beiträge seit 2008
vor 4 Jahren

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):

  • Entitäten bilden ganze Tabellen ab
  • Projektionen bilden nur einzelne Spalten ab

Im Endeffekt also nur zwei verschiedene Klassen, die man Dapper beim Query übergibt.
So machen wir das in unseren Projekten auch.

2.078 Beiträge seit 2012
vor 4 Jahren

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.

16.807 Beiträge seit 2008
vor 4 Jahren

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.

  • es hat verdammt viel Magic Code
  • das generierte Linq ist teilweise einfach nur schlecht und man muss doch wieder von Hand ran
  • das Debugging ist grauenhaft
  • oft nicht-nachvollziehbare Queries
  • keine wirklich gute Performance
  • viele Projekte hängen immer noch auf EF 6, weil es keinen wirklichen Migrationspfad gibt
  • die EF Migrations haben bis heute nicht das Niveau eines FluentMigrator o.ä.
  • Immer noch kein Support von Many to Many Support ohne join-Entity (versprochen war es schon zu 2.0; kommt mit Glück dann mit 3.0)

Absolute Empfehlung von meiner Seite: Dapper mit Dapper.Contrib.