Cosa fare sulla logica aziendale complessa basata su molte opzioni

Question

Cosa fare sulla logica aziendale complessa basata su molte opzioni

#1 da (1 voti)

0

Per prefigurare, penso che questo problema sarebbe più facile da capire se fornissi un esempio: In che modo un'applicazione complessa di valutazione fiscale gestisce più leggi fiscali e situazioni personali?

Ho ereditato una applicazione web che ha molta logica aziendale nelle viste. Questa logica controlla il flusso della pagina e la visualizzazione del controllo. L'essenza di questa logica si basa sulle proprietà di un contesto come: quale stato è stata l'azione intrapresa, chi è il client, quale tipo di attività e molto altro ancora. esempio di tale logica:

if task.state == "WA" then goto view1
else if task.type == "Wash Windows" && task.clientid == 5 then goto windowWashview2

le richieste di funzioni arrivano in ogni momento per aggiungere nuovi compiti, con nuove regole. Ho esplorato brevemente le lingue specifiche del dominio.

Qualche suggerimento?

business-logic business-rules

posta Chris 30.06.2015 - 22:07

fonte

1 risposta

Leggi altre domande sui tag business-logic business-rules

Registrazione dei dati privati Perché la definizione 'class String' ha un modificatore 'finale'? [duplicare]

score 1 · Answer 1

Prima di tutto, è seriamente necessario isolare la logica di business da Views. Non è necessario eseguire tutto in una volta, ma con le nuove richieste di funzionalità, è davvero necessario allenare una migliore distribuzione dei ruoli nella propria applicazione.

In secondo luogo, Strategy Design Pattern è esattamente ciò di cui hai bisogno nella tua applicazione:

L'idea del modello è di eliminare le dipendenze e lasciare che i componenti decidano cosa fare con i loro compiti. Ad esempio, potresti avere una classe Router che basandosi su quale stato è, restituirà la vista corretta da presentare all'utente.

Potresti avere una classe di JobBasedCalculator che baserebbe il calcolo della posizione e del tipo di lavoro che supporta. E ogni classe JobCalculator deve essere trattata come tale, solo QUALCUNO% di classe_così, indipendentemente dal fatto che si tratti di un lavoro IT, di un lavoro civico, ecc ... dovrebbero essere tutti conformi alla stessa interfaccia è ciò che intendo.

Un altro modello da esaminare è State Object. Potrebbe rivelarsi utile se hai tante decisioni logiche da prendere in base alle selezioni, ma se l'app è di grandi dimensioni, può anche essere un anti-pattern.