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.
