vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
sevAniGif - als kostenlose Vollversion auf unserer vb@rchiv CD Vol.5  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB.NET - Ein- und Umsteiger
Re: MFC oder doch Code in den Windows-Forms? 
Autor: ModeratorRalfE (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

alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
MFC oder doch Code in den Windows-Forms?2.212Froggy08.09.10 18:36
Re: MFC oder doch Code in den Windows-Forms?1.633Zero-G.09.09.10 14:04
Re: MFC oder doch Code in den Windows-Forms?1.521ModeratorFZelle09.09.10 14:16
Re: MFC oder doch Code in den Windows-Forms?1.484ModeratorFZelle09.09.10 14:23
Re: MFC oder doch Code in den Windows-Forms?1.624Froggy09.09.10 14:46
Re: MFC oder doch Code in den Windows-Forms?1.503Zero-G.09.09.10 14:43
Re: MFC oder doch Code in den Windows-Forms?1.509ModeratorFZelle09.09.10 16:21
Re: MFC oder doch Code in den Windows-Forms?1.519ModeratorRalfE09.09.10 15:30
Re: MFC oder doch Code in den Windows-Forms?1.443Froggy09.09.10 18:00
Re: MFC oder doch Code in den Windows-Forms?1.628Zero-G.09.09.10 18:14
Re: MFC oder doch Code in den Windows-Forms?1.495Froggy09.09.10 18:34
Re: MFC oder doch Code in den Windows-Forms?1.933ModeratorRalfE09.09.10 18:56
Re: MFC oder doch Code in den Windows-Forms?1.520Froggy09.09.10 19:16
Re: MFC oder doch Code in den Windows-Forms?1.549ModeratorRalfE09.09.10 19:34
Re: MFC oder doch Code in den Windows-Forms?1.466Froggy09.09.10 22:13
Re: MFC oder doch Code in den Windows-Forms?1.484ModeratorFZelle10.09.10 10:00

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übersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel