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

[Gelöst] EFCore executable notwendig (nur für die Operationen) | Namespace-strukturen
Killerkrümel
myCSharp.de - Member



Dabei seit:
Beiträge: 169
Herkunft: Hamburg

Themenstarter:

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

beantworten | zitieren | melden

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...
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von Killerkrümel am .
private Nachricht | Beiträge des Benutzers
Taipi88
myCSharp.de - Member

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1044
Herkunft: Mainz

beantworten | zitieren | melden

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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Taipi88 am .
private Nachricht | Beiträge des Benutzers
Killerkrümel
myCSharp.de - Member



Dabei seit:
Beiträge: 169
Herkunft: Hamburg

Themenstarter:

beantworten | zitieren | melden

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

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15526
Herkunft: BW

beantworten | zitieren | melden

Zitat von Killerkrümel

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

Avatar #avatar-3220.jpg


Dabei seit:
Beiträge: 1044
Herkunft: Mainz

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Taipi88 am .
private Nachricht | Beiträge des Benutzers
Killerkrümel
myCSharp.de - Member



Dabei seit:
Beiträge: 169
Herkunft: Hamburg

Themenstarter:

beantworten | zitieren | melden

Zitat von Abt
Siehe mein Beispiel https://github.com/BenjaminAbt/2018-Talks-ModernApiDevelopment/ (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.
Zitat von Taipi88
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
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Killerkrümel am .
private Nachricht | Beiträge des Benutzers