Laden...

[Gelöst] EFCore executable notwendig (nur für die Operationen) | Namespace-strukturen

Erstellt von Killerkrümel vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.278 Views
K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren
[Gelöst] EFCore executable notwendig (nur für die Operationen) | Namespace-strukturen

Hallo Community,

heute bin ich über EF Core gestolpert und habe mich gewundert,
warum zwingend eine executable erforderlich ist.

Das würde doch bedeuten, dass die DB Operationen direkt im (e.g. ASP.NET Core) Webservice hängen und nirgendwo anders genutzt werden können, oder sehe ich das falsch?

Wie baue ich mir beispielsweise ein Framework mit EFCore auf?
e.g.
NameSpace.DAL (Hier EFCore)
NameSpace.Model
NameSpace.Contract

Viele Grüße
Killerkruemel

Edit: Ich glaube ich habe das falsche Subforum erwischt, sorry...

1.029 Beiträge seit 2010
vor 5 Jahren

Hi,

da hast du nicht sauber gelesen.

Du kannst deinen ganzen EF-spezifischen Code durchaus unter einem .NET Standard Projekt verwalten (gibt gar keine Runtime für .NET Standard).

Nur wenn du dann halt die eingebauten Tools nutzen möchtest wie z.B. über die Kommandozeile deine DB aktualisieren zu müssen - musst du diese Kommandozeile eben auf einem ausführbarem Projekt ausführen lassen. Das kann dann dein ASP.NET Core Projekt sein, dass du eigentlich haben willst - kann aber auch ein .NETCore Konsolenprojekt sein, welches nur für diesen Zweck erstellt wurde.

In anderen Worten:
Nein - die Wiederverwendbarkeit deines EF-Core Codes wird dadurch nicht eingeschränkt.

LG

PS: Framework bauen... Da würde ich mir an deiner Stelle eher Vorlagen aus anderen Projekten suchen. Da stehen auch deinerseits ein paar wichtige Fragen an. UnitOfWork-Pattern ein Thema? RepositoryPattern? Da gibt's viele Optionen und Geschmacksfragen...
Nachfolgend hatte ich eigentlich angefangen noch weiteren Text zu einem Beispielaufbau zu schreiben - mir ist jedoch nach kurzer Zeit aufgefallen, dass man dadurch wohl leider schnell ein Buch füllen könnte. Insofern einfach folgende Tipps:
a) Arbeite dich erstmal in das jeweilige System ein, finde Schwachstellen und Lösungen
b) Schau dir an, wie andere die Probleme umgangen haben

K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren

Das würde bedeuten, das ich, sofern ich keine Änderungen an den Tabellen mehr habe, die generierten Entities und den Context in die StandardBibliothek kopieren kann/muss/sollte, verstehe ich das richtig?

16.807 Beiträge seit 2008
vor 5 Jahren

Wie baue ich mir beispielsweise ein Framework mit EFCore auf?

Ein .NET Namespace baut sich hierarchisch auf.
Siehe mein Beispiel https://github.com/BenjaminAbt/2018-Talks-ModernApiDevelopment/ (dachte Du hast das im anderen Thread bereits gelesen?).

NameSpace.DAL (Hier EFCore) NameSpace.Model NameSpace.Contract

Regel 1:
Man baut keine Namespaces mit Schichtenbezeichnern auf.

1.029 Beiträge seit 2010
vor 5 Jahren

Hi,

doch noch ein Nachtrag zum "Framework" - auch hier scheint es glaube ich Verständnisschwierigkeiten zu geben.

Wenn ich z.B. von Framework rede meine ich, dass du dir ein separates Projekt ohne eigentliche Datenbankoperationen machst, dass dir die Arbeit mit Datenbanken vereinfacht.
Also eine Schicht, die z.B. den korrekten Umgang mit Dapper oder EfCore vereinfacht.

Von den Assemblies ist ein solches Framework z.B. folgendermaßen aufgebaut: (Achtung: wurde dafür auch schon von Abt kritisiert - nicht gänzlich zu Unrecht):

  • FluiTec.Data -> Basisschnittstellen für UnitOfWork, Entitiy, Repository
  • FluiTec.Data.Dapper -> Basisimplementierungen für vorgenannte Klassen (abstrakt)
  • FluiTec.Data.Dapper.Mssql -> Weitergehende Implementierungen für MsSql
  • FluiTec.Data.Dapper.Pgsql -> Weitergehende Implementierungen für PgSql
  • FluiTec.Data.LiteDb -> Implementierung für LiteDb
  • FluiTec.Data.Sql -> Simpler SQL-Generator für verschiedene Provider
    (Nur Basis-Sachen wie "Such mir alle Records", "Zähle alle Records", etc. - alles leicht cachebar)

LG

Edit:
Auf Basis eines solchen Frameworks brauche ich z.B. in meinen Projekten dann nur noch:
a) Eine Assembly für Repository-Schnittstellen, die dann eben von der Basis ableiten und eben noch neue CRUD-Operationen vorschreiben wie z.B: "Such mir alle Records mit Name = Wert und Nummer = Wert2)
b) Eine Assembly je Provider (Mssql, PgSql, etc.), welche dann im wesentlichen die speziellen Sql-Befehle enthalten

Edit2:
Wer kopiert macht was falsch.

K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren

Siehe mein Beispiel
>
(dachte Du hast das im anderen Thread bereits gelesen?).

Habe ich tatsächlich gerade erst, dadurch wird mir jetzt gerade auch einiges klar.
Generell habe ich scheinbar Frameworkstrukturen falsch verstanden.

Von den Assemblies ist ein solches Framework z.B. folgendermaßen aufgebaut: (Achtung: wurde dafür auch schon von Abt kritisiert - nicht gänzlich zu Unrecht):

  • FluiTec.Data -> Basisschnittstellen für UnitOfWork, Entitiy, Repository
  • FluiTec.Data.Dapper -> Basisimplementierungen für vorgenannte Klassen (abstrakt)
  • FluiTec.Data.Dapper.Mssql -> Weitergehende Implementierungen für MsSql
  • FluiTec.Data.Dapper.Pgsql -> Weitergehende Implementierungen für PgSql
  • FluiTec.Data.LiteDb -> Implementierung für LiteDb
  • FluiTec.Data.Sql -> Simpler SQL-Generator für verschiedene Provider
    (Nur Basis-Sachen wie "Such mir alle Records", "Zähle alle Records", etc. - alles leicht cachebar)

Ich dachte bisher, das ich die entsprechenden Schichten anders abstrahieren muss.
(e.g.)
NameSpace.DAL
NameSpace.Model
NameSpace.Contract
etc.

Dein Beispiel hilft mir hier sehr weiter Abt,
und auch danke an dich für deine Zeit Taipi.

Viele Grüße, Killerkruemel