Penso che non ci sia un grado abbastanza grande di separazione tra Business Logic, Data e Presentation in alcuni dei nostri prodotti. Sto cercando di spiegarlo ai colleghi, ma lo trovo difficile in quanto non riesco a pensare ad alcun esempio o link che sostengano i miei sentimenti su istanze specifiche che penso interrompano MVC.
La nostra API (versione) restituisce dati come GET - "api / v1.5 / product? id = 4":
"status": "PAID",
"category": "FISH",
"categoryImage": "www.site.com/images/fish.png"
Il campo di stato è, come ci si aspetterebbe, statico e può contenere "UNPAID", "PAID", "DELAYED".
Alcuni sviluppatori dell'interfaccia utente stanno esportando direttamente questo campo nell'interfaccia utente, ma la mia esperienza mi dice che questo campo dovrebbe riportare una rappresentazione di questi campi, l'interfaccia utente dovrebbe interpretare questi stati e agire di conseguenza.
Mi sbaglio? Qualcuno ha risorse che posso leggere o usare come esempi sul motivo per cui i dati dovrebbero essere interpretati, ove possibile?
Alcuni dei miei ragionamenti sull'uso di un flag di numero intero su una stringa di visualizzazione sono i seguenti:
- Internazionalizzazione - Non lo facciamo ora, ma consideriamo se potremmo implementarlo in futuro
- Prestazioni: il confronto tra stringhe è molto meno efficiente rispetto al confronto di tipi di base se i valori
- Dimensione: le stringhe occupano più spazio nei messaggi rispetto agli interi
- Dati / Logica / Divisione UI ecc. - I divari tra Logica, Dati e Presentazione dovrebbero essere rinforzati laddove possibile. Avere una stringa "PAGATO" per uno stato può significare "pagato" in questo momento, ma questo potrebbe cambiare in futuro - i dati rimarrebbero gli stessi ma il significato potrebbe cambiare nell'interfaccia utente.