Code in mehreren Dateien aufteilen

  • C#
  • .NET (FX) 4.5–4.8

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von us4711.

    Code in mehreren Dateien aufteilen

    Guten Abend!

    Durch das Projekt, an dem ich gerade arbeite, hat sich mir die Frage gestellt, ob es möglich ist, den Code in mehrere Dateien auszulagern, auch so Sachen wie z.B. die Button_Click Methoden usw.

    Bei mir ist es so, dass ich eine Form hab mit einem TabControl und 3 TabPages. Ist es möglich das man z.B. alles was zur TabPage1 gehört z.B. in die TabPage1.cs Datei auslagert?

    Code von TabPage1 -> TabPage1.cs
    Code von TabPage2 -> TabPage2.cs

    Dass das geht mit eigenen Funktionen usw. ist klar, mir geht es speziell um die Events/Methoden von den Controls. Hab das eben mal ausprobiert und logischerweise nur Fehlermeldungen bekommen. Liegt wahrscheinlich an meiner Unwissenheit. :D

    Falls das möglich ist, wäre es super wenn es mir jemand erklären könnte. Falls nicht, muss ich damit leben.

    Schau mal nach partial. Weiß aber nicht, in wie weit das funktioniert, da ich es nur bei Klassen kenne.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Danke für den Hinweis! :thumbup: Das ist genau das was ich gesucht habe. Und laut MSDN benutzt MS das selbst in VS.

    Jetzt muss ich das nur noch hinbekommen. ^^


    EDIT:

    so, ich hab mal geschaut wie es gehen kann usw., und das ist dabei raus gekommen:

    Form1.cs
    Spoiler anzeigen

    C#-Quellcode

    1. using System;
    2. using System.Windows.Forms;
    4. namespace WindowsFormsApplication1
    5. {
    6. public partial class Form1 : Form
    7. {
    8. public Form1()
    9. {
    10. InitializeComponent();
    11. }
    13. private void button1_Click(object sender, EventArgs e)
    14. {
    15. Class1 btn1click = new Class1();
    16. btn1click.Button1Click(this);
    17. }
    18. }
    19. }


    Class1.cs
    Spoiler anzeigen

    C#-Quellcode

    1. using System.Windows.Forms;
    3. namespace WindowsFormsApplication1
    4. {
    5. public class Class1
    6. {
    7. public void Button1Click(Form1 form)
    8. {
    9. MessageBox.Show("Hallo");
    10. }
    11. }
    12. }


    Jetzt stellt sich mir die Frage, ob das wirklich denen ihr ernst ist. Das wird ja noch unübersichtlicher als wenn man alles in die Form1.cs packt. Das sollte eigentlich nicht das Ziel sein, ich will es ja übersichtlicher haben und nicht komplexer.
    Oder ist das falsch so?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Parmaster“ ()

    das code-sample was du bringst ist natürlich blödsinn - steht das wirklich so bei MSDN?

    Für Code-Aufteilung gibts nicht wirklich ein Patentrezept.
    wenn du codes verschiedener Tabpages trennen willst, jo, partial ist ein Ansatz, wenn auch es nur scheinbar voneinander trennt.
    2 partiale klassen sind in wirklichkeit ein und dieselbe Klasse, nur ist der Code auf 2 (oder mehr) Dateien verteilt.

    partial kann aber auch für das tabpage-Problem praktikabel sein - kommt halt immer drauf an.

    ein anderer Ansatz ist, UserControls zu schaffen, wo die Teil-Logik drauf ist, und dann auf den Tabpages je ein son ucl draufpacken.

    also Leitlinie ist, zu erkennen, was sich wiederholt, und das zusammenzufassen in eine klasse, und die sollte mit möglichst wenig Berührpunkten nach aussen hin auskommen.

    Man kann auch Behaviors creiern, also Objekte, die ein Objekt übergeben bekommen, bestimmte Events abonnieren und das Objekt manipulieren, so kann man auch eine Menge Logik auslagern aus einem Form, was einem über den Kopf wächst.

    Ne, den Codefetzen hatte ich bei stackoverflow gefunden, aber ansonsten sind die auch fast immer gleich.

    ErfinderDesRades schrieb:

    partial kann aber auch für das tabpage-Problem praktikabel sein - kommt halt immer drauf an.


    Ja, würde ich ja gern. Aber wie macht man das richtig? Wie gesagt, ich finde nur so Sachen wie das was ich oben geschrieben hab, und das ist quatsch.

    ErfinderDesRades schrieb:

    ein anderer Ansatz ist, UserControls zu schaffen, wo die Teil-Logik drauf ist, und dann auf den Tabpages je ein son ucl draufpacken.


    Das geht leider nicht, da auf jeder TabPage völlig unterschiedliche Sachen sind.

    Mach den gesamten Inhalt der einzelnen TabPages je in eine UserControl, welches du dann in der TabPage anzeigst. Dadurch hast du für jede TabPage einen eigenen Designer und eine eigene Codedatei :)

    Nein. Du fügst deinem Projekt ein UserControl hinzu - nennen wir es mal TabPageControl1. Da machst du dann die Controls und den Code für die TabPage rein und fügst dieses Control als Dock = DockStyle.Fill in die TabPage ein. Dann hast du eine extra Codedatei für diese TabPage erstellt.

    @Parmaster erzeuge eine Form im Studio, Du bekommst die DAtei Form1.cs und Form1.Designer.cs.
    In diesen beiden DAteien ist die Flasse Form1 aufgeteilt.
    Genau so kannst Du das auch mit anderen Klassen tun.
    Wenn Du dann noch in der Datei ccc.csproj die Abhängigkeit einträgst:

    XML-Quellcode

    1. <Compile Include="Form1.Designer.cs">
    2. <DependentUpon>Form1.cs</DependentUpon>
    3. </Compile>
    4. <Compile Include="Program.cs" />
    werden diese Dateien im Solution-Explorer zusammen zum Aufklappen dargestellt.
    Die Anzahl der Dateien, in die Du eine Klasse verteilen kannst, ist (beliebig) hoch.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Parmaster schrieb:

    da die TabPages untereinander keine Abhängigkeiten haben.
    jepp - dann sind autarke Ucls der richtige Ansatz.
    Wie gesagt: man muss halt je nach Erfordernis das günstigste auswählen.
    edit:
    aber nenne die ucls nicht Tabpage1,... denn es sind keine Tabpages. Nenne sie (so sollte übrigens jede Benamung sein) nach dem, für was sie da sind: uclOverview, uclArticleDetail, uclKunde, uclBestellung, uclUsermanagement - whatever.

    edit:
    Aber erarbeite dir auch das Konzept partial class - man sollte einfach die Mittel kennen, die verfügbar sind.
    Dazu brauchst du übrigens nicht zwingend in der csproj - Datei rumzufuhrwerken.
    Also du kannst jederzeit und beliebig viele partiale Klassen-Dateien anlegen, und wenn du sie nicht als dependend registrierst, dann hat das einzig den "Nachteil", dass diese Dateien wie eigenständige Dateien gelistet werden im Solution - Explorer.
    Kann man auch als Vorteil sehen, denn dependend registrierte dateien sind wie gesagt verborgen, und das ist zweischneidig, denn da steht ja entscheidender Code drinne.
    Ich ordne das dann auch gerne so, dass ich die Dateien sinnig benenne, etwa wenn ich aus einem frmMain das OwnerDrawing rausziehe, dann kann ich die Dateien vlt. so nennen:
    frmMain.cs
    frmMain.OwnerDrawing.cs
    Dann sortiert sich auch zusammen, was zusammen gehört.

    Wenn magst, guck dir an, was ich mit dem FigureDts angestellt hab im AdvancedPainting-Projekt in allgemeine Zugriffs-Lösung für: MySql, Access, SqlCe, SqlServer, DatasetOnly - (da hab ichs mit Unterordnern gelöst)

    Dieser Beitrag wurde bereits 11 mal editiert, zuletzt von „ErfinderDesRades“ ()

Facebook
Telefonspende