L'attivazione o la disattivazione delle funzionalità dell'interfaccia utente (o di altre funzionalità) in base alle date, un odore di codice?

Non c'è niente di sbagliato nel tweaking di un'interfaccia utente basata su quali funzionalità sono abilitate per un cliente o su quali tipi di distribuzione hanno scelto, ma la modifica dovrebbe

1. dipende da flag significativi, ad es. "HAVE_EXPORT" per abilitare / disabilitare un'opzione di esportazione, non per confronti con date strane. L'interfaccia utente non ha business conoscendo la regola aziendale su ciò che è stato pubblicato quando, dovrebbe soddisfare solo la sua attività di interfaccia utente e obbedire alle istruzioni specifiche dell'interfaccia utente.
2. Essere controllato lato server, in modo che un cliente non possa abilitare surrettiziamente funzionalità per le quali non ha pagato.

(Si noti che le funzioni di inversione - dis dopo un certo periodo di tempo - è un no no importante a meno che non abbiate chiaramente comunicato che state vendendo una versione di prova a tempo limitato. bombe a orologeria in qualsiasi altra circostanza faranno in modo che le persone ti odiano più velocemente di qualsiasi altra cosa.)

Il requisito in sé non è problematico, ma ci sono modi buoni e cattivi per implementarlo . Se il codice è stato copiato e incollato in tutto il posto che assomiglia a:

if (businessInitiationDate > cutoffDate)
  enableNewControlsForThisOneLittlePiece();
else
  enableOldControlsForThisOneLittlePiece();

Questo sarà difficile da mantenere, anche se al momento sembra più veloce. Ad esempio, forse ad un certo punto alcuni clienti più anziani vorranno il nuovo look. Forse ad un certo punto ci sarà una terza configurazione con la sua data di taglio.

Idealmente, vuoi che questa istruzione if appaia esattamente una volta nel tuo codice, preferibilmente sul lato server. Tuttavia, si desidera anche evitare di duplicare l'intera applicazione e apportare modifiche. Trova il codice comune e calcolarlo, quindi crea piccole funzioni separate solo per le parti diverse. Quindi abilita o disabilita tali funzioni da una posizione centrale.

È un requisito e, sebbene sembri essere puzzolente, fondamentalmente una configurazione basata su un valore datetime, non c'è motivo per cui il tempo non possa essere utilizzato per modificare l'interfaccia utente. Il caso classico è un display satnav che cambia dai colori vivaci di giorno a un tema scuro di notte (e se sei davvero dedicato, un colore in sordina al mezzo).

Tuttavia, una cosa che posso suggerire come miglioramento è rimuovere il concetto di una data che abilita i controlli, ma un numero di versione. La versione imposta la configurazione dell'interfaccia utente (es. Hai una bandiera per dire configurata per NewCustomer, e in futuro può essere espansa per soddisfare i controlli aggiuntivi richiesti da NewNewCustomer e così via). Questo è molto più facile da gestire nel codice e ha un buon odore.

Quindi hai solo 1 problema che sta impostando il numero di versione in base ad alcuni criteri, e questo può essere fatto da un controllo data oggi, possibilmente un'opzione di configurazione lato server, o anche un cookie che viene impostato dal login utente un po 'di tempo in futuro.

Questo sembra un caso speciale di una domanda più generale: è una cattiva pratica disabilitare le funzionalità dell'interfaccia utente per ragioni specifiche in base a regole predefinite? La risposta, quindi, è "ovviamente no". La consegna delle date può essere complicata perché date e orari sono difficili , ma in linea di principio non ci sono buone ragioni per non farlo se è ciò che i tuoi requisiti aziendali richiedono.

Se le modifiche hanno a che fare con uno specifico scopo aziendale che è sensibile alla data, allora è un male necessario.

Se si tratta di distribuire una revisione al programma che cambierà il programma in modo permanente, e il vecchio progetto non sarà mai più utilizzato, allora è meglio semplicemente distribuire un aggiornamento al momento giusto.

Sembra buono. È abbastanza comune che l'interfaccia utente si adatti a diversi utenti, ad es. qui su StackOverflow diverse funzionalità sono abilitate o disabilitate in base al karma di un singolo utente.

La ragione per cui non ti piace è che ovviamente aggiunge complessità relativamente a una soluzione in cui tutti vedono la stessa interfaccia utente. Tuttavia la complessità sembra essere complessità essenziale , es. è un requisito aziendale, non un artefatto di una cattiva decisione architettonica. Ovviamente avrà un costo (che dovresti comunicare al business), ma se l'azienda decide che ne vale la pena, vai avanti e implementalo.

Rischi noti: il rischio più grande è probabilmente quello di far verificare l'interfaccia utente nelle varie configurazioni. Se inizi a percorrere la strada di abilitare / disabilitare le funzionalità dell'interfaccia utente per vari gruppi di utenti, puoi rapidamente ottenere un'esplosione di possibili configurazioni.

Devi anche assicurarti di implementare le restrizioni nel livello della logica aziendale, in modo da verificare che i clienti non possano eseguire operazioni a cui non sono autorizzati, anche se l'interfaccia utente non dovrebbe renderla possibile in primo luogo:

Quello che stai descrivendo è il concetto di datazione efficace , che non è affatto una nuova idea e al suo interno un tipo di problema temporale a cui potresti applicare un schema temporale .

Essenzialmente ciò che dovresti fare nel tuo database è applicare una data valida per formare moduli o per formare versioni (qui di seguito denominate componenti), memorizzando alcuni metadati su di essi componenti e le loro date di inizio / fine effettive. Ovviamente avrai bisogno anche di alcuni dati sui tuoi utenti nell'applicazione.

Sembra che potresti avere altri motivi più convincenti per prendere in considerazione la possibilità di riscrivere questa applicazione. Se i problemi di appuntamenti efficaci sono i tuoi unici problemi, suggerirei che forse l'implementazione di appuntamenti efficaci è un'opzione migliore. In caso contrario, dovrai valutarlo in base al tuo scenario.

È una funzionalità attiva e attiva in base alla data, che è perfettamente valida. Immagina se la funzione fosse utilizzata solo durante un periodo promozionale o se dovesse finire quando un nuovo regolamento governativo interviene ad una certa data.

Stai lavorando su APS.NET e JavaScript, ma il frame di attivazione della funzionalità Java Togglz ha specificamente un regola di attivazione basata su data (e ora!) .