OOP/Repository-Muster: zu viele Objekte für verschiedene Teilmengen des Datenbankzugriffs erstellen?

Question

Ich portiere alten VB6-Code (ja ja, VB6 ...) zu C#. Ich reformiere Code, um objektorientierter zu sein, und unter anderem implementiere ich Repository-Klassen, um auf die Datenbank zuzugreifen.

Nun geben diese Repository-Klassen Objekte zurück, keine Datasets. Aber ich finde, dass ich manchmal nur eine Teilmenge der Informationen zurückgebe, die ein Objekt enthalten könnte. Beispiel: Ich kann eine vollständige Liste von Dokumenten mit Namen, Dateipfad, Ordner, Ersteller usw. erhalten - oder ich kann Suchergebnisse für Dokumente erhalten, die nur Namen und Ordner enthalten.

Was ist die beste Vorgehensweise für diese Teilmengen? Sollte ich benutzerdefinierte Objekte für diese Datenbankaufrufe erstellen, die nur die Teilmenge der Daten enthalten? Soll ich die vollständigen Objekte mit nur einigen ihrer Felder zurückgeben? Oder sollte ich nur Datensätze zurückgeben?

Answer 1

Idealerweise sollte alles so zentralisiert wie möglich sein. Dies könnte durch Erstellen eines Abfrageobjekts für jede Teilmenge erfolgen. Ich denke, dass Sie beide Wege mit zurückkehrenden Objekten mit einigen Feldern, die ausgefüllt werden oder Null, abhängig sein können, abhängig davon, ob Ihre Datenbank Nullen für diese spezifischen Felder zulässt.

So zentralisieren Sie Ihre Regeln und Logik mit Ihren Repository-Klassen, so dass jedes Objekt basierend auf diesen Regeln und Logik konsistent zurückgegeben wird.

Erstellen Sie ein Unterzeichnungsschema für Ihre Objekte, damit sie nicht zu komplex werden. Ich denke, was notwendig ist, ist eine Entität pro Objekt, die für das Repository berücksichtigt werden soll. Auch das Erstellen von benutzerdefinierten Objekten oder DTOs könnte unnötigen Code und unnötige Komplexität erzeugen. Aus Gründen der Integrität halten Sie Ihre Objekte mit einigen Feldern gefüllt und andere, die nicht innerhalb dieser Untermenge benötigt werden, auf diese Weise, wenn diese Informationen später abgefragt werden, können Informationen zurückgemeldet werden, dass der Wert für eine bestimmte Entität nicht existiert.

Hier ist ein kurzes Beispiel, versuchen Sie mit POCO-Klassen mit dem Entity-Framework.

public interface IRepository<TEntity, in TKey> where TEntity : class 
{ 
    TEntity Get(TKey id); 
} 

public class SomeRepo1 : IRepository 
{ 
    private readonly FileDbContext someDbContext; 

    public FileRepository(FileDbContext dbContext) 
    { 
     someDbContext = dbContext; 
    } 

    public File Get(string id) 
    { 
    return someDbContext.Files.ToList(); 
    } 
} 

Beispiel von POCO-Klasse, die für Dateien verwendet werden können:

public class File 
{ 
    public int Id { get; set; } 
    public string FileName { get; set; } 

} 
public class Folder 
    { 
    public List<File> Files { get; set; } 

    } 

Weitere Details hier: https://msdn.microsoft.com/en-us/library/ff649690.aspx

hoffe, das hilft!

Answer 2

Aber ich finde, dass ich manchmal nur eine Teilmenge der Informationen zurückgeben, die ein Objekt halten könnte.

Sie haben gerade das Objektmodell mit dem Persistenzmodell verwechselt.

Sie sehen, das Object Model kümmert sich nicht, wie der Speicher implementiert ist. Wenn sich eine Datenbank hinter dem Objektmodell befindet und Sie über Tabellen verfügen, die einige Daten enthalten, können Sie die Datenbank Ihrem Objektmodell beliebig zuordnen. Mit einem cleveren objektrelationalen Mapper können Sie beispielsweise eine Tabelle in zwei Klassen aufteilen oder mehrere Klassen in derselben Tabelle beibehalten.

So etwas, das aus der Perspektive Ihres Speichers wie "eine Teilmenge" aussieht, könnte möglicherweise nicht "eine Teilmenge" aus der Objektmodellperspektive sein.

Ein Beispiel spezifische Entity Framework 6-Lösung beinhaltet so Table Splitting genannt, die Ihnen eine Modellklasse in zwei Klassen, eine Klasse mit Core-Immobilien spalten können, die immer geladen sind und eine weitere Klasse mit Zusatzeigenschaften, die träge geladen werden nur wenn Sie auf die virtuelle Eigenschaft der Kernklasse verweisen.

Ein Beispiel Tutorial: http://www.c-sharpcorner.com/UploadFile/ff2f08/table-splitting-in-entity-framework-6-code-first-approach/

(nur zu erwähnen, das Gegenteil, wo zwei physikalische Tabellen Oe Modellklasse zugeordnet werden aufgerufen wird Splitting Entity)