Design: le funzionalità di annullamento / ripetizione devono far parte del livello aziendale di un'app?

Naviga le tue risposte
2

Stiamo sviluppando una grande applicazione con una vasta GUI e un livello aziendale complesso. Senza entrare troppo nel dettaglio, l'applicazione è attualmente implementata in un ricco client nativo, ma la funzionalità è approssimativamente separata in parti correlate alla logica di business e la GUI (anche complessa) basata su un paradigma MVC. (Qui devo dire che il "modello" di MVC è strettamente collegato alla GUI, dato che proviene dalla libreria della GUI di Windows)

I piani devono migrare questa app sul web, dove la separazione appropriata diventerà ancora più importante.

L'applicazione presenta Annulla / Ripristina, basata su un modello di comando classico che incapsula la logica aziendale. Tuttavia questo modello di comando attualmente "vive" nella parte della GUI, e i comandi stessi hanno grandi dipendenze sul sottosistema della GUI (notevole per le funzioni relative all'aggiornamento della UI). La nostra idea è di spostarla più in profondità ai livelli core aziendali, che diventeranno parte del backend di una potenziale soluzione basata sul Web.

Ma ciò solleva una domanda fondamentale. Funzionalità di annullamento / ripetizione si suppone che vivano nel livello aziendale? Dove lo inseriresti e come giustificheresti questa scelta di design?

    
posta Scrontch 06.10.2016 - 13:39
fonte

4 risposte

6

Sicuramente questo dipende totalmente dalla tua attività.

  • Esempio 1: editor di documenti con funzionalità di salvataggio

L'editor stesso potrebbe darti annulla / ripristina mentre modifichi, ma quei comandi non sono conservati tramite salvataggio. non fa parte del prodotto per fornire una cronologia delle modifiche apportate al documento. - > Logica della GUI

  • Esempio 2: audit trail per il processo di ordinazione

ogni modifica dell'ordine è registrata e può essere ripristinata se necessario. Un requisito aziendale per il prodotto è la visualizzazione di tutte le singole modifiche e l'ordine può essere ripristinato in qualsiasi momento. - > Logica aziendale

    
risposta data 06.10.2016 - 13:47
fonte
1

Il fatto che tu stia combattendo con decisione dove hai bisogno di spostare il tuo oggetto / classe / pacchetto - sottolineando che questo oggetto / classe / pacchetto già viola la separazione delle preoccupazioni o addirittura viola il principio di Responsabilità Singola.

L'applicazione include Annulla / Ripristina, basata su un modello di comando classico che incapsula la logica aziendale .

Quindi il tuo oggetto comando ha già incapsulato alcune logiche di business

Tuttavia questo modello di comandi attualmente "vive" nella parte della GUI e i comandi hanno grandi dipendenze dal sottosistema della GUI .

I comandi dipendono dalla GUI, quindi lascia i comandi sul lato dell'interfaccia utente, ma sposta la logica aziendale sul livello aziendale.

Attualmente i comandi violano la presentazione e la separazione del livello della logica aziendale.

Quindi è necessario dividerli in due parti (presentazione e business).

    
risposta data 06.10.2016 - 14:09
fonte
0

Spero di averti capito bene:

Direi che se la tua applicazione sta facendo un lavoro intensivo della CPU, chiamerei semplicemente una funzione di annullamento nel core. Lo farei anche con la comunicazione cross-thread poiché annullare qualcosa potrebbe anche diventare molto complesso.

Questo ti dà una prova di futuro come bonus, perché se sei disposto ad implementare più funzioni / una GUI messicana, il tuo thread di Windows non sta causando molti più overhead e il tuo codice sarà semplicemente più bello da guardare.

    
risposta data 06.10.2016 - 16:59
fonte
0

Basarsi sulla risposta di @ @ Ewan riguardo alla verifica:

Undo / redo dovrebbe funzionare come un meccanismo di stack e generalmente consente di annullare solo nella parte superiore della cronologia (e di ripetere finché non vengono apportate altre modifiche). Questo stack cronologico di annullamento è, per tutti gli scopi pratici, legato alla sessione in cui si trova un utente.

Il mantenimento di uno stack cronologico di annullamento / ripristino a lungo termine nel livello aziendale potrebbe essere problematico, in vari modi, specialmente nel contesto di una collaborazione multiutente in cui l'illusione di un singolo stack di storia evapora.

Invece di fornire (un problematico) annulla / ripeti come stack della cronologia nel livello aziendale, è possibile mantenere un log delle modifiche nel livello aziendale e fornire all'utente funzionalità che consentano di creare un comando di inversione da qualsiasi dato cambia nel registro se è l'ultima modifica o meno.

(Si potrebbe anche catturare nel registro delle modifiche se un comando era destinato a invertire un precedente comando per contribuire a rendere più digeribile il registro delle modifiche in seguito.)

    
risposta data 06.10.2016 - 18:43
fonte

Leggi altre domande sui tag

Chiamata esplicita a Chiudi per una connessione db all'interno di un blocco utilizzando in C #? CQRS / ES in haskell, usando l'architettura di carta "Out of the tar pit"