Implicazioni delle maniglie tra le forme

Per rispondere a ciascuna delle tue domande:

Quali sono le implicazioni della procedura che ho usato?

In questo caso, stai passando un riferimento da un oggetto genitore (il modulo principale) all'oggetto figlio (il modulo Impostazioni). Il risultato di questo è che il modulo Impostazioni deve conoscere molte cose sul modulo principale per funzionare correttamente. Alcune implicazioni non tanto desiderabili:

1. Il modulo Impostazioni deve conoscere i nomi di tutti i controlli nel modulo principale per funzionare correttamente.
2. Devi rendere pubbliche molte cose nel modulo principale. Rendere pubbliche le cose non è un peccato mortale da nessuna parte, tuttavia ora la tua forma principale sta pubblicizzando molte funzionalità che non ha bisogno di fare pubblicità al mondo esterno. Questo è più un problema quando il tuo progetto cresce, o se lavori con più di uno sviluppatore, che curioserà tra i membri pubblici dei tuoi oggetti per capire come lavorare con il tuo codice dall'esterno.
3. In fondo alla strada, se per qualche motivo il modulo principale e il modulo delle impostazioni erano in due diversi assembly (file DLL), potresti avere problemi perché non puoi creare riferimenti circolari.

Perché non si tratta di un approccio orientato agli oggetti?

Bene, ciò che stai facendo è orientato agli oggetti, tuttavia poiché hai un oggetto figlio dipendente da un oggetto genitore, stai andando contro Principio di inversione delle dipendenze e causano quindi accoppiamento stretto tra oggetti.

Quando le persone su SO e altri siti parlano di come è "object oriented" qualcosa, spesso si riferiscono a SOLID , che sono i cinque principi chiave della progettazione orientata agli oggetti.

Quale sarebbe la migliore pratica per inviare informazioni avanti e indietro tra classi / moduli?

Penso che in questo caso il modo più semplice per farlo sarebbe creare proprietà nel modulo Impostazioni che rappresentano i valori che vengono modificati all'interno della finestra delle impostazioni.

Ad esempio, questo codice si trova nel modulo Impostazioni:

public string UserName
{
   get { return txtUserName.Text; }
   set { txtuserName.Text = value; }
}

E questo codice sarebbe nella tua forma principale:

private void settingsToolStripButton_Click(object sender, EventArgs e)
{
    settingsForm = new miniDldMngr.SettingsForm() { UserName = lblUserName.Text };
    settingsForm.ShowDialog(); 
    lblUserName.Text = settingsForm.UserName;
}

È un po 'più codice, ma ora sei libero di apportare tutte le modifiche che desideri al modulo principale, e la forma delle impostazioni non dovrà essere aggiornata.

Ovviamente ci sono molti altri approcci che puoi seguire, il che mi porta alle tue ultime due domande:

Come andresti a creare l'evento menzionato da codesparkle?

Creare e innalzare un evento è un altro modo per evitare un accoppiamento stretto tra due classi. Si noti come gli oggetti Windows Form, come ToolStrip, siano in grado di chiamare metodi nel codice (settingsToolStripButton_Click), anche se il codice Windows Form non è collegato al codice. Questa è la bellezza degli eventi. La mia opinione è che è eccessivo in questa situazione, dal momento che si sta visualizzando il modulo come una finestra di dialogo (in cui è possibile leggere tutti i valori dopo la chiusura della finestra di dialogo), ma tuttavia ecco un esempio:

Per prima cosa, avresti un codice come questo in ImpostazioniForm:

public string UserName
{
   get { return txtUserName.Text; }
   set { txtuserName.Text = value; }
}

public event EventHandler UserNameChanged;
protected void OnUserNameChanged(EventArgs e)
{
   if(UserNameChanged != null)
   {
       UserNameChanged(this, e);
   }
}

private void txtUserName_TextChanged(object sender, EventArgs e)
{
    OnUserNameChanged(EventArgs.Empty);
}

Quindi, avresti un codice simile a questo nel tuo MainForm:

private void settingsToolStripButton_Click(object sender, EventArgs e)
{
    settingsForm = new miniDldMngr.SettingsForm() { UserName = lblUserName.Text };
    settingsForm.ShowDialog(); 

    lblUserName.UserNameChanged += 
        (sender, args) => lblUserName.Text = settingsForm.UserName;
}

Non so nulla dei pattern di progettazione MVC o MVVM, quindi alcuni link a una spiegazione strutturata sarebbero apprezzati.

Il pattern MVVM è un pattern supportato da Microsoft, principalmente per l'utilizzo in WPF. Puoi leggere una bella descrizione qui:

link

È possibile utilizzare questo modello in Windows Form, tuttavia non lo consiglierei, poiché WPF ha già completato l'impianto idraulico di base per farlo funzionare.

Buon codice!

Penso che gli altri siano preoccupati per l'accoppiamento stretto.

Ad esempio, cosa visualizzerà txtIni.Text quando Form2 è stato istanziato con il costruttore predefinito?

Secondo me, dovresti risolvere questo valore nella sua proprietà con un backing store, in modo che il costruttore alternativo, che Form1 chiamerebbe, potesse impostare questa proprietà.