Designfrage: EF - DataContext über komplette DB oder einzelne Tabellen

verwendetes Datenbanksystem: MS-SQL lokal

Hi,

ich habe mich gerade etwas in ASP.NET und infolge dessen auch in das Entity Framework nach dem "Code-First" Prinzip eingearbeitet.
Ich hätte da ein Projekt anstehen, bei dem ich in der Datenbank einige Tabellen und auch Datenbankviews (=> Tabellen die selbst keine Daten enthalten, sondern Daten aus verschiedenen Tabellen darstellen) liegen müssten.
Nun, bevor ich mich da irgendwie in eine Sackgasse bewege, hätte ich da eine kurze, hoffentlich einfache Designfrage:

Sollte ich lieber jede Datentabelle für sich in die Datenbank legen, mit jeweils einem eigenen DataContext und die Views entsprechend nur in meinem C#-Code?
Oder sollte ich lieber mit meinen Klassen die komplette Datenbank in ein einzelnes Objekt abbilden und für dieses dann ein einziges DataContext anlegen?

Ich würde hier pro Tabelle eine Klasse anlegen.
Dann brauchst du aber auch für jede Klasse eigenen eigenen DbContext.
Ist zwar viel Tippaufwand, aber dann hast du mit einem sauberen Drei-Schichten Modell auch später einen sauberen Code und eine saubere Trennung der Klassen.
Bei den Views wirst du dann auch eigene Klassen und einen eigenen DbContext umsetzen müssen.
Nur so kann man den Code wirklich sauber trennen, was sich später bezahlt macht.
Wild zusammen gezimmerten Code kannst du auf lange Sicht schlecht warten oder erweitern.

T-Virus

Hallo da_user,

ganz verstehe ich deine Frage nicht.

jede Datentabelle für sich in die Datenbank legen

Wie sonst? Od. ich verstehe eben wie gesagt die Frage nicht.

So wie ich die Frage weiters lese existiert die Datenbank noch nicht. D.h. du kannst wirklich "grün" beginnen. Somit modelliere deine Klassen (im DAL -- data access layer) so wie du sie brauchst und sie Sinn ergeben. Via EF werden diese dann in die DB gemappt.

Den DbContext kannst du dir als "unit of work" vorstellen. D.h. kapsle darin die Klassen die zusammengehören und die in der Verwendung auch zusammen benötigt werden. Somit kann es durchaus mehrere DbContexte in einer Anwendung geben. Das hängt voll und ganz von deiner Domäne ab und wie das modelliert wird. Ohne diese Kenntnis ist es schier unmöglich einen allgemein gültigen Rat zu geben.

Außerdem gibt es später immer noch die Möglichkeit bestimmte Code-Teile zu überarbeiten (vllt. im Zuge eine Refactoring), falls bemerkt wird dass der aktuelle Weg nicht ganz so ideal ist. Das geht mit agiler Entwicklung fast zwangsläufig einher...daher beginne einfach mti einem Weg und passe die Richtung immer wieder an.

die Views entsprechend nur in meinem C#-Code?

Views im Sinne von "read-only-Tabellen" würde ich eher als ViewModel in der Domänen-Logik abbilden. ViewModels sind nicht unbedingt auf WPF (vom MVVM) beschränkt, sondern können mehr od. weniger in jeder Anwendung verwendet werden um "Rohdaten" für die View od. sonst eine spätere Verarbeitungsschicht aufzubereiten.

mfG Gü

ich habe mich gerade etwas in ASP.NET und infolge dessen auch in das Entity Framework nach dem "Code-First" Prinzip eingearbeitet.

Eigentlich ist das EF in ASP.NET deplatziert.
EF hat eher in Desktop-Anwendungen einen Sinn als in Webanwendungen.

Views gibt es in dem Sinne nicht wirklich.
Datenbank-Objekte haben auch in einer ASP.NET Page nichts zu suchen.
[Artikel] Drei-Schichten-Architektur

In ASP.NET hat man wie mit jeder anderen Anwendungstechnologie ebenfalls ViewModels.
ASP.NET MVC - Arbeiten mit View- und SubmitModels

ganz verstehe ich deine Frage nicht.

Zitat:
jede Datentabelle für sich in die Datenbank legen

