Utilizzo da anni il pattern MVC nelle mie applicazioni (con separazione completa del controller dalle sue viste).
Dovendo implementare diverse centinaia di visualizzazioni per rappresentare un po 'più di 100 modelli per un potenziale contratto, questa volta vorrei ridurre i tempi di sviluppo delle mie attività di interfaccia utente e aggiungere alcune funzionalità aggiuntive (visualizzare le decorazioni, ecc.) .
Sono curioso di scoprire se qualcuno ha utilizzato o addirittura implementato un progetto come quello che spiegherò in seguito e, in tal caso, quali erano i tuoi pro e contro.
Senza entrare troppo nei dettagli, mi limiterò a elaborare un esempio di API con cui mi sono divertito nella testa per alcuni giorni insieme ad alcune spiegazioni un po 'più avanti, quindi ecco qui:
Model m = dao.getInstance(ID); // ie: possibly fetch it from a database
VTextField text = new VTextField(); // simply 'extends' the Swing components
text.setModel(m);
Decorator deco = DecoratorFactory.getInstance(); // specific to a customer
text.setDecorator(deco);
Controller c = ControllerFactory.getInstance(m);
text.setController(c);
Validator v = ValidatorFactory.getInstance(m); // get the current validator
c.setValidator(v, "validateText");
Quindi nell'esempio sopra, l'idea è che avrò la stessa applicazione per diversi client. Anche se ognuno ha accettato l'usabilità generale, ognuno vuole il proprio marchio L & F ad esso, alcuni basati su regole di business (ad esempio: un campo di testo ha errori, lo sfondo del campo di testo dovrebbe essere in giallo con caratteri rossi ... un altro vuoi il testo in nero e lo sfondo giallo con un bordo rosso).
Quello che stavo pensando è che in ogni evento (su focus, loss focus, tasto digitato, ecc.), il componente invocherà il controller. A sua volta, il controllore (attraverso la riflessione) invocerebbe il validatore. Se la convalida passa, il controllore aggiorna semplicemente il modello. Se la convalida fallisce, il controllore non aggiorna il modello.
Il controller manterrebbe uno stato di tutto questo (visualizzazione, modifica, modifica con errori, ecc.) e delegherebbe al decoratore che regolerebbe la L & F di ciascun componente in base alle richieste del cliente.
Ciò eviterebbe una tonnellata di blocchi "if / else" direttamente in un singolo controller. Il controller, il validatore e il decoratore conoscono l'istanza concreta da caricare in base a quale client esegue l'applicazione. In questo modo, posso separare la logica per ogni client e riutilizzarla quando è un comportamento condiviso.
Il decoratore non si limita ai metodi paintXXX (), ma chiama semplicemente 'setBackground (c)', 'setBorder (b)' e tutti questi metodi setter sono già disponibili nei componenti Swing. Il motivo per cui estendo ogni componente è semplicemente quello di aggiungere i metodi "setModel (m)" e "setController (c)" insieme a qualsiasi logica di framework di cui ho bisogno. Quando il componente è in modalità 'vista', di solito non dipinge il bordo e lo sfondo e tutte le cose (sembra più una pagina web tradizionale). Quando è in modalità 'modifica', sembra più simile a un componente Swing.
Quando progetto le interfacce utente dell'applicazione, di solito rimango a pochi componenti principali (JTextField, JTextArea, JPanel, ecc.). Quindi non sarebbe troppo lavoro da quella parte.
Non ho ancora iniziato a implementare nessuna di queste cose, quindi se conosci le librerie esistenti che eseguono qualcosa di simile, ti preghiamo di indicarle.
I miei unici veri problemi in questo momento sono come gestire casi in cui i componenti dipendono l'uno dall'altro. Ad esempio, due campi di testo con un valore int. Se un campo è dispari allora anche l'altro deve essere dispari e se uno è pari, l'altro deve essere pari. Quando si verifica la convalida, il validatore avrebbe bisogno del valore dell'altro campo di testo per validare correttamente ... quindi non ho ancora risolto questa parte.