Come posso separare l'interfaccia utente dalla business logic mantenendo l'efficienza?

^{Innanzitutto, l'esempio che hai fornito non è incredibilmente inefficiente; è solo leggermente inefficiente; la sua inefficienza è al di sotto del livello percepibile. Ma, in ogni caso, passiamo alla domanda.}

Per come la intendo, quando parliamo di separazione di UI e logica , intendiamo evitare l'accoppiamento ravvicinato .

Accoppiamento ravvicinato fa riferimento alla situazione in cui l'interfaccia utente conosce (e invoca) la logica e la logica conosce (e invoca) l'interfaccia utente. Per evitare un accoppiamento ravvicinato, non è necessario ricorrere ad abolire del tutto l'accoppiamento. (Questo è ciò che sembra mirare a demolire l'interfaccia tra di loro fino a un'interfaccia di stringa a minimo comune denominatore.) Tutto ciò che si deve fare è utilizzare accoppiamento libero .

Accoppiamento lento significa che A conosce B, ma B non sa A. In altre parole, le due parti coinvolte giocano distinti client e server ruoli, dove il client conosce il server, ma il server non conosce il client.

Nel caso dell'interfaccia utente e della logica, il modo migliore di organizzare questo a mio parere è vedere la logica come server e l'interfaccia utente come client. Quindi, l'interfaccia utente è costruita per la logica, ha conoscenza della logica e invoca la logica, mentre la logica non conosce l'interfaccia utente e risponde semplicemente alle richieste che riceve. (E queste richieste arrivano dall'interfaccia utente, ma la logica non lo sa.)

Per dirla in termini più pratici, da nessuna parte all'interno dei file del codice sorgente della logica dovresti trovare delle istruzioni di inclusione / importazione / uso che fanno riferimento ai file dell'interfaccia utente, mentre i file del codice sorgente dell'interfaccia utente saranno pieni di include / importare / utilizzare istruzioni che si riferiscono a file logici.

Quindi, per tornare al tuo caso, non c'è assolutamente nulla di sbagliato nel fatto che il codice UI che popola la casella combinata sia a conoscenza della classe di hamburger. Ci sarebbe un problema se la classe dell'hamburger sapesse qualcosa sulle caselle combinate.

Per inciso, questo design consente un'altra cosa che dovresti aspettarti da un sistema del genere: dovrebbe essere possibile collegare tante diverse interfacce utente come desideri alla logica, e il tutto dovrebbe comunque funzionare.

Devi separare ogni pezzo del modello, Visualizza & Controller, ma non c'è motivo per cui non è possibile (ad esempio) passare gli oggetti del modello tra il controller e la vista.

Quindi nel tuo caso, gli oggetti Hamburger faranno parte del Modello. Quindi si utilizza il controller per recuperare l'elenco richiesto di Hamburger s e passare tali oggetti alla vista (la casella combinata) da visualizzare. Quando il tuo utente ha selezionato quale hamburger, puoi quindi passare di nuovo l'oggetto Hamburger al Controller per l'elaborazione.

Il punto è che puoi ancora testare la logica "recupera Hamburger s" e la logica "processo Hamburger " separatamente dalla visualizzazione effettiva degli hamburger.