Desktop su Web - Come gestire i flussi di lavoro interattivi dell'utente

Le tue difficoltà principali sono che hai una discrepanza tra un flusso di lavoro molto lineare e personalizzato in un'applicazione precedente che non coincide con i flussi di lavoro di interazione dell'utente che sono comuni sul web.

Le applicazioni Web che interagiscono con un'applicazione server che contengono la business logic comunicano in uno stile di messaggistica di richiesta / risposta. Il browser client e il server che esegue un'applicazione con la business logic sono processi separati. Il client richiede una risorsa (pagina html, immagine jpg, dati JSON, ecc.) E il server fornisce tale risorsa in modo intrinsecamente stateless . Questo è un paradigma molto diverso dalla tua applicazione desktop autonoma che ha un concetto di stato globale per una sessione utente. La sessione degli utenti in un'applicazione desktop vive e muore in base al processo in esecuzione sulla workstation.

Quindi fondamentalmente ci sono due modi in cui puoi gestire la manutenzione dello stato in un'applicazione web che ha sempre una relazione client / server.

Server Centric

Un'applicazione web centrata sul server manterrà le informazioni stateful per la sessione di un singolo utente. Lo fanno tipicamente servendo un cookie di sessione una volta che l'utente è autenticato. L'applicazione client (browser) includerà il proprio token di sessione univoco con ciascuna richiesta che consente al server di recuperare informazioni sullo stato dei client dall'ultima volta in cui hanno ricevuto una richiesta per questo client.

Inoltre il server conterrà la maggior parte se non tutta la logica di business dietro l'esecuzione di azioni che l'utente aziendale tipico vorrà raggiungere, azioni che hanno un valore aziendale reale. Questo non deve essere confuso con la logica di presentazione che è la maggior parte del codice lato client (ad esempio Javascript) che esegue l'interazione dell'interfaccia utente come nascondere un particolare menu in un modulo se è stata selezionata una specifica casella di controllo. p>

Centro clienti

Sebbene sia possibile avere un server per mantenere l'autenticazione di un utente e mantenere una sessione attiva, è possibile utilizzare un framework di scripting lato client (ad esempio framework Javascript come AngularJS per eseguire la maggior parte se non tutte le operazioni della logica di business e le operazioni della logica di presentazione. I vantaggi di questo modello sono la possibilità di programmare l'applicazione Web nello stesso modo in cui si potrebbe programmare un'applicazione desktop. vivi e muori dalla navigazione del browser alla pagina corrente più o meno allo stesso modo in cui viverà e morirà durante il processo in esecuzione di un'applicazione desktop. Per la comunicazione con un database è possibile esporre servizi Web stateless sul server che può eseguire il proxy per un database .

Alcune considerazioni importanti con questo approccio sono che gli utenti sui browser client hanno la possibilità di modificare o modificare il comportamento di Javascript che potrebbe essere potenzialmente pericoloso e introdurre casi di eccezione sconosciuti all'applicazione. È altamente raccomandato che, se viene adottato questo approccio, si dovrebbe prestare molta attenzione alle interazioni con i server per disinfettare gli input e convalidare tutti i dati che vanno avanti e indietro.

Sommario

In breve, l'applicazione che hai specificato è molto vecchia. Sembra che tu stia facendo la scelta giusta per catturare i flussi di lavoro correnti e provare a valutare di cosa l'utente ha bisogno. Il prossimo passo sarebbe cercare di seguire i principi Agile e acquisire valore per il business nelle storie degli utenti. Vorrei iniziare su una lavagna pulita e cercare di scoprire altri mezzi e flussi di lavoro che possono anche raggiungere lo stesso valore aziendale catturato nelle storie degli utenti. Questa applicazione è così vecchia che è stata probabilmente limitata dalla tecnologia del suo tempo a dove i vincoli tecnici hanno influenzato i flussi di lavoro degli utenti in modo negativo o arcaico. Fondamentalmente ci sono probabilmente modi migliori, flussi di lavoro più intuitivi e interfacce utente che l'azienda può utilizzare per raggiungere gli stessi obiettivi finali.

Leggi su programmazione asincrona

Sembra che l'app desktop originale sia strettamente accoppiata alla GUI con funzioni che non proseguono finché l'utente non sceglie le decisioni dai popup.

Il Web e molti framework GUI non funzionano in questo modo: tutte le operazioni che possono richiedere l'input dell'utente devono fornire un delegato / callback affinché l'elaborazione possa continuare.

Non è poi così male, ma un enorme cambiamento rispetto al tuo attuale design. IMO vale la pena dedicare il tuo tempo alla progettazione attuale per supportare la programmazione asincrona, indipendentemente dal toolkit Web o GUI.

Questo collegamento sembra pertinente. Questo sembra anche vicino al link . Immagino che il tuo vecchio codice "business layer" sia scritto con gli strumenti Borland, sia C ++ che Delphi?

