myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Entwicklung » Rund um die Programmierung » DB-Daten (SQL Server) mit Katalogdaten (lokal, SQLite) verknüpfen
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

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

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Tris
myCSharp.de-Mitglied

Dabei seit: 17.04.2009
Beiträge: 16


Tris ist offline

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

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
30.01.2018 16:55 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
T-Virus T-Virus ist männlich
myCSharp.de-Mitglied

Dabei seit: 17.04.2008
Beiträge: 1.267
Entwicklungsumgebung: Visual Studio, Codeblocks, Edi
Herkunft: Nordhausen, Nörten-Hardenberg


T-Virus ist offline Füge T-Virus Deiner Kontaktliste hinzu

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
30.01.2018 20:37 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

avatar-4119.png


Dabei seit: 20.07.2008
Beiträge: 12.897
Herkunft: Stuttgart/Stockholm


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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?
31.01.2018 10:16 Beiträge des Benutzers | zu Buddylist hinzufügen
Tris
myCSharp.de-Mitglied

Dabei seit: 17.04.2009
Beiträge: 16

Themenstarter Thema begonnen von Tris

Tris ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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 :)
31.01.2018 19:40 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Palin Palin ist männlich
myCSharp.de-Mitglied

Dabei seit: 22.08.2011
Beiträge: 1.090
Entwicklungsumgebung: VB.net


Palin ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
31.01.2018 23:12 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als ein Jahr.
Der letzte Beitrag ist älter als ein Jahr.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 17.08.2019 14:43