Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Designfrage: EF - DataContext über komplette DB oder einzelne Tabellen
da_user
myCSharp.de - Member



Dabei seit:
Beiträge: 94
Herkunft: nähe Regensburg

Themenstarter:

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

beantworten | zitieren | melden

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?
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.975
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

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
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.
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.819
Herkunft: Waidring

beantworten | zitieren | melden

Hallo da_user,

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.

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.
Zitat
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ü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.826

beantworten | zitieren | melden

Zitat von da_user
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
private Nachricht | Beiträge des Benutzers
da_user
myCSharp.de - Member



Dabei seit:
Beiträge: 94
Herkunft: nähe Regensburg

Themenstarter:

beantworten | zitieren | melden

Zitat
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>;
    }
Zitat
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?
Zitat
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!
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.826

beantworten | zitieren | melden

Natürlich alles in einem Kontext. Sonst funktioniert das gar nicht.
Zitat
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.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.975
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

@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
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.
private Nachricht | Beiträge des Benutzers