Sie sind aktuell nicht angemeldet.

Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Verständnishilfe in OOP für VBA-Umstieg
Autor: sronny
Datum: 08.02.16 16:12
Ein herzliches Hallo an die Gemeinschaft... Angemeldet hab ich mich hier, weil es doch ein sehr umfangreiches Board ist und ich derzeit am Umstieg von VBA zu VB.Net (Community Studio 2015)... Unter Excel VBA habe ich mir ein Programm geschrieben, wofür mittlerweile Excel nur noch zum Ausdrucken der Daten herhält. Warum also nicht gleich ein richtiges Programm daraus basteln- das lässt sich ja dann auch viel flexibler auf unterschiedlichen Rechnern einsetzen. Also jetzt schon mal viel Lektüre gelesen und gelesen und Kopf schwirrt. Ich bräuchte da mal eine Initialzündung für mein Verständnis. Wäre toll, wenn mir da jemand helfen könnte... In VBA habe ich für allerlei Sachen Klassen erstellt. Hier mal, wo ich am Grübeln bin, wie ich das in VB(.net) umsetzen kann: Klasse Adresse liest und schreibt Strasse, PLZ und Ort aus und in Datenbank Klasse Einsatzort enthält ein Objekt der Klasse Adresse und wird ergänzt durch Namen des Ortes speichert dann in der DB-Tabelle den Einsatzort oder liest aus Klasse Fahrtenbuch enthält drei Objekte von Einsatzort (Startort, Einsatzort, Endort) Klasse Einsatz enthält ein Objekt von Fahrtenbuch Klasse Rechnung enthält (unter anderem) ein bis viele Objekt(e) von Einsatz In der Userform Rechnung gibt es nun ein Objekt von Rechnung (oRechnung) dessen Daten in der Userform angezeigt werden - die Verwaltung (speichern, ausdrucken, berechnen etc.) der Daten geschehen in den einzelnen Klassen. Bedeutet, ich kann nun viele Objekte von Typ Rechnung erstellen (also viele Rechnungen), welche alle ein oder mehrere Einsätze haben, jeder Einsatz kann genau einen Start-, End-, Einsatzort haben und jeder Ort hat einen Namen und Anschrift. Bsp: oRechnung.Einsatz.Fahrtenbuch.Startort = Rathaus - automatisch wird dann unter Startort.Name (Rathaus) auch Startort.Strasse / PLZ / Ort herausgesucht (erledigt alles Klasse Einsatzort) Funktioniert genau so, wie ich mir das vorstelle. Nun gibt es VB, in welchem Vererbung und ganz viel viel mehr möglich ist. Ich denke halt aber noch im Schema VBA und komme nun nicht klar, wie ich das in VB umsetze. Ich habe erst gedacht, ich erstelle mir nach dieser Hierachie genauso meine Klassen und vererbe dann durch bis Rechnung. Und von Rechnung kann ich mir dann noch Kostenvoranschlag oder Mahnung etc. ableiten... Aber ich komme noch nicht klar, wie binde ich denn dann die drei Orte ein, wenn ich Einsatzort nur einmal vererben darf? In der gesamten Lektüre wird immer nur eine Klasse beschrieben, welche sich vererbt. In einem Hauptprogramm wird dann alles zusammengebastelt. Also bspw. würde dann der Kunde (welcher sich von Adresse ableitet) im Hauptprogramm hinzugefügt. Ist ja so nicht gewollt. Nach meiner Vorstellung (und Realisierung unter VBA) gibt es dann in der Klasse Rechnung noch ein Objekt von Kunde und ein Objekt von Kostenträger (welche sich in diesem Moment von Adresse ableiten lassen würden). Der Vorteil meiner Aufteilung unter VBA ich kann fast jede einzelne Klasse unabhängig voneinander benutzen. Bspw. unter Rechnung wähle ich mir Klient, die Orte etc. aus. Andererseits habe ich eine unabhängige Adressverwaltung, welche auf die Klassen beruhen. Jeder Klient, Kostenträger etc. kann auch mehrere Adressen oder Kontakte haben. Wo würde ich denn nun meine Kontakte hererben - welches bei mir auch wieder ein einzelnes Objekt ist). Meine DB ist auch soweit Normalisiert, so dass für jeden Punkt eine einzelne Tabelle existiert. Darauf bauen dann halt viele Klassen auf... Mit welchen Ansätzen muss ich arbeiten und welche Funktionen (Schnittstellen, Structur, List(of..) Vererbung etc. dazu am Besten nutzen? Oder verwende ich genau wie unter VBA dann die einzelnen Objekte oder implementiere ich die einzelnen Klassen: also Dim Klient as clsKlient Dim Einsatz as clsEinsatz oder implement cKlient implement cEinsatz oder bei Fahrtenbuch dim Startort as clsEinsatzort dim Einsatzort as clsEinsatzort Bin echt verwirrt mit der Fülle an Informationen und Möglichkeiten. Für eine hilfreiche Initialzündung wäre ich sehr dankbar...

Re: Verständnishilfe in OOP für VBA-Umstieg
Autor: Manfred X
Datum: 08.02.16 17:39
Du beschreibst nicht die Struktur des Problems, sondern Deine Klassen. Insofern kann man zu Möglichkeiten der Strukturierung wenig sagen. Da Deine Klassen mit einer Datenbank kooperieren, solltest Du Dir das Objekt-Relationale Designing z.B. Entity-Framework anschauen. Dabei werden Datenbank-Tabellen, -Relationen etc. in einem Objektmodell abgebildet. Diese Konzepte kommen Deiner Zielsetzung vermutlich recht nahe. https://msdn.microsoft.com/de-de/library/bb399232%28v=vs.100%29.aspx https://msdn.microsoft.com/library/bb399182%28v=vs.100%29.aspx Beitrag wurde zuletzt am 08.02.16 um 17:41:29 editiert.

Re: Verständnishilfe in OOP für VBA-Umstieg
Autor: sronny
Datum: 08.02.16 18:54
Nun, grob gesagt bezieht sich meine Frage darauf, ob in Zeiten von Vererbung, Polyphmorphie, Schnittstellen etc. noch so eine Herangehensweise wie in VBA üblich ist: also ich erstelle Klassen, welche für sich arbeiten können, aber per Objekt in einer anderen Klasse eingebunden werden. Also bspw. so Klasse1: Strasse PLZ Ort Speichern Ändern Löschen Klasse2: oKlasse1 as Klasse1 Name Speichern oklasse1.speichern Namespeichern ... Klasse3: Einsatzort as Klasse2 Startort as Klasse2 Zeit1 Zeit2 KMHinfahrt KMRückfahrt ... Speichern Einsatzort.speichern Startort.speichern etc... Im Prinzip könnte ich Klasse2 von Klasse1 ableiten, aber bei Klasse3 tue ich mich schwer, weil da verwende ich bisher drei Objekte von Klasse2 - also dreimal Name,Strasse etc... Danke schon mal für den Tip mit dem ORD. Werde mich darin mal einarbeiten... Ich wollte halt nicht wieder anfangen mit Programmieren und dann mit der Zeit (durch hinzulernen) feststellen, dass ich den vollkommen falschen Ansatz gewählt habe und wieder alles umschreiben. So ging es mir bisher - und das im laufendem Betrieb. Geht bei Rechnungen ja auch um viel viel Geld... Werde aber nun trotzdem einfach mal parallel meine Strucktur von VBA umsetzen und dann mal schauen wo und an welcher Stelle ich dann wie weiterkomme...

Re: Verständnishilfe in OOP für VBA-Umstieg
Autor: sv00010
Datum: 08.02.16 20:04
sronny schrieb: Zitat: Nun, grob gesagt bezieht sich meine Frage darauf, ob in Zeiten von Vererbung, Polyphmorphie, Schnittstellen etc. noch so eine Herangehensweise wie in VBA üblich ist Ja das ist noch so üblich. Polyphmorphie ist allerdings in VB.net nicht möglich, sondern nur einfache Vererbung. 0 Beitrag wurde zuletzt am 08.02.16 um 20:05:22 editiert.

Re: Verständnishilfe in OOP für VBA-Umstieg
Autor: Manfred X
Datum: 08.02.16 20:21
Du schilderst wieder Deine Klassen, aber nicht Deine Problemstellung. Dann kann man dazu auch nichts sagen. Was für Vorgänge der wirklichen Welt sollen in der Datenstruktur (Datenbank) abgebildet werden? Zur Anregung ... Klasse: Adresse abgeleitete Klassen: InlandAdresse / AuslandAdresse Klasse: Person enthält Name, Beruf eine oder mehrere Instanzen von Adresse abgeleitete Klassen: Kunde, Mitarbeiter, Lieferant Klasse: Fahrt enthält: Person Fahrer, Adresse Start, Adresse Ziel, StartZeit, Zielzeit, Grund der Fahrt, Nummernschild bzw. FahrzeugID abgeleitete Klassen: Auftragsfahrt (enthält Auftragsnummer) PrivatFahrt (enthält Person, die sie bewilligt hat) Leerfahrt Klasse: Fahrtenbuch: enthält Liste der Fahrten Klasse: Auftrag Kunde, Liste der Lieferanten, Termine Liste der zugeordneten Mitarbeiter benötigte Ressourcen usw. Hinter diesen Strukturen steht eine entsprechend aufgebaute Datenbank mit Tabellen und Relationen. Du mußt Dir zunächst über den Aufbau der Datenbank und die benötigten Abfragen klar werden.

Re: Verständnishilfe in OOP für VBA-Umstieg
Autor: sronny
Datum: 08.02.16 21:02
@sv00010: danke für den Hinweis- das ist schon mal gut zu wissen... @ManfredX: Das Programm beschreibt eine Rechnungsverwaltung für Dolmetscher. Es gibt einen Dolmetscheinsatz mit Anfangs/Endzeit, Stundensatz etc. Für diesen Einsatz soll die Fahrdaten aufgeführt werden- da diese mit abgerechnet werden. In jeder Rechnung können ein oder mehrere Einsätze abgerechnet werden. Dabei wird für jeden Einsatz auch die Fahrtdaten gespeichert. Es wird ein Klient benötigt und ein Kostenträger. In VBA hab ich halt Klient, Kostenträger, Einsatz, Fahrtenbuch, Anschrift und Adresse als eigenes Objekt. Bis auf Adresse kann jedes einzelne Objekt für sich bestehen. Jedes einzelne Objekt wird in eine relationale DB gespeichert und kann dann später wieder aufgerufen werden. Meine DB ist folgendermaßen aufgebaut (für die hier relevanten Sachen): Klient: (Kostenträger respektive) IDKlient Name Vorname Geburtstag IDKontakt Kontakt: (Kontakt ist das einzige nicht relationale Element) Telefon1 Mobil Fax ... Adresse: IDAdresse Strasse PLZ Ort: Adresse.PLZ und Ort.PLZ stehen in Verbindung PLZ Ort KlientAnschrift: (Kostenträgeranschrift dito) IDKLAnschrift IDAdresse IDKlient (So kann ein Klient mehrere Adressen haben) FahrtOrt: IDFahrtort IDAdresse Name Fahrtenbuch: IDFahrtenbuch IDStartort (enthält IDFahrtort) IDEndort (enthält IDFahrtort) IDEinsatzort (enthält IDFahrtort) StartZeit Ankunftszeit StartKM EndKM ... Einsatz: Zeitvon Zeitbis ... IDFahrtenbuch IDRechnung Rechnung: IDRechnung Preis Datum ... Die einzelnen Objekte habe ich halt mit Dim Klient as clsKlient , Dim Einsatz as clsEinsatz ... z.B. in Rechnung eingebunden. Die Klassen hinter den Objekten realisieren eben auch die Kommunikation mit der DB und alles andere relevante. In den Userforen werden dann nur die Objekte angezeigt...Und nach meinen Lektüren war ich mir nicht mehr sicher, ob es noch gängig ist dies so zu realisieren. VBA und VB.net ist ja doch nur in seinen Grundzügen gleich. Aber vom Standpunkt aus - alles ist ein einzelnes Objekt gesehen, sehe ich das immer noch als richtigen Ansatz. Vorteil ist eben auch, ich kann mit jedem einzelnen Objekt auch unabhängig arbeiten...Fand das ein recht cleveren Ansatz.. PS: Trotzdem vielen Dank für deine Denkansätze und Hilfestellungen. Mir geht es halt um die Objektverarbeitung und Klassenrealisierung in VB.Net. Beitrag wurde zuletzt am 08.02.16 um 21:06:47 editiert.

Re: Verständnishilfe in OOP für VBA-Umstieg
Autor: Manfred X
Datum: 09.02.16 09:30
[I]Die Klassen hinter den Objekten realisieren eben auch die Kommunikation mit der DB und alles andere relevante.[/I] In der Framework-Landschaft ist es clever, das Entity-Framework zu verwenden und diesen "Koordinierungskram" (Objekt-DB) nicht selbst zu programmieren (wesentlich höhere Flexibilität, Assistenten usw.). Durch "Mapping" wird es z.B. möglich, daß die Datenobjekte keine 1:1-Umsetzung der DB-Struktur zu sein brauchen. Beitrag wurde zuletzt am 09.02.16 um 09:36:31 editiert.

Re: Verständnishilfe in OOP für VBA-Umstieg
Autor: sronny
Datum: 09.02.16 11:20
Hab da jetzt mal schon angefangen mich reinzulesen. ADO.Net hat mit dem ADO von VBA nichts mehr gemeinsam - außer die Bearbeitung von DB. Jep, da ist bei allem ein großes Umdenken erforderlich. Deshalb war ja auch meine Anfrage in welche Richtung ich denken muss. Wird wohl ne Weile dauern, bis ich da mal was gescheites auf meinem Bildschirm zu sehen bekomme (also etwas, was meinen Vorstellungen entspricht smile). Vielen Dank schon mal für den Anstupsers in eine gewisse Richtung. Sowas hab ich halt gesucht... Werde wohl aber öfters noch Fragen haben...

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

Funktionen:  Zum Thema  |  Gesamtübersicht

Suchen