DB-Daten (SQL Server) mit Katalogdaten (lokal, SQLite) verknüpfen

Hallo,

ich bin hier eher der stille Mitleser, habe jetzt aber dennoch mal eine Frage zur "best practice".

Angenommen, ich habe einen SQL Server mit einer Personentabelle. Die Personendaten können durch Benutzer geändert werden. Als Wohnort/Plz soll ein Katalogeintrag aus einer lokal vorhandenen (WPF/Client) SQLite-Datenbank ausgewählt werden müssen. Der Primary Key der Ort/PLZ-Auswahl würde dann in der Personentabelle gespeichert werden. Weiterhin sind die Ort/PLZ-Kombinationen in der SQLite-DB nicht durch Benutzer veränderbar, dh, die Dateisignatur wird bei jedem Programmstart geprüft und dieser ggf. verhindert, sobald sie nicht mehr stimmt.

Um nun Personendaten anzuzeigen, würdet ihr eigene (BL?) Personenobjekte als Zwischenschicht zwischen der Daten- und Anzeigeschicht verwenden, die die Daten aus der SQL Server-DB und SQLite-DB zusammenführen oder vielleicht mit anonymen Typen selbst arbeiten? Bisher habe ich immer nur mit den Entity-Objekte aus dem EF Core direkt herumgespielt, also gebunden, etc. Würdet ihr zu so einer Zwischenschicht generell immer raten? Oder bin ich komplett auf dem falschen Weg und der beste Weg ist es, alle Daten zusammen in der SQL Server-Db zu halten?

LG Tris

Dein Client(WPF Anwendung) sollte nie direkt auf die DB des Servers zu greifen.
Dazu nimmt man WebAPI und kommuniziert dann zwischen Server und Client über entsprechende Methode der WebAPI.

Die WebAPI sollte natürlich deine Anfragen Authentifizieren, damit man nicht einfach alle Daten abfragen kann.
Ebenfalls sollten deine Methode dann nur die Daten für die entsprechende Person liefern.
Übertragung sollte dann, da es ja personenbezogene Daten sind und du auch Zugangsdaten überträgst, am besten per https übertragen werden.
Somit kann niemand die Daten, die zwischen deinem Client und dem Server laufen, mitlesen.

T-Virus

Als Erstes mein derzeit allgemeiner Rat, kein EF Core zu verwenden.
Es ist im aktuellen Stadium nicht production ready.

Als Zweites, dass das Erwägen von anonymen Typen nie eine Lösung sein kann.
Sowas ist nichts anderes als ein Workaround eines Software / Architektur Fehlers.

Ansonsten sei gesagt, dass Datenobjekte NIE etwas in der Anzeigeschicht verloren haben. Nie.
Es muss immer eine Businssschicht dazwischen sein. Immer! (Bei Mini-Mini-Mini-Tools kann man hier mal nen Auge zu drücken; bei Geschäftsanwendungen eher nicht)
[Artikel] Drei-Schichten-Architektur

Ich hab nicht unbedingt die Business Regeln, die hier beschrieben sind, verstanden.
Aber wenn Du auf einen Key verweisen musst, dann musst Du natürlich den FK mitführen.

Ob Du dann die Werte des FKs (also PLZ und Wohnort) doppelt hälst, das sind dann oft Performance-Gründe.
Ist das das, was Du meintest?

Danke für die Antworten. Die 3-Schichten-Architektur muss ich mir wohl nochmal genau zu Gemüte führen (scheute mich bisher immer davor, zusätzlich zum DbContext und DbSet des EF noch eine zusätzliche Abstraktionsschicht einzubauen). Aber darauf wird es dann, trotz des Mehraufwands, mal hinauslaufen, danke 😃

Hi Tris,

wenn du da für die Unterschiedlichen Schichten Passende Generische Basis Klassen Erstellst. (Hier mal z.B. nach Generic Repository googlen). Hast du da kaum mehr aufwand. Grundlegend erstellst du dir einmal ein Model, was dann auch eine reine Objekt Orientierte Darstellung erlaubt. Was grade bei Komplexeren Datenmodellen sinnvoll ist. Da kann einer "einfache" O/R Mapper nicht mithalten. Mappst im DAL (manche machen es auch im BL) das Objekt auf das EF Model (da gibt es z.B. auch Automapper, die es bei einfachen Modellen können). Im DAL erstellst du dann einfach eine Klasse die von der Gernerischen Basis Erbt. Und gibst da an Welche Model Verwendet wird und schreibst dein Mapping vielleicht noch selbst. Im BL machst du das selbe nur ohne Mapping. Und wenn du wenn du eine Web Api hast. Wiederholst du das noch mal im Controller. Also Grob 10 bis 20 Minuten mehr aufwand. Wenn du die Generischen Basis Klassen hast.

Und wenn du es dann richtig machen willst, Implementiert du es nur gegen Interfaces und verwendest einen IoC Container um die Abhängigkeiten aufzulösen.

Was bekommst du dafür.
Erstmal es interessiert den Rest der Anwendung nicht mehr, wo der DAL die Daten hin speichert. Du hast da dein Objekt Model und kein EF Model. Es kann eine einfache Text Datei sein, XML, SQL oder NoSQL. Im zweifel musst du nur deinen DAL anpacken.

Es kommen neue Anforderungen für den BL hinzu. Z.B. schick den neu Kunden eine Willkommenes Mail. Kein Problem überschreibe die Methode der Basis Klasse. Da rufst du dann die Methode der Basis Klasse auf. Und im Anschluss Versendest du dann die Mail.

Und wenn du noch den IoC Container verwendet. Kannst du es auch je nach Kunden Anforderung Konfigurieren.

Du bekommst also für wenig mehr Aufwand einen hohen Grad an Flexibilität.

Auch wenn du es jetzt nicht brauchst weil es wirklich eine Mini Anwendung ist. Man sollte es einmal Implementiert haben um die Vorteile zu sehen. Es kann für die Zukunft nicht schaden.