Modellierung von Klassen auf der Grundlage von Tabellenentwürfen

Question

Würden Sie den Unterricht normalerweise so gestalten? Eine Klasse = 1 Tisch. Wie sieht es mit Tabellen aus, die einen Fremdschlüssel zu einer anderen Tabelle enthalten?

Angenommen, ich habe Folgendes:

PersonTable
---------------
person_id
name

PersonMapTable
---------------
map_id
type_id (fk)
person_id

PersonTypeTable
-------------------
type_id
description
parent_type_id

AddressTable
-------------------
address_id
address1
address2
city
state
zip

AddressMapTable
-----------
address_map_id
address_id
person_id

Wäre es eine gute Praxis, für jede Tabelle eine Klasse zu erstellen? Wenn ja, was sind die besten Praktiken für das Laden/Speichern solcher Klassen zurück in die Datenbank ohne einen Orm? Ein einfaches Codebeispiel wäre sehr hilfreich

Answer 1

Ich empfehle die Lektüre von Martin Fowlers Muster der Unternehmensanwendungsarchitektur die mehrere Muster für die Zuordnung zwischen Klassen und Tabellen enthält.

Answer 2

Ich glaube nicht, dass ein Objekt pro Tisch unbedingt ein gutes Design ist. Es ist schwer, eine allgemeingültige Regel aufzustellen, aber Objekte können reichhaltiger und feinkörniger sein. Eine Datenbank kann aus Gründen, die nicht auf Objekte zutreffen, denormalisiert werden. In diesem Fall hätten Sie mehr Objekte als Tabellen.

Ihr Fall würde 1:1 und 1:m Beziehungen umfassen:

public class Person
{
    // 1:m
    private List<your.namespace.Map> maps; 
}

public class Map
{
    // 1:1
    private your.namespace.Type;
}

Answer 3

In den meisten Fällen neige ich dazu, Tabellen auf Entitäten abzubilden, aber das ist keine feste Regel. Manchmal gibt es Fälle, in denen das Repository für eine bestimmte Entität besser geeignet ist, sich mit den allgemeinen Belangen rund um eine bestimmte Entität zu befassen, was bedeutet, dass es sich infolgedessen mit anderen Tabellen befasst, ohne dass diese Tabellen speziell als Entitäten existieren müssen.

Was ich niemals tun (außer in sehr spezifischen geplanten Fällen, in denen die abhängigen Daten IMMER mit der Entität abgerufen werden müssen), ist das Festlegen einer Entität oder einer Sammlung von Entitäten als Eigenschaft einer anderen Entität. Stattdessen wird diese Entität entweder über ihre ID auffindbar sein, die entweder eine Eigenschaft der übergeordneten Entität ist oder über das zugehörige Repository in Bezug auf die übergeordnete Entität auffindbar sein wird.

In Fällen, in denen ich die untergeordnete Entität oder Entitäten einer anderen Entität zusammenfassen muss, verwende ich eine "info"-Helferklasse, um alle erforderlichen Daten zusammenzufassen. Wenn ich zum Beispiel eine Entitätsklasse habe Widget und es hat eine Sammlung von Kind Part Objekte, dann würde ich eine WidgetInfo Klasse, die die Widget Instanz als eine Eigenschaft und eine Sammlung von Part Objekte als die andere Eigenschaft.

Auf diese Weise bleiben alle Entitätsklassen so leichtgewichtig wie möglich und gehen nie davon aus, dass abhängige Daten geladen werden müssen. Außerdem wird das Repository-Modell sauber gehalten, ohne dass Sie in ein chaotisches ORM-Territorium gezwungen werden, was im Allgemeinen der Fall ist, wenn Sie Kindobjektsammlungen auf einer Entitätsklasse erstellen. Wenn Sie das tun ohne ORM, dann enden Sie mit dem chaotischen Problem, wann die Kinder geladen werden oder nicht, und wann angenommen werden soll, dass die Kinder geladen wurden oder nicht.

Answer 4

Ich würde nicht sagen, dass ich immer eine Klasse pro Tabelle habe, vor allem, wenn man viele Beziehungen hat. Basierend auf Ihrer Tabelle oben würde ich 2 Klassen haben... Ich bin mir nicht sicher, warum Sie sowohl eine id als auch eine person_type_id haben, für mich wären sie das Gleiche, aber hier sind die Klassen.

Person
{
   public int Id { get; set; }

   public string Name { get; set; }

   public List<PersonType> { get; set; }
}

PersonType
{
   // I would discourage from using Type as property name as it is a keyword...
   public string [Type] { get; set; }
}

Answer 5

Sofern es sich bei Ihren Benutzern nicht um Dateneingabebeamte handelt, ist es im Allgemeinen besser, Klassen anhand von Anwendungsfällen/Benutzergeschichten zu entwerfen. Selbst wenn die Datenbank bereits existiert.

Der Grund? Es ist zu leicht, dass die Benutzer davon ausgehen, dass es ihre Aufgabe ist, die Software zu bedienen, anstatt zu erwarten, dass die Software ihnen hilft, ihre Arbeit zu erledigen.

Es liegt auf der Hand, dass sie sich an einem bestimmten Punkt überschneiden müssen. Ich stimme zu, dass Fowlers Buch ein guter Anfang ist. Aber ich denke, er wird diese Sichtweise noch verstärken.

Wenn Sie eine Modellierungsperspektive suchen, die Ihnen hilft, sowohl die Klassen als auch die Datenbank richtig zu modellieren, sollten Sie die Objektrollenmodellierung in Betracht ziehen.