|
| |
VB.NET - Ein- und Umsteiger| MFC oder doch Code in den Windows-Forms? | |  | | Autor: Froggy | | Datum: 08.09.10 18:36 |
| Hallo zusammen,
bin fleißiger Leser dieses Forums, habe auch schon viele tolle Hilfen für meine VB6 Programme bekommen, nun ist es an der Zeit, dass ich mich von der schönen VB6 Welt zur .NET Welt bewege.
Für mich stellt sich nun die Frage, wie ich meine Programme am besten aufbaue. Habe schon einiges
über MVC gelesen. In der VB6 Welt laufen (bei mir auf jeden Fall  ) die ganzen Berechnungen (quasi die Business-Schicht) in den Formularen oder in ausgelagerten Modulen.
Das was ich so gelesen habe, sollte man in .NET 3 mit 3 Schichten entwickeln, ein Fronted, ein Business-Layer und ein DB-Layer. Das Frontend redet mit der Business-Schicht und nie direkt mit der Datenbank.
Ist das so korrekt, sollte man so ein .NET Programm aufbauen?
Was mir unglaublich schwer fällt ist das Verständnis wie die Kommunikation der Formulare mit der Datenbank zusammen wirkt, hatte nicht gedacht, dass ich mich sooo doof anstelle
Lese seit 2-3 Tagen nur E-Books und hier im Forum, aber geschnallt habe ich es immer noch nicht.
.NET ist OOP, also stelle ich mir das mal vor.
Ich erstelle eine Klasse für meine Adressdaten, jeder Inhalt (Feld) dieser Adresse wird angelegt (Properties), soweit so gut. Wenn ich mit diesen Daten was machen muss (irgendwelche Berechnungen), dann kann ich das innerhalb der Klasse "Adresse" mit Methoden machen, auch noch verstanden.
Hoffe ich 
Wie fülle ich aber meine Klasse mit Daten aus einer Datenbank (Access) Das habe ich noch nicht gelesen oder verstanden 
Habe ich VB6 auch schon mal ein Projekt mit Klassen gemacht, das ging dort ja auch mehr oder weniger. z.B. so:
Es gibt 2 Klassenmodule clsAdressen und clsAdressenItem.
In dem clsAdressenItem waren die privaten Variablen deklariert und die Properties zum Auslesen und Schreiben der privaten Variablen.
Im Klassenmodul clsAdressen gab es z.B. eine Funktion OpenCollection die sich mit der Datenbank verbunden hat und für jeden Datensatz in der Tabelle ein Instanz von clsAdressenItem erzeugt hat die DB Wert mit Hilfe der Properties gefüllt hat und dann in eine Collection hinzugefügt hat.
Wenn ich das richtig verstanden habe ist das ja auch in etwa die Vorgehensweise bei .NET
ABER, in VB6 war das grotten langsam und das befüllen der Klassen musste immer selber programmiert werden. Ist das in .NET anders? Wenn ja, kann mit jemand kurz erklären wie sowas von statten geht?
Sorry für den halben Roman, wusste nicht wie ich das kürzer schreiben soll.
Ich hoffe ich habe mich nicht völlig plamiert, weil ich doch noch gar nichts verstanden habe
LG Bastian | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Zero-G. | | Datum: 09.09.10 14:04 |
| Hey
Also, für Dein Problem gibt es meiner Meinung nach 2 - 3 Lösungen
1) DataSet's
Vorteil: Alle gängien ODBC & .NET Treiber werden unterstützt. Dazu findest Du auch 1000e Bsp.
Nachteil: Ist kein 100%ig es OOP, da Du die Namen der Felder erst wieder händisch ansprechen musst, wenn Du nicht wirklich alles über ein Grid steuerst. - Was in der Praxis unmöglich ist.
Nochdazu sind alle SQL-Statements im Code enthalten & somit nicht geschützt vor SQL-Injections
2) LinQ
Vorteil: Echtes OOP!. - Leider funktioniert es nur mit dem SQL Server von MS (von Haus aus). Es gibt mittlerweile von der Fa. Devart aber sehr gut funktionierende .NET Treiber, die eine Anbindung aller gängigen Datenbanken zulässt. - Die aktuelle Version ist auch großteils frei von Fehlern.
Die 2 wahrscheinlich wichtigsten Punkte: Erstens der SQL Code wird erst generiert wenn er benötigt wird. - Keine SQL-Injektions mehr möglich & zweitens: Du brauch VB vom Syntax nicht mehr verlassen, weil alle Anfragen direkt in VB geschrieben werden
Nachteil: Eine echte Weiterentwicklung findet im Moment anscheinend nicht statt. - LinQ selbst wird weiterentwickelt aber von MS aus gibt es keine Anstrengungen LinQ to Databases weiter zu entwickeln (Es gibt verschiedene LinQ's, die alle die gleiche Grundsprache nutzen, aber eben verschiedene Back-Ends nutzen z.B. XML, Objects usw.)
3) ORM Frameworks. Das wohl bekannteste = von DevExpress
Vorteil: Auch hier ist mit jedem ODBC/.NET Treiber für eine Datenbank der Zugriff möglich. Die Business Objects werden für Dich generiert. 100%ig OOP
Nachteil: Ich wollte es vor ca. 1 Jahr mal probieren, da war es aber nicht möglich, weil es meiner persönlichen Meinung zu diesem Zeitpunkt absolut nicht gereift war. - Hatte dann langen Kontakt mit dem Support, der mir sehr dankbar war, weil ich täglich Fehler mit mySQL gefunden habe. - Wurden zwar schnell korrigiert, aber trotzdem ärgerlich, wenn man immer nach 3 Zeilen Code wieder den Support kontaktieren muss... - Muss aber ehrlicher weise sagen, dass ich nach wie vor die Updates per Mail bekomme & was ich da so lese dürfte es wirklich gereift sein!
Hoffe Dir mal einen kleinen, Überblick über Deine Möglichkeiten aufgezeigt zu haben.
Schöne Grüße | |
| Re: MFC oder doch Code in den Windows-Forms? | | | Autor:  FZelle (Moderator) | | Datum: 09.09.10 14:16 |
| Irgendwie sind deine Grundlagen ziemlich löchrig.
1) Natürlich kann man ADO.NET auch gegen Sql-Injection schützen, dafür gibt es die ParameterCollection, und wenn man sich einen vernünftigen DAL macht, stehen die SQL Anweisungen auch nicht wild im Code.
2) LinQ ( Language Integrated Query ) ist ist nicht "LinQ to Sql". Du solltest also wirklich mal die Grundlagen wirklich verstehen und dann richtig wiedergeben.
3) Der bekannteste ORMapper ist nicht XPO den kennt im Gegenteil fast niemand der von VB.NET kommt.
Der bekannteste ist NHibernate dicht gefolgt von EntityFramework.
Wenn du solche Grundsätzlichen Aussagen machen möchtest, solltest Du also erstmal kontrollieren ob Du auch wirklich verstanden hast wovon Du redest. | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: FZelle (Moderator) | | Datum: 09.09.10 14:23 |
| Mit deinem Unwissen kannst Du dich eigentlich nicht Blamieren.
Wohl aber mit der Ansicht OOP in 2-3 Tagen verstehen zu können.
Es gibt Leute die nach Jahren C++ oder .NET immer noch nicht verstanden haben was OOP ist.
Das hat auch überhaupt nichts damit zu tun, das Du klassen erstellst, sondern wie die Zusammenhänge sind.
Und wer OOP kann, muss noch lange keinen Plan von SW Architektur haben.
Was meinst Du warum SW Architekten in grossen Projekten so Wertvoll sind?
Versuch einfach zu verstehen das es etwas dauert bis du das alles verstanden hast, und vor allem mach nicht den Fehler und lies hier ein bisschen dann da und frickel zwischendurch rum.
Lies dir erstmal die Grundlagen zu OOP komplett durch, danach solltest Du dich dann mit Pattern beschäftigen, und danach dann mit Architektur.
Das kann durchaus Jahre dauern bis Du da bist, wo Du meinst hin zu wollen. | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Zero-G. | | Datum: 09.09.10 14:43 |
| Jetzt weiß ich wieder, warum ich in den letzten 2 Jahren lieber im MS-Forum für VB unterwegs war...
| Zitat: | |
1) Natürlich kann man ADO.NET auch gegen Sql-Injection schützen, dafür gibt es die ParameterCollection, und wenn man sich einen vernünftigen DAL macht, stehen die SQL Anweisungen auch nicht wild im Code.
| |
Geb ich Dir recht. - Hab mich dabei schlecht ausgedrückt, weil ich meinte, dass der vom Designer generierte Code nicht vor Injections schützt.
Zu 2. Ich habe nie behauptet, dass LinQ / LinQ to SQL ist. - Ich habe es in diesem Fall abgekürzt, weil es hier eindeutig über die Frage zu Datenbanken geht. - & wenn Du den Schluss meiner Aussage gelesen hättest, habe ich explizit darauf hingewiesen, dass es verschiedene LinQ to ... gibt. Aber wenn man im Google mal LinQ eingibt, kommt man auf gute Referenzen.
Zu Punkt 3 finde ich Deine Aussage sehr interessant. - Wenn Du der Meinung bist, dass XPO niemand kennt & NHibernate viel mehr Leute kennen. - OK ... -> Ohne Worte ...
Muss aber wieder fairer weise zugeben auf's Offensichtliche hab ich vergessen gehabt, wie von Dir erwähnt: Entity Framework.
| Zitat: | |
Wenn du solche Grundsätzlichen Aussagen machen möchtest, solltest Du also erstmal kontrollieren ob Du auch wirklich verstanden hast wovon Du redest.
| |
Von Deinen perösnlichen Angriffen bist Du nach wie vor so arrogant wie früher. - Interessant...
Du hattest genug Zeit Froggy eine von Dir qualifizierte Aussage zu geben. - Hast Du nicht gemacht. - & die 2. Antwort von Dir, ist sicher auch sehr hilfreich für Froggy damit er sich besser auskennt.
Versuch mal von Deinem Rösslein runter zu kommen & Dir die die Frage von Froggy mal GENAU durch zu lesen. - Er will, dass ihm jemand Möglichkeiten aufzeigt, wie er ein Problem lösen kann & wenn die nicht 100%ig Deinem Einverständnis gefallen, weil vielleicht nicht ganz korrekt, dann auch gut. - Aber ich behaupte hier mal dass meine "falsche" Aussage ihm mehr hilft als Deine. | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Froggy | | Datum: 09.09.10 14:46 |
| Hallo,
danke für deine Antwort, ist schon ein bisschen ernüchternd.
War mir schon klar dass ich das nicht so auf die Schnelle lernen kann, hatte aber gehofft
wenigstens mal mit kleineren Projekten schon anfangen zu können.
Wenn ich aber bei der Konzeption schon merke, dass ich eigentlich alles was ich bisher gelernt
habe vergessen kann ist das schon deprimierend
Etwas über OOP zu lesen ist ja nicht das Problem, ich sehe eher das Problem, dass das alles
theoretisch ist, gibt es irgendwelche Vorgaben, wie man nun "heutzutage" ein Windows-Programm
aufbauen sollte?
Dann kann ich vielleicht für die einzelnen Bereiche mich schlau machen, denn nun 2 Jahre "stupide"
Bücher lesen und lernen um dann zu hoffen das ich alles verstanden habe will ich eigentlich nicht, bin eher einer der "try and error" Kategorie
LG Bastian | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: RalfE (Moderator) | | Datum: 09.09.10 15:30 |
| Für den Anfang kann ich dir folgendes Vorgehen ans Herz legen: Lese dir erstmal die ganzen OOP-Geschichten durch, um die theoretischen Zusammenhänge zu verstehen. Ganz trivial ist es nämlich nicht.
Was bei dieser Lektüre u.a. auf jedem Fall raus kommen muss: Jede Klasse hat genau eine Aufgabe! Von daher überlegst du im Vorfeld, was du alles für deine Anwendung brauchst an Funktionalität und erstellst dafür dedizierte Klassen.
Wenn du für ein Aufgabengebiet, z.B. Validierung oder Datenzugriff, mehrere Klassen brauchst, würde ich ab einer etwas größeren Anzahl diese in ein eigenes Projekt auslagern. Was ist eine größere Anzahl? Pauschale Antwort ist leider nicht möglich. Als erste Hausnummer würde ich 5 empfehlen.
Kleine Aufgabenbereiche wandern mindestens in einen eigenen Unterordner im Projekt.
Wichtig ist, dass du die einzelnen Aufgabenbereiche sauber einhälst. Gerade in Forms sollte auch nur Code stehen, der die Benutzeroberfläche manipuliert. Alles andere sind Aufrufen zu den jeweiligen Klassen.
Mit dieser Gliederung kannst du später dann entsprechende fortgeschrittene Techniken einbauen. Patterns, Unit tests, IoC/DI etc. lassen sich da dann recht angenehm einpflegen.
Ansonsten bekommt jeder Typ (Klassen, Module, Delegates, Enumerationen) eine eigene Codedatei, benenne Variablen etc. sprechend und sorge für eine angenehme Methodenlänge. Als ideal würde ich definieren, dass eine Methode bequem auf eine Bildschirmseite passt. Bei großen Methoden (sagen wir ab 40-50 Zeilen) würde ich Submethoden bilden.
Ansonsten mach dir keinen unnötigen Stress, unbedingt gewisse Techniken umzusetzen. Shipping is also a feature 
Edit: Typo
Ralf | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: FZelle (Moderator) | | Datum: 09.09.10 16:21 |
| Du hast dich da nicht falsch ausgedrückt, sondern etwas Falsches erzählt, da ist ein grosser Unterschied.
Und gerade deshalb weisen deine Aussagen jemandem wie Froggy genau in die Falsche Richtung, eben weil es komplette Fehlinformationen sind.
Ich frage mich wer hier auf zu hohem Ross sitzt?! | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Froggy | | Datum: 09.09.10 18:00 |
| Hallo Ralf,
danke für deine Ausführungen.
Ich werde versuchen das zu beherzigen
In der Hoffnung, dass ich mich nicht wiederhole und nerve.
Ich trenne die Forms von Berechnungen, also quasi ein Frontend-Layer und ein Business-Layer.
Das ist für mich völlig einleutend.
Was passiert aber mit der Kommunikation mit der Datenbank?
Bei vielen Beispielen die ich gelesen oder angeschaut habe kommuniziert ein Control
z.B. das Grid immer über eine Datenverbindung direkt mit der Datenbank, das ist doch
dann der falsche Ansatz, oder?
Was ich bis jetzt immer noch nicht gefunden habe ist, wie befülle ich meine Klassen mit
den Daten einen Datenbank, vielleicht hast du mir dazu auch einfach noch einen theoretischen
Ansatz.
Danke
LG Bastian | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Zero-G. | | Datum: 09.09.10 18:14 |
| Hey nochmal
Also dafür ist im Endeffekt eine ORM Lösung zuständig Beispiel
Also z.B. LinQ to SQL, Entity Framework, HIbernate, XPO.
mfg | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Froggy | | Datum: 09.09.10 18:34 |
| Hi,
OK, habe mal kurz das Entity Framework überflogen, das wäre dann schon
sowas, baut dieses Framework die "Klassenstruktur" dann neu auf, wenn
man später die Datenbank ändert oder muss man das dann manuell machen?
Weiß du / ihr das?
Darf ich fragen, welche Techniken ihr bei reinen Windows-Anwendungen
mit Datenbankzugriff auf Access benutzt habt?
Ich möchte in den nächsten 2 Jahren meine VB6 Anwendung auf .NET umstellen,
da ich im Moment nicht weiß, ob Windows 8 noch die VB6 Runtime mit ausliefert.
Zudem ist es denke ich an der Zeit, sonst verpasse ich noch den "Zug"
Mein Programm nutzen ca. 6000 Kunden und es werden im Moment mit dieser Anwendung
Daten in 120 Tabellen gehalten mit "im schlimmsten Fall" ca. 1.000.000 Datensätzen
Somit habe ich viel vor, aus diesem Grunde muss ich eine sehr gute konzeptionelle
Planung aufstellen, denn bei so einem Projekt einmal in die falsche Richtung
abgebogen kann fatale Folgen haben
Und wie schon gemerkt, ich stehe noch am Anfang
LG Bastian | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: RalfE (Moderator) | | Datum: 09.09.10 18:56 |
| Persönlich verwende ich kein Access, sondern den SQL Server (meist in der Express Version). Hat genügend Power, viele Features und wenn nötig kann man Problemlos auf eine der großen Editionen upgraden. Access hat an einigen Punkten doch seine Limitierungen.
Meistens verwende ich Linq To SQL oder das Entity Framework. Für andere Lösungen bin ich persönlich zu faul mich einzuarbeiten und teilweise ist das Tooling bei anderen nicht so toll. Ist aber Geschmackssache, ob man Tools oder Code bevorzugt.
Wenn es auf maximale Performance ankommt oder ich spezielle SQL Befehle brauche, die über einem O/R-Mapper nicht abgedeckt werden, dann verwende ich direkt klassisches ADO.NET mit SqlConnection, SqlCommand etc. Die Abfragen versehe ich mit Parametern.
Wie immer nun der Datenzugriff erfolgt habe ich Klasse(n) mit Methoden, die mir die Daten passend liefern für die jeweilige Form. Diese Methoden können z.B. Daten gefiltert liefern, spezielle Teile (Paging) zurückgeben etc. Dieses Resultat wird dann an die jeweiligen Steuerelemente via BindingSource gebunden.
Im Falle von Linq To SQL und Entity Framework kannst du die Klassen anhand eines Datenbankschemas erstellen lassen. Wenn sich das Schema ändert, kannst du das Klassenmodell aktualisieren.
Beim Entity Framework kannst du auch umgekehrt rangehen: Du definierst das Klassenmodell und lässt dir ein SQL Skript genieren, was eine passende Datenbank generiert.
Generell bist du beim Entity Framework sehr frei, was das Mapping zwischen Klassen und Datenbank betrifft. Bei Linq to SQL bist du ziemlich hart am Datenbankmodell gebunden. Wie es bei XPO, NHibernate etc. aussieht kann ich keine Aussage treffen - kenn ich mich nicht aus.
Ralf | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Froggy | | Datum: 09.09.10 19:16 |
| Hi Ralf,
danke für deine Antwort, die hat mir schon sehr geholfen!
Wie sieht es denn mit der Performance aus, wenn die Klassen immer erst mit den Werten der Datenbank gefüllt werden müssen, bevor sie an das Frontend übergeben werden können?
Bei VB6 war das Grotten langsam, hast du da Erfahrungswerte?
LG Bastian | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: RalfE (Moderator) | | Datum: 09.09.10 19:34 |
| Klar, je mehr Abstraktionsebenen existieren, desto mehr leidet die Performance. Allerdings ist der Overhead für eine typische Anwendung nicht entscheidend, da man durch einen O/R-Mapper meist doch einige Vorteile bekommt, die die etwas langsamere Performance ausgleicht (u.a. SQL Injection sicher, LINQ-Support (find ich sehr cool, dass ich mich nicht mit SQL beschäftigen muss, was ich in den meisten Fällen nicht will), IntelliSense-Support (sind ja Klassen), Compiler-Checks).
Was eher auf die Performance drückt, sind suboptimales Entwickeln der Abfragen. Sprich, wenn man tausende von Objekten abrufen will - das wird dauern. Hier wäre es wichtiger, die Daten auf ein angenehmes Maß zu reduzieren. Einmal wegen der Performance, zum anderen auch wegen des Benutzers. Ich weiß nicht wie du das siehst, aber bei mehr als 100 Items pro Seite dreh ich durch
Ralf | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: Froggy | | Datum: 09.09.10 22:13 |
| Hi Ralf,
danke für deine Antworten.
Mal sehen ob ich das alles so hinbekomme wie ich möchte. ;)
Vielen Dank nochmals.
LG Bastian | |
| Re: MFC oder doch Code in den Windows-Forms? | | | | Autor: FZelle (Moderator) | | Datum: 10.09.10 10:00 |
| Noch etwas was Du beachten solltest ist das Design der Anwendung selber, die DB Schnittstelle ist ja nur der Minimalste Anteil.
Du hattest ja oben schon von MVC gesprochen.
Man kann sich trefflich darüber Streiten ob bereits die bisherige Herangehensweise von MS schon MVC ist, aber in grösseren Anwendungen hat sich ( zumindest wenn man auch die Testbarkeit per Unittests haben will ) eher MVP und MVVM durchgesetzt.
Bei so einem Umstieg solltest Du dir auch dringend Unittests ansehen, und TDD, denn wenn man das mal verstanden hat, wird es einfacher von vornherein Testbaren und meist auch Fehlerfreieren Code zu erstellen. | |
 | 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 TOP! Unser Nr. 1 
Neu! sevDataGrid 3.0
Mehrspaltige Listen, mit oder ohne DB-Anbindung. Autom. Sortierung, Editieren von Spalteninhalten oder das interaktive Hinzufügen von Datenzeilen sind ebenso möglich wie das Erstellen eines Web-Reports. Weitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.