Come dividere ASP MVC Project usando Code-First Entity Framework

Question

Come dividere ASP MVC Project usando Code-First Entity Framework

#1 da (2 voti)

3

Per un esercizio accademico, siamo stati incaricati di creare un piccolo sito web. Abbiamo già raccolto i requisiti e arricchito il settore aziendale per vedere le classi che dovremmo supportare. Deve essere nello stack Microsoft, quindi ho deciso di utilizzare ASP MVC con il codice prima Entity Framework . Ora sto cercando il modo migliore per dividere una squadra di 6 uomini al fine di affrontare al meglio il progetto.

TLDR: quali sono alcuni modi efficaci per dividere un progetto ASP MVC in modo che più sviluppatori possano lavorarci contemporaneamente?

Ho cercato dove sono stati suddivisi i progetti tra i livelli, ovvero database, business, viste e così via, ma non so esattamente come istruirli a progettare una vista per che non c'è controller.

La suddivisione tra i diversi modelli di business utilizza una strategia decente? Ho letto che questo ha portato a un'applicazione che non si integrava bene, a causa della diversa estetica.

project-management web-development asp.net-mvc entity-framework codefirst

posta Gilbrilthor 06.02.2014 - 00:47

fonte

1 risposta

Leggi altre domande sui tag project-management web-development asp.net-mvc entity-framework codefirst

Clausola "Dati sensibili" nel Contratto con il cliente di Bitbucket Devo affermare nei pacchetti? [duplicare]

score 2 · Accepted Answer

Il modo in cui il nostro piccolo team ha affrontato il problema era quello di sviluppare in modo cooperativo lo strato del dominio e la logica del database, e quindi ha proceduto a suddividere il lavoro per Area, così ho lavorato sulle impostazioni mentre un'altra persona lavorava sulle nostre pagine CRUD core. Una volta fatto, abbiamo scelto un'altra area e ripartiamo. Ci sono diversi problemi con questo approccio:

Il nostro lavoro di sviluppo iniziale ha prodotto visualizzazioni che non sembravano affatto simili. Dovevamo tornare indietro e rifare i punti di vista. Questo potrebbe essere evitato facendo in modo che le specifiche e il lavoro di progettazione siano eseguiti in anticipo (lo stiamo facendo ora e rende le cose molto migliori).
Entrambi abbiamo sviluppato metodi di libreria per fare la stessa cosa in modo indipendente, e il refactoring era necessario per rimuovere il duplicato (questo a volte era facile, ma spesso difficile dato che li abbiamo scritti in modo abbastanza diverso).

Se avessi di nuovo il mio tempo, farei quanto segue:

Scrivi insieme la tua logica aziendale e decidi gli endpoint URL (controllori e azioni e i loro argomenti). Se si utilizzano entità aziendali separate e modelli MVC, progettare anche i modelli MVC.
Ora una persona può scrivere viste in base ai modelli MVC e agli URL decisi, mentre un'altra persona scriverà i controller / le azioni necessarie.

Non è perfetto (non è possibile testare realmente le viste finché non vengono scritti i controller) ma minimizza l'interazione, quindi è possibile eseguire più lavoro più rapidamente.

Un'altra opzione (anche se non MVC vero) è scrivere l'applicazione come applicazione a pagina singola e fare in modo che un gruppo scriva tutto dietro l'API REST e un altro gruppo scriva il codice JavaScript sul front-end.