Devo creare una nuova applicazione da zero, quindi voglio implementarla utilizzando MVC3 e provare a seguire le best practice generali il più fedelmente possibile. Comunque, lo sto sviluppando come un esercito di un solo uomo. Fa molto di più per creare le viste prima, quindi ho alcune "Schermate di Mockup", quindi costruisco i Modelli e i controller? o viceversa?
Tendo a scorrere iterate entrambe le volte.
Di solito inizio disegnando il modello, poiché alla fine della giornata è la cosa più importante da ottenere a lungo termine.
Ma considero anche l'interfaccia utente, chiedendomi in che modo quest'ultimo influisce sul modello. Ci sono occasioni in cui il modello è giusto sulla carta ma porta a uno o entrambi i problemi di interfaccia utente e problemi di prestazioni. Adeguo il modello di conseguenza.
Ad esempio, prendi utenti e indirizzi. L'idea naturale è di normalizzare la cosa al punto in cui hai utenti, indirizzi, città, stati, paesi e una tabella user2ddress per una relazione n-n.
Ma se consideri le implicazioni dell'interfaccia utente e come potrebbe funzionare in un editor, l'ultima cosa che vuoi è un utente confuso che modifica l'indirizzo di qualcuno e finisce per cambiare l'indirizzo di molti altri. Si finisce per abbandonare la tabella user2address e attenersi a un campo user_id negli indirizzi (quindi una relazione 1-n).
(Non escludo l'esempio da stupido, in realtà ho visto questo nella realtà per i nomi e gli indirizzi di società su un sistema che aveva una tabella contact2company. Una segretaria ha cambiato il nome e l'indirizzo di un'azienda perché un contatto aveva una nuova datore di lavoro: ciò ha comportato un ingresso quasi duplice nelle aziende e ha modificato in modo errato l'indirizzo postale di numerosi altri contatti).
Il punto è, ci sono casi in cui l'interfaccia utente porta a modificare il modello e viceversa.
Un altro punto cruciale, che non hai menzionato ma che penso sia ugualmente se non più importante, sono i casi limite delle regole aziendali. In questi, "sempre" significa in realtà "di solito" e "mai" significa "raramente".
Ad esempio, ho visto negozi le cui tabelle degli ordini erano legate a un singolo prodotto e due date (order_date / clear_date). Ho detto buona fortuna con questo se hai bisogno di un ordine con più prodotti o se si verifica un chargeback o un rimborso parziale.
Per prima cosa è meglio creare schermate Mock up, poiché ti darà un'idea degli attori e dei casi d'uso. Ma gli schermi mock dovrebbero essere proprio questo, e dopo, dovresti codificarli di nuovo secondo la logica dinamica che vorresti.
Successivamente, dovresti procedere allo sviluppo di un modello di dati per la tua applicazione. Il modello ASP dovrebbe riflettere questo. Finalmente puoi progettare i tuoi Controller o Azioni. Per ultimo arrivano le schermate o l'effettiva interfaccia utente.
Questo dovrebbe essere il caso per caso. Dato che sei un esercito di un solo uomo, puoi creare piccoli casi d'uso, il più liberamente possibile dagli altri.
Spero che questo aiuti.
- Sid
A lungo termine, l'unica cosa che conta è avere il modello corretto per risolvere il vero problema.
Puoi (e dovresti) armeggiare con le opinioni per sempre per ottenere cose "giuste". Il modello, tuttavia, contiene preziose informazioni che non puoi facilmente coniare.
Il tempo impiegato per ottenere il modello giusto è il tempo impiegato per creare software di valore duraturo.
Bene - dipende - ma se ti piacerebbe utilizzare lo strumento scaffold allora avrai prima bisogno del tuo modello.
Leggi altre domande sui tag asp.net mvc asp.net-mvc-3