Sviluppo dell'app N-Tier. In quale direzione?

Question

Supponendo che si stia implementando una user story che richiede modifiche in tutti i livelli dall'interfaccia utente (o dalla facciata del servizio) al DB.

In quale direzione ti muovi?

• Dall'interfaccia utente al livello aziendale, dal repository al database?
• Dal DB al repository al livello aziendale all'interfaccia utente?
• Dipende. (Su cosa?)

Answer 1

La migliore risposta che ho visto a questo tipo di domanda è stata fornita dai ragazzi di Atomic Object e dai loro Presentatore Primo modello. Fondamentalmente si tratta di un'implementazione del modello MVP, in cui (come suggerisce il nome) inizi a lavorare dal Presenter.

Questo ti fornisce un oggetto molto leggero (dal momento che il presentatore è praticamente lì per eseguire il marshalling dei dati dal Modello alla Vista e degli eventi dalla Vista al Modello) che possono modellare direttamente il tuo insieme di azioni dell'utente. Quando si lavora su Presenter, la vista e il modello sono generalmente definiti come interfacce e derisi, quindi il focus iniziale è sulla definizione del modo in cui l'utente interagisce con i tuoi oggetti.

In genere mi piace lavorare in questo modo, anche se non sto seguendo uno schema MVP rigoroso. Trovo che concentrarmi sull'interazione dell'utente mi aiuti a creare oggetti business con cui è più facile interagire. Usiamo anche Fitnesse in casa per i test di integrazione, e trovo che scrivere i dispositivi per Fitnesse mentre costruisco il mio gli oggetti business aiutano a mantenere le cose focalizzate sulla prospettiva dell'utente della storia.

Devo dire, tuttavia, che si finisce con un ciclo TDD piuttosto interessante quando si inizia con un test Fitnesse fallito, quindi si crea un Unit Test fallito per quella funzionalità e si risale lo stack. In alcuni casi sto anche scrivendo test unitari del database, quindi esiste un altro livello di test che possono essere scritti, falliti e superati prima che i test Fitnesse superino.

Answer 2

Se è probabile un cambiamento, inizia dalla parte anteriore. È possibile ottenere un feedback immediato dagli azionisti. Chissà? Forse in realtà non sanno cosa vogliono. Guardali usare l'interfaccia (UI, servizio o altro). Le loro azioni potrebbero ispirarti a vedere il problema sotto una nuova luce. Se riesci a rilevare le modifiche prima di codificare oggetti di dominio e database, risparmi un sacco di tempo.

Se i requisiti sono rigidi, non è così importante. Inizia nel livello che è probabilmente il più difficile: affronta il rischio in anticipo. In definitiva, questa è una di quelle "più un'arte che una scienza" problemi. È probabilmente una delicata interazione tra il design dei livelli che crea la soluzione migliore.

Saluti.

Answer 3

Lo farei dal basso verso l'alto, poiché avresti alcuni risultati di lavoro veloci (cioè puoi scrivere test unitari senza un'interfaccia utente, ma non puoi testare l'interfaccia utente fino a quando il modello non è finito).

Ci sono altre opinioni, però.

Answer 4

Vorrei iniziare a modellare il dominio problematico. Creare classi pertinenti che rappresentano le entità del sistema. Una volta che mi sento sicuro di ciò, proverei a trovare una mappatura fattibile per mantenere le entità nel database. Se si mette troppo lavoro nell'interfaccia utente prima di avere un modello del dominio, c'è un rischio significativo che è necessario rielaborare l'interfaccia utente in seguito.

Pensandoci, probabilmente dovrai fare alcuni aggiornamenti a tutti i livelli ... =)