sto rispondendo in modo generale qui.
non credo che un pattern Singleton si adatterebbe bene con la gestione dei moduli. In genere, si desidera passare alcuni parametri di contesto al modulo e si potrebbe voler aprire più istanze dello stesso modulo. Quindi un singleton non si adatta bene all'IMO.
Credo che la gestione forma dovrebbe essere semplice.
Per esempio, se si desidera visualizzare un form modale da un'altra forma, vorrei scrivere qualcosa di davvero semplice:
private void button1_Click(object sender, EventArgs e)
{
using (ModalForm1 frm = new ModalForm1(myParam))
{
frm.ShowDialog();
if (frm.MyResultProperty == ...)
{
// Do some job here
}
}
}
Naturalmente si potrebbe scrivere una sintassi interfaccia/farmaci generici per evitare un po 'di duplicazione di codice in caso in cui si desidera visualizzare un sacco di forme modali:
public interface IFormResult<T>
{
T Result { get; set; }
}
public class ModalForm1 : Form, IFormResult<string>
{
public ModalForm1()
{
InitializeComponent();
this.Result = "My result";
}
public string Result { get; set; }
}
private void button1_Click(object sender, EventArgs e)
{
string res = ShowModalForm<ModalForm1, string>();
}
private static T2 ShowModalForm<T1, T2>()
where T1 : Form, IFormResult<T2>, new()
{
using (T1 form = new T1())
{
form.ShowDialog();
return form.Result;
}
}
Ma, onestamente, mi sento come se fosse un po 'overingeneered.
Secondo punto: se il modulo non segue esattamente questo comportamento specifico (ShowDialog() quindi è impostata una proprietà Result), è necessario scrivere un'altra interfaccia ... ecc.
Se questo tipo di sintassi (generici, interfacce, ecc.) Non riduce il numero di righe di codice scritte O la complessità O la manutenibilità (e ovviamente non possiamo dire che sia proprio il caso qui) , quindi è IMO piuttosto inutile.
Edit:
gestione Modulo dipende dal vostro caso d'uso.
- Se si dispone di dire 20 moduli che possono essere visualizzati allo stesso tempo, allora si dovrebbe pensare di un concetto
FormManager (o meglio: pensare a come migliorare l'esperienza dell'utente, riducendo il numero di possibili forme aperte)
- Se si dispone di qualcosa di relativamente semplice (2-3 moduli modeless allo stesso tempo + 3-4 forme modali possibili), non scriverei codice complesso per gestire tali moduli.
Generalmente, il modulo che viene utilizzato per avviare l'applicazione (cioè la forma che arresta il programma quando è chiuso, che è la forma che è un parametro di Application.Run()) è responsabile di altre forme. Si dispone di in un modulo principale e si moltiplicano i moduli figlio. Se il tuo caso è davvero diverso, probabilmente c'è qualcosa di più intelligente da scrivere, ma dipenderà dal tuo caso. Non credo che si possa fornire una buona risposta generale alla problematica generale della gestione della forma.
Onestamente, se vuoi qualcosa di veramente mantenibile, prova a ridurre (il più possibile) il numero di moduli che possono essere mostrati allo stesso tempo. La presenza di più moduli non modali visualizzati allo stesso tempo non offre una buona esperienza utente nella maggior parte dei casi e la gestione a vita può essere problematica se i moduli dipendono l'uno dall'altro.
Quali sono i requisiti? Vuoi più moduli da mostrare all'avvio? Una volta avviata l'applicazione, qual è la forma mostra/nascondi la strategia desiderata (moduli modali, più moduli, moduli MDI ...)? – ken2k
Quindi, non ho bisogno di più moduli visualizzati all'avvio. Una volta avviata l'applicazione, la forma mostra/nascondi strategia è semplicemente più moduli (non-MDI). Ci possono essere una o due forme modali. – Jason