Wie sonst? Od. ich verstehe eben wie gesagt die Frage nicht.

Die Frage ist eher, ob ich jede einzelne Tabelle/Objekt mit jeweils einem DataContext abbilde, oder die gesamte "Datenbank" mit einem einzelnem.

Ich mach mal schnell hingekritzelten Pseudocode, ich hoffe der veranschaulicht da Problem:

class Table1
{
    int ID;
    int Data1;
    int Data2;
}

class Table2
{
    int ID;
    int Data1;
    int Data2;
}

class TableView
{
    int ID;
    int Data1 = Table1.Data1;
    int Data2 = Table1.Data2;
    int Data3 = Table2.Data1;
    int Data4 = Table1.Data2;
}

class Database
{
    TableView tv;
    //[... weitere Tabellen & Views]
}

Mache ich jetzt:

    public class DatabaseContext : DbContext
    {
        public DatabaseContext(DbContextOptions<DatabaseContext> options) : base(options)
        { }

        public DbSet<Database>;
    }

oder:

    public class DatabaseContext : DbContext
    {
        public DatabaseContext(DbContextOptions<DatabaseContext> options) : base(options)
        { }

        public DbSet<Table1>;
        public DbSet<Table2>;
    }

und bilde "TableView" und "Database" nur im Code ab, weil in der SQL-Datenbank brauche ich die dann ja gar nicht erst.

Oder doch eher komplett:

public class DatabaseContext : DbContext
    {
        public DatabaseContext(DbContextOptions<DatabaseContext> options) : base(options)
        { }

        public DbSet<Table1>;
        public DbSet<Table2>;
        public DbSet<TableView>;
        public DbSet<Database>;
    }

Eigentlich ist das EF in ASP.NET deplatziert.
EF hat eher in Desktop-Anwendungen einen Sinn als in Webanwendungen.

Wie greife ich den sonst aus einer ASP.NET Webanwendung auf eine SQL-Datenbank zu, wenn nicht übers EntityFramework?

Datenbank-Objekte haben auch in einer ASP.NET Page nichts zu suchen.
[Artikel] Drei-Schichten-Architektur

In ASP.NET hat man wie mit jeder anderen Anwendungstechnologie ebenfalls ViewModels.
ASP.NET MVC - Arbeiten mit View- und SubmitModels

MVC ist umgesetzt, die Datenbank hängt im Model und natürlich nicht in der ASP.NET-Page. Der erste Absatz des verlinkten Artikels liest sich aber schonmal interessant. Den führe ich mir heute noch zu Gemüte!

Natürlich alles in einem Kontext. Sonst funktioniert das gar nicht.

Wie greife ich den sonst aus einer ASP.NET Webanwendung auf eine SQL-Datenbank zu, wenn nicht übers EntityFramework?

Wo steht denn, dass nur das EF für Datenbanken in ASP.NET ist? 🤔
ASP.NET verwendet .NET und man kann mit allen .NET Providern auf Datenbanken zugreifen, egal in WPF, Forms oder ASP.NET

Und in .NET heisst die Datenbankschnitstelle ADO.NET.
EF ist hierbei einfach nur ein Aufsatz für eben selbiges. Keiner zwingt einen aber, diesen Aufsatz zu nutzen.

@da_user
Ich bin erstaunt, dass du mit einem OR Mapper arbeitest und scheinbar nicht weißt was dieser eigentlich macht.
Den sonst wäre deine Frage doch schon beantwortet.

Ein OR greift auch nur auf die Datenbank Provider zu um eben deine Modelle(Klassen) auf die DB zu mappen.
Hier wäre es eben die Sql* Klassen, die dann die Verbindungen und Befehle an den SQL Server schicken und dir die Daten liefern.
Diese sind nur in den Interna soweit versteckt, dass du im OR Mapper i.d.R. nicht auf diese zugreifen musst.
EF Core ist hier ein Beispiel dafür, da man hier einfach nur beim DbContext den Provider initalisiert und EF Core, dann schon selbst weiß was gemacht werden muss.
Intern werden dann die entsprechenden Implementierungen instanziert und verwendet um mit der jeweiligen DB zu kommunizieren.

T-Virus