|
| |
VB.NET - Ein- und Umsteiger| Beispiel für das Befüllen einer Klasse mit Daten aus der DB | |  | | Autor: Froggy | | Datum: 10.09.10 23:54 |
| Hallo zusammen,
wollte mal die Profies hier für .NET fragen, ob jemand von euch mir mal ein
Beispielcode geben kann wie ihr eine Klassenstruktur (egal was, Personen, Artikel, ...) in einem Business-Layer durch eine Datenbankverbindung im DB-Layer befüllt.
Also MVC Aufbau.
Wenn das geht, wäre super nett ;)
Dank euch.
LG Bastian
Beitrag wurde zuletzt am 10.09.10 um 23:55:03 editiert. | |
| Re: Beispiel für das Befüllen einer Klasse mit Daten aus der DB | | | Autor:  DaveS (Moderator) | | Datum: 11.09.10 11:33 |
| Naja, 3-Schichten (DL, BL, PL) und MVC (M, V, C) wenn nicht völlig unverwandt sind aber doch zwei paar Stiefel. Anscheinend ist das nicht aus dem langen Thread klar geworden. Was habt ihr da alles diskutiert? Immerhin, zwei Methoden Daten aus der DB einzulesen ohne weiteres Hilfsmittel wie VS Assistenten, L2S, EF, weitere Orms usw findest du hier, klar und einfach.
http://www.vbarchiv.net/forum/read.php?f=24&t=4326&i=4355
Lediglich aber bringt das wenig wenn die Hauptarchitektur der Anwendung noch völlig unbestimmt ist.
Weiter geht's bei solchen Themen im Ado.Net Forum.
________
Alle Angaben ohne Gewähr. Keine Haftung für Vorschläge, Tipps oder sonstige Hilfe, falls es schiefgeht, nur Zeit verschwendet oder man sonst nicht zufrieden ist | |
| Re: Beispiel für das Befüllen einer Klasse mit Daten aus der DB | | | | Autor: FZelle (Moderator) | | Datum: 11.09.10 12:43 |
| Wie DaveS schin sagte, da sind bei dir noch Begrifflichkeiten durcheinander.
Datenlayer taucht im 3 Schichten Model auf, also UserInterface, BusinessLogic, Daten Layer.
MVC ist eher ein Teil des UI und BL Parts, der die Testbarkeit erhöhen soll.
Da Du ja etwas grösseres vor hast solltest Du das befüllen von Klassen nicht selber machen, sondern dies von einem ORMapper erledigen lassen, diese haben den Vorteil das die Abfragen etwas einfacher zu schreiben sind, und du u.U. auf andere DB Systeme umsteigen kannst, ohne Neukodierung.
Auch solltest Du eher MVP oder wenn Du WPF machen willst MVVM anschauen, das ist deutlich besser getrennt.
Aber ansonsten ist es recht simple, man muss da nicht so viel hineininterpretieren.
Hier etwa MVP:
Deine UI bietet seine Daten als Properties an (PassivView), diese werden vom Presenter befüllt ( Supervising Controller ).
Wird eine Aktion im View angestossen, z.b. ButtonClick wird die entsprechende Funktion im Presenter aufgerufen.
Hier holst du dir die Daten, ob das über einen ORMapper oder per DAL geschieht ist nebensächlich.
Der Presenter Validiert die Daten und setzt ggf im View wieder etwas.
Vorteil:
Per Unittests kannst du den Presenter also deinen UseCase automatisch testen, ohne das jemand die UI bedienen muss.
Da das aufsetzen einer vernünftigen Architektur nicht einfach ist, ist hier ein mal eben hingeschriebenes Demo schwierig.
Hast Du dich denn schon entschieden ob es WindowsForms oder WPF werden soll?
Denn darauf aufbauend kann man dann ein evtl schon bestehendes FrameWork empfehlen. | |
| Re: Beispiel für das Befüllen einer Klasse mit Daten aus der DB | | | | Autor: DaveS (Moderator) | | Datum: 11.09.10 20:33 |
| Ich möchte denn die andere Seite ansprechen, bevor man annimmt es muss wohl Orm sein.
Es mag zuerst schon sein der Begriff sagt einem nichts, und da sind wir schon beim ersten Thema: man muss ganz schön viel neues lernen. Und trivial wird das nicht sein. Ein Orm soll ja die "Widerstands Unausgeglichenheit" ("impedance mismatch") zwischen Sql DB und OOP Klassen ausmerzen, und es mag sein beim ersten Blick passiert alles automatisch, aber ohne zu wissen was hinter den Kullissen wirklich passiert kann man ganz schlechte Abfragen erstellen, die extrem langsam sind. Das ist bei etwa Linq to Sql und Linq/EF mehr oder weniger vorprogrammiert. Und viele Orms haben Probleme mit komplexen Queries, obwohl es kann aber sein, dass es effizienter wäre für das Gesamtsystem wenn der Client die Werte aus einfachen Queries zusammensetzt. Meine Meinung nach aber ist etwa eine Linq Abfrage oft schwieriger zu verstehen als normale Sql, und Spielraum for grobe Fehler hat man genug. Und jemand muss auch sowieso eine DB entwerfen (ist bei dir vermutlich schon gegeben). Und man sollte übrigens auch bedenken, dass wenn die BL Logik im Client implementiert ist, dass der DB Server einiges nochmal prüfen sollte. Eine BL am Server, was alle Clients ansprechen reicht aber um Gültigkeit der Daten zu sichern, aber ganz ohne DB Wissen geht es also nicht.
Ich glaube man kann Sql Datenbanken am besten ausnutzen wenn man Sql Datenbanken gut versteht, und ganz normale Methoden (man macht es ja schon 40 Jahre oder so) verwendet. Irgendwelche komplizierten Methoden die dazwischen kommen sind vielleicht hilfreich wenn man das alles nicht so gut versteht, aber man reicht schnell die Grenzen und wird danach eher aufgehalten und frustriert. Wenn man Sql Datenbanken nicht braucht gibt es andere Sachen wie Objekt-Datenbanken. Ist es eigentlich ein großer Sprung vorwärts wenn man schreibt etwa
For Each customer in dataContext.Customers
For Each Order In customer.Orders
...oder
For Each customer in dataSet.Customers
For Each Order In customer.GetChildRows()
...Nun, ich lasse die Frage offen.
Und ein Orm (oder nicht) ist auch nur ein (eventuell kleiner) Teil der Anwendung. Da hat man noch mit den Fragen zu Schichten, MVC/MVP/MVVM und was es alles sonst gibt zu tun. Man kommt eventuell schneller ans Ziel wenn man sich total von diesem Thema verabschiedet und sich auf eine gute Architektur mit längst bewährten Mitteln konzentriert.
________
Alle Angaben ohne Gewähr. Keine Haftung für Vorschläge, Tipps oder sonstige Hilfe, falls es schiefgeht, nur Zeit verschwendet oder man sonst nicht zufrieden ist | |
| Re: Beispiel für das Befüllen einer Klasse mit Daten aus der DB | | | | Autor: Froggy | | Datum: 11.09.10 21:23 |
| Hallo,
nun danke für deine ehrliche Antwort.
Mir geht es schon ähnlich, ich habe vor einem Jahr schon mal angefangen
.NET zu "lernen", habe mir einfach ein Projekt überlegt und habe drauf
los programmiert. Hatte damals kein 3 Schicht-Modell genommen, sondern
so wie in meinen meisten VB6 Projekte ein "2-Schicht Modell".
Also ein Frontend und ein DB-Layer, da es mir schon immer wichtig war
"datenbankunabhängige" Programme zu schreiben.
Das ging auch super, das auslesen der Datenbank mit ADO.NET, DataTables
und SQL Queries, war gar nicht so arg viel anders als in VB6.
Nun ein Jahr später beschäftige ich mich schon wieder mit diesem Thema,
und ich lese halt immer OOP, MVC, ORMapper und was ihr noch so alles nennt.
Da dachte ich mir, na ja, dann sollte ich meine zukünftigen Projekte
ja doch anders umsetzen.
Also reine 3 Schicht Modelle mit allen möglichen Klassenstrukturen.
Das Frontend komplett von der "Business-Schicht" trennen usw.
Es ist ja nicht so, dass man in VB6 zentrale Funktionen nicht in Module
auslagert, oder? Somit haben wir ja doch immer irgendwie ein "Business-Layer"
gehabt oder automatisch benutzt.
Bin jetzt schon ein bisschen verunsichert, wie ich mein Mamutprojekt aufbauen
soll. Bestimmte funktionale Dinge in eigene Klassen auslagern ist ja nicht
das Problem, aber ist das dann schon .NET konform? Mache ich mir dann
unnötig das Leben schwer? Würden so andere Programmierer klar kommen?
Ist das dann zukunftssicher?
Das sind die Fragen die ich mir halt stelle. 
Ich möchte erstmal mit reinen Windows-Forms Anwendungen anfangen, für mich
ist es klar, dass ich immer Access als primäre Datenbank habe und den
SQL Server als Sekundäre. Weitere Datenbanksysteme habe ich bis heute nicht
unterstützt und brauche das somit auch nicht. 
Ein reines 3-Schicht-Modell macht ja denke ich auch nur Sinn, wenn man
plant mal ein anderes Frontend zu implementieren, aber auch hier habe ich
keine Intension das überhaupt mal zu machen, wenn es performant und stabil
im 3 Schicht Modell läuft -> OK, dann hat man mal die Möglichkeit für ein
Webfrontend, aber das ist nicht mein primäres Ziel.
Mein primäres Ziel ist es die neue Sprache zu lernen und zukunftssichere
Software zu schreiben, da früher oder später VB6 Anwendungen einfach nicht
mehr auf den aktuellen Betriebssystemen laufen werden. 
Danke schon mal für euer Feedback.
LG Bastian | |
| Re: Beispiel für das Befüllen einer Klasse mit Daten aus der DB | | | | Autor: FZelle (Moderator) | | Datum: 11.09.10 23:16 |
| Es geht bei ORMappern, 3 Schichten Architektur, MVP und Pattern nicht darum, das man das nicht auch ohne das alles machen kann.
Aber "seperation of concern" hilft z.b. dabei die SW wartbarer und robuster zu machen indem jede Klasse nur für einen begrenzten Bereich zuständig ist, allerdings wird es auf den ersten blick dadurch umfangreicher.
Die meisten Pattern führen zu mehr Code, aber Sie haben gerade dann Vorteile wenn die SW Komplexer wird.
Ein Beispiel ist z.b. das hier ständig die fragen kommen wie man bei Textboxen z.b. Zahlen oder Buchstaben unterbinden kann.
Dies wird dann u.a. dazu benutzt um Die eingabe einer Zahl in einer Datatable zu Validieren.
Zusätzlich wird dann noch in der Form das Validating auf grenzen gemacht, oder irgendwelche Pattern überprüft.
Jetzt gibt es aber in fast jeder grösseren SW die Möglichkeit Datenbestände per CSV upzudaten.
Jetzt musst du hier die selben Regeln wieder implementieren.
Und hast du mehr als eine Form die diese Daten bearbeiten kannst du all diese Stellen immer schön parallel pflegen.
Hast du eine Businessschicht dazwischen, die die Validierung bei der Eingabe vornimmt, und per INotifyPropertyChanged und IDataErrorInfo die Daten verabeitet bzw Signalsiert, musst du das alles nur an einer Stelle pflegen.
Nimmt man hier eine BusinessRulesEngine wird es sicherlich im ersten Moment wieder umfangreicher, aber
Public Class Person
Inherits BusinessEntity(of Person )
protected overrides sub AddValidatioRules()
ValidationRules.Add( new StringRequiredRule("LastName"))
...
end sub
End ClassFinde ich schon recht eingängig.
Genauso ist es z.b. mit ORMappern.
Natürlich kann man das auch alles per SQL und ADO.NET machen, aber ich persönlich finde ein
Dim kunde as New Person
kunde.Firstname ="Max"
kunde.Lastname = "Mustermann"
Dim adress as Adress = kunde.Adresses.Add( new Adress)
adress.AdressType = Adresstype.BillingAdress
adress.Street=...
adress = kunde.Adresses.Add( new Adress)
adress.AdressTyoe = AdressType.DeliveryAdress
adress.Street=...
Session.Persist( kunde ) viel einfacher.
Wer allerdings Massendaten verschiebt, und stündlich 1.000.000 Datensätze verarbeiten muss, der ist sicherlich mit einem ORMapper nicht gut bedient, denn natürlich benötigen die Sachen Zeit und mehr Speicher.
Darum ist es aber wichtig zu wissen was es gibt, wie man etwas benutzen kann und wo die Grenzen sind.
Aber wie oben gesagt, du kannst das auch alles anders machen. | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
vb@rchiv CD Vol.6 vb@rchiv  Vol.6
Geballtes Wissen aus mehr als 8 Jahren vb@rchiv!
Online-Update-Funktion
Entwickler-Vollversionen
u.v.m.Jetzt zugreifen Tipp des Monats sevWizard für VB5/6 
Professionelle Assistenten im Handumdrehen
Erstellen Sie eigene Assistenten (Wizards) im Look & Feel von Windows 2000/XP - mit allem Komfort und zwar in Windeseile :-) Weitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.