Hallo
Naja, im Grunde einfach. Du lässt ja nur eine Schicht weg.
Benötigst also in der Businesslogic (dein Namespace ist falsch geschrieben) einen Verweis auf das EntityFramework.
Ich habe zum Testen (da ich keinen MySQL habe) einfach den InMemory-Provider genommen.
Als erstes komme ich zu dem was ich am Projekt verändert habe.
Eine Methode die mit zurückgibt ob es den User gibt, eine die mir zurückgibt ob sein Passwort korrekt ist. Vieleicht eine Mehtode
Gut. Ich habe mal eine Basisklasse für die BL erstellt.
Die hat zwei Konstruktoren und ein Property
Reichst du aber eine Contextinstanz hinein (weil du z.b. vom der LoginBl auf eine andere BL zugreifst und hier die selbe Instanz nutzen willst - wegen changeTracking) wird diese nicht zerstört.
Achja, und wichtig ist das das Property
Ja, und der Code im MainBl ist dann wieder ganz normaler code zum speichern oder abrufen von Daten.
Im ViewModel rufst du die Methoden einfach nur noch auf und dein ViewModel bleibt sauber, übersichlich und du hast wirklich nur noch den Code vor der Nase den du brauchst.
Zum Thema Asyncrone Methoden. Müssen nicht Asyncron sein. Ich empfehle es aber. So bleibt deine GUI nicht hängen. EF Core bietet so viele Async-Methoden an, wäre schade wenn man sie nicht nützt.
Wenn du Fragen hast immer nur her damit. Wenn man es mal versteht ist es echt nicht schwer und verdammt übersichtlich. Fragen - EF core spezifisch aber bitte in einem neuen Thread. (Und die werden kommen ;-))
Grüße
Sascha
Naja, im Grunde einfach. Du lässt ja nur eine Schicht weg.
Benötigst also in der Businesslogic (dein Namespace ist falsch geschrieben) einen Verweis auf das EntityFramework.
Ich habe zum Testen (da ich keinen MySQL habe) einfach den InMemory-Provider genommen.
Als erstes komme ich zu dem was ich am Projekt verändert habe.
Model.Protocol
hatte kein Property ProtocolId
. Auch wenn du es in diesem Moment noch nicht benötigst. Mach die Model immer fertig dann musst du die DB nicht X mal erstellen lassen. In der BusinessLogic habe ich erstmal alle Klasse rausgeworfen. Erstelle am besten Klassen immer erst wenn du diese wirklich benötigst. Ich habe gesehen du hast für jede Entität (also jede Modelklasse) eine Klasse in der BL erstellt. Klar, das erscheint ermal logisch. du hast Models und für jedes Model ein ViewModel. Also muss das sicher in der BL auch so sein. Naja, wenn man will ja, ich handhabe das so das ich die BL in Bereiche eingliedere. Beispiel: Die App öffnet sich und der User muss sich einloggen. Da habe ich keine UserBl und eine ProtokollBl und sonst was. Ne, ich habe eine LoginBl. Alles was zum Login gehört ist da drinnen.Eine Methode die mit zurückgibt ob es den User gibt, eine die mir zurückgibt ob sein Passwort korrekt ist. Vieleicht eine Mehtode
LoginUser()
. Diese prüft vieleicht nochmals und loggt den User ein, schreibt ein Protokoll usw. und wenn alles geklappt hat gibt diese Tru zurück und im ViewModel öffne ich das nächste Fenster. Ich weis aber immer das die Logik für Login genau dort drinnen ist.Gut. Ich habe mal eine Basisklasse für die BL erstellt.
Die hat zwei Konstruktoren und ein Property
Context
. Dieses Property hält die EF Core Contextinstanz. Weiters implementiert die Basisklasse Dispose damit der Context auch immer brav entsorgt werden kann.Reichst du aber eine Contextinstanz hinein (weil du z.b. vom der LoginBl auf eine andere BL zugreifst und hier die selbe Instanz nutzen willst - wegen changeTracking) wird diese nicht zerstört.
Achja, und wichtig ist das das Property
Context
und die Konstruktoren
internal sind. Warum? Weil du den DBContext sonst nach außen reichst und du somit im ViewModel einen Verweis auf das EF Core benötigen würdest. Das wollen wir ja nicht wenn wir "clean" bleiben wollen. Genau, ich konfiguriere in der basisklasse auch gleich den Context für NoTracking als Default da ich das immer zwecks Performance mache.Ja, und der Code im MainBl ist dann wieder ganz normaler code zum speichern oder abrufen von Daten.
Im ViewModel rufst du die Methoden einfach nur noch auf und dein ViewModel bleibt sauber, übersichlich und du hast wirklich nur noch den Code vor der Nase den du brauchst.
Zum Thema Asyncrone Methoden. Müssen nicht Asyncron sein. Ich empfehle es aber. So bleibt deine GUI nicht hängen. EF Core bietet so viele Async-Methoden an, wäre schade wenn man sie nicht nützt.
Wenn du Fragen hast immer nur her damit. Wenn man es mal versteht ist es echt nicht schwer und verdammt übersichtlich. Fragen - EF core spezifisch aber bitte in einem neuen Thread. (Und die werden kommen ;-))
Grüße
Sascha
If _work = worktype.hard Then Me.Drink(Coffee)
Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##
Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##