Qualche decennio fa eseguivo il porting di molti codici legacy da 16bit DOS (Turbo Pascal) a 16 bit DPMI (Borland Pascal) e Windows a 32 bit (Borland Delphi). Per portare la parte DOS come-è senza rompere nulla (riscrivere il codice non era un'opzione, solo piccoli refactoring) la prima cosa che dovevo fare era creare un "emulatore di terminale DOS" inserito come componente all'interno di una GUI di Windows circondata con API Win32 a 32 bit e nuovi componenti di Windows, ecc. Benché sembri diverso, il modo in cui l'applicazione DOS funziona con l'input dell'utente attraverso le finestre di dialogo modali ecc. è totalmente diverso da come funzionano le code degli eventi di Windows. L'emulatore sistemava le cose eseguendo l'emulatore DOS in un thread separato - tutte le funzioni di I / O utente reindirizzate al livello di emulazione che a sua volta sospendeva il thread DOS in attesa di un evento di Windows. Il codice DOS e la sua logica non sono stati affatto modificati (spezzati).

Nel tuo caso puoi anche uscire elegantemente creando innanzitutto (usando) un emulatore come JSC C # → JavaScript link . Una volta che puoi eseguire la tua applicazione "nel browser" puoi aggiungere i vantaggi richiesti ("..mobilità, possibilità di vendere versioni SaaS, aspetto moderno e componenti ...") uno per uno

Non so quale tecnologia sarebbe più adatta per il tuo linguaggio legacy lato server (il livello aziendale dipendente dalla GUI). Ma l'esecuzione nella tecnologia del browser è già qui, basandosi su asm.js come processore web, vedi per es. link o abbastanza lungo elenco di strumenti che possono essere utilizzati per convertire il codice legacy da eseguire nel browser all'indirizzo link

Dichiarazione di non responsabilità: non sono uno sviluppatore web di grande esperienza.

Credo che javascript / il lato client delle app web non vengano di solito scritti in questo modo, perché non importa cosa, nella maggior parte dei browser tutto il codice js viene eseguito in un thread. Tuttavia, puoi simulare questo comportamento, con qualcosa come questo (non l'ho mai usato, è proprio quello che ho trovato) , per mettere in pausa un thread (pseudocodice):

var stuffIsDone = false

doInAnotherThread(function () {
    // blah blah blah, do stuff, load purchase, talk to server, whatever

    // ...
    stuffIsDone = true
})

// DO NOT PUT THE BLOCKING WHILE LOOP IN THE MAIN THREAD, IT WILL FREEZE THE INTERFACE
doInAnotherThread(function () {
    while (!stuffIsDone) {} // Do nothing until stuff is done

    // stuff has been done, do whatever
})

  > Reworking/rethinking these workflows is not an option

Temo che tu debba aggiungere altri stati nel tuo flusso di lavoro, ogni volta che il vecchio flusso di lavoro richiede una decisione dell'utente senza modificare il flusso di lavoro di base.

esempio nel vecchio sistema:

customer adds products to basket
...
checkout: customer decides to buy the content of the basket
system does the verifification
    order article is out of stock
        messagebox: "do you want to (a) cancel the order, (b) remove this product or (c) select another one equivalent"?
            (a) ...
            (b) ...
            (c) ...

così invece di mostrare la messagebox lo stato del flusso di lavoro intermedio: "Uno o più articoli sono esauriti è stato raggiunto."

in alternativa puoi introdurre lo stato del flusso di lavoro intermedio "l'ordine non può essere elaborato" con informazioni aggiuntive per quegli articoli che hanno problemi.

in un'app web classica il cliente viene reindirizzato alla pagina di panoramica del paniere in cui vengono visualizzati i messaggi errati accanto all'ordine che presenta problemi.

@JBRWilkinson ha ragione, in sostanza.

Avere un front-end client Web e un back-end server Web è una cosa altamente asincrona per definizione. Soprattutto quando entrano in gioco i callback per caricare dinamicamente i dati o verificare le cose, ecc.

Ma non è necessario riscrivere l'intera app. Non è necessario riscrivere il flusso di lavoro. Devi "solo" lavorare su quelle parti che hanno a che fare con l'interfaccia utente in qualsiasi modo. scrivo "solo", perché questo può essere ancora abbastanza doloroso, specialmente quando tutta la logica è legata alla GUI le forme. Ci sono stato, fatto.

Abbiamo realizzato buone esperienze attraverso questo processo estraendo il codice dell'interfaccia utente in parti di codice condivise, allontanando l'interfaccia utente. Le parti di codice Thos vengono utilizzate sia dalla GUI desktop sia dal back-end Web. Mentre la GUI utilizza ancora controlli ecc. Come al solito, il back-end Web esegue il rendering dinamico delle pagine o fornisce JSON al client in base a tali informazioni. Il client è costituito da una buona porzione di codice di script per controllare l'interfaccia utente Web.

È stato un bel po 'di lavoro e ho preso qualche serio refactoring per fare quella transizione, ma ne è valsa la pena. E tu sai molto sul design del software buono e cattivo lungo la strada, posso dirtelo.