L'interfaccia utente in un'architettura pulita con un modello client / server [chiuso]

Question

L'interfaccia utente in un'architettura pulita con un modello client / server [chiuso]

#1 da (3 voti)

0

Ho letto (e guardato le presentazioni) su argomenti come: DDD, TDD, BDD, SOLID (principi), schemi di progettazione, codice pulito, architettura pulita, metodologie di progetto agili.

Tutto sommato ho una visione abbastanza chiara su come affrontare lo sviluppo di software agile. Soprattutto la parte DDD aiuta davvero a comunicare a tutti i soggetti coinvolti nel team (stakeholder, proprietari di prodotti, membri del team, ecc.).

Sviluppare un buon software è difficile e apprezzo molto le opinioni degli sviluppatori esperti. Tuttavia dicono cose come: "L'interfaccia utente (o database) è un dettaglio di implementazione".

Se stai osservando dal valore fondamentale del prodotto è certamente vero. In realtà, tuttavia, l'utente finale si occupa esclusivamente dell'interfaccia utente. Per rendere il nostro prodotto davvero utile, abbiamo bisogno di un'esperienza utente eccellente.

Diciamo che abbiamo un client html / css / javascript a pagina singola. La progettazione e la creazione di tutta la "sola interfaccia utente" sono abbastanza fattibili. Ho dei problemi con le seguenti cose:

Logica del dominio - Vive nel mio modello di dominio sul server. Sembra fragile duplicarlo nel client. L'esposizione di quelle parti del modello di dominio sul server potrebbe essere un'opzione, ma probabilmente creerebbe molte richieste (un problema di prestazioni). Tuttavia, richiedere all'utente di immettere un valore compreso tra 0 e 42 è chiaramente una regola aziendale.
Storie degli utenti / Scenari / Comportamento / Casi di utilizzo - Qualunque cosa tu chiami. Il server è in grado di gestire i casi d'uso, se lo abbiamo fatto bene sono ben specificati dalle specifiche comportamentali. L'interfaccia utente dovrebbe implementare una 'vista' o 'guida' per questi scenari. Dovremmo probabilmente riutilizzarli giusto?

Non sono riuscito a trovare nulla sulla combinazione di queste cose. Hai qualche risorsa o idea su questo?

Ci deve essere qualche persona intelligente che ha detto qualcosa di molto illuminante su questo argomento, altrimenti: ecco la tua occasione

bdd domain-driven-design clean-code architecture client-server

posta EECOLOR 21.01.2014 - 23:56

fonte

1 risposta

Leggi altre domande sui tag bdd domain-driven-design clean-code architecture client-server

ASP.NET senza input viewstate, come mai? Come si progettano i suoi vari modelli di architettura / business?

score 3 · Answer 1

Quanta logica di dominio hai nell'interfaccia utente lato client dipenderà in gran parte da quanto interattività e reattività vuoi nell'interfaccia utente.

Ad esempio, supponiamo di voler convalidare un campo che l'utente inserisce. Forse quella convalida coinvolge altri campi nel modulo (hai chiesto calze, ma non hai specificato quale colore di calze volevi). Nella maggior parte dei sistemi con poca interattività, ciò implicherebbe un round trip sul server, in cui il server convaliderà tutti i campi, quindi invierà una nuova pagina al client con i campi che non sono stati evidenziati evidenziati, insieme ad alcuni utili messaggi di errore.

Su un modulo ad alta interattività, non si otterrebbe un postback. Invece, il modulo ti direbbe semplicemente "hai dimenticato di specificare un colore per i tuoi calzini" e mantieni il postback fino a quando non hai specificato un colore.

O forse stai inserendo Year, Make and Model di una macchina (ciò che chiamiamo "dropdowning a cascata"). Sulla maggior parte delle pagine Web decenti, ciò richiede un viaggio AJAX sul server per aggiornare il prossimo menu a discesa, in base ai precedenti elenchi a discesa. Le pagine Web mal progettate richiedono un POST e un re-rendering completo dell'intera pagina solo per aggiornare il prossimo elenco a discesa.

Le pagine ben progettate e ad alta interattività funzionano proprio come le applicazioni desktop. Questo era usato con Flash, ma ora puoi farlo molto bene con le applicazioni web (vedi Applicazioni a pagina singola per una prova di concetto).

Ovviamente, devi ancora convalidare di nuovo sul server, poiché alla fine non puoi fidarti dei dati che un client ti invia, anche se il client ha una logica di convalida.