Risposte:
Per quanto riguarda le cartelle che hai citato:
/libs viene solitamente utilizzato per la personalizzazione classes/functions/modules/vendoro /supportcontiene librerie di terze parti (aggiunte come sottomodulo git quando si utilizza git come controllo del codice sorgente)/spec contiene le specifiche per i test BDD./testscontiene i test unitari per un'applicazione (utilizzando un framework di test, vedere
qui )NOTA: entrambi /vendore /supportsono obsoleti da quando NPM ha introdotto una gestione pulita del pacchetto. Si consiglia di gestire tutte le dipendenze di terze parti utilizzando NPM e un file package.json
Quando si crea un'applicazione piuttosto grande, si consigliano le seguenti cartelle aggiuntive (soprattutto se si utilizza un tipo di MVC- / ORM-Framework come express o mongoose ):
/modelscontiene tutti i tuoi modelli ORM (chiamati Schemasin mangusta)/views contiene i tuoi template di visualizzazione (usando qualsiasi linguaggio di template supportato in express)/public contiene tutto il contenuto statico (immagini, fogli di stile, JavaScript lato client)
/assets/images contiene file di immagini/assets/pdf contiene file pdf statici/css contiene fogli di stile (o output compilato da un motore CSS)/js contiene JavaScript lato client/controllerscontiene tutti i percorsi express, separati dal modulo / area dell'applicazione (nota: quando si utilizza la funzionalità di bootstrap di express, questa cartella viene chiamata /routes)Mi sono abituato a organizzare i miei progetti in questo modo e penso che funzioni abbastanza bene.
Aggiornamento per le applicazioni Express basate su CoffeeScript (utilizzando connect-assets ):
/app contiene il tuo JavaScript compilato/assets/ contiene tutte le risorse sul lato client che richiedono la compilazione
/assets/js contiene i file CoffeeScript sul lato client/assets/css contiene tutti i fogli di stile MENO / Stilo/public/(js|css|img) contiene i tuoi file statici che non sono gestiti da alcun compilatore/src contiene tutti i file CoffeeScript specifici sul lato server/test contiene tutti gli script di unit test (implementati usando un framework di test a tua scelta)/views contiene tutte le tue opinioni espresse (che siano giada, ejs o qualsiasi altro motore di creazione di modelli)C'è una discussione su GitHub a causa di una domanda simile a questa: https://gist.github.com/1398757
Puoi utilizzare altri progetti come guida, cerca in GitHub:
E infine, in un libro ( http://shop.oreilly.com/product/0636920025344.do ) suggerisce questa struttura:
├── index.html
├── js/
│ ├── main.js
│ ├── models/
│ ├── views/
│ ├── collections/
│ ├── templates/
│ └── libs/
│ ├── backbone/
│ ├── underscore/
│ └── ...
├── css/
└── ...
Più esempi dalla mia architettura di progetto puoi vedere qui:
├── Dockerfile
├── README.md
├── config
│ └── production.json
├── package.json
├── schema
│ ├── create-db.sh
│ ├── db.sql
├── scripts
│ └── deploy-production.sh
├── src
│ ├── app -> Containes API routes
│ ├── db -> DB Models (ORM)
│ └── server.js -> the Server initlializer.
└── test
In sostanza, l'app per la logica è stata separata dalle cartelle DB e APP all'interno della directory SRC.
srco l'app front-end ha una propria cartella (con una package.jsonstruttura di cartelle propria e simile)?
Questa è una risposta indiretta, sulla struttura della cartella stessa, molto correlata.
Qualche anno fa ho avuto la stessa domanda, ho preso una struttura di cartelle ma ho dovuto fare molte directory spostandomi in seguito, perché la cartella era pensata per uno scopo diverso da quello che ho letto su Internet, cioè che cosa ha una particolare cartella significati diversi per persone diverse su alcune cartelle.
Ora, dopo aver realizzato più progetti, oltre alla spiegazione in tutte le altre risposte, sulla struttura della cartella stessa, suggerirei vivamente di seguire la struttura di Node.js stessa, che può essere vista su: https://github.com/ nodejs / node . Ha molti dettagli su tutti, diciamo linters e altri, quale struttura di file e cartelle hanno e dove. Alcune cartelle hanno un file README che spiega cosa c'è in quella cartella.
Iniziare con la struttura sopra è buono perché un giorno entrano in gioco nuovi requisiti, ma avrai un margine di miglioramento in quanto è già seguito da Node.js stesso che viene mantenuto da molti anni.
Spero che questo ti aiuti.
È importante notare che non vi è consenso su quale sia l'approccio migliore e i relativi quadri in generale non impongono né premiano determinate strutture.
Trovo che questo sia un sovraccarico frustrante ed enorme ma ugualmente importante. È una specie di versione minimizzata (ma IMO più importante) del problema della guida di stile . Mi piace evidenziarlo perché la risposta è la stessa: non importa quale struttura usi purché sia ben definita e coerente .
Quindi proporrei di cercare una guida completa che ti piace e chiarire che il progetto si basa su questo.
Non è facile, soprattutto se sei nuovo in questo! Aspettati di passare ore a fare ricerche. Troverai la maggior parte delle guide che raccomandano una struttura simile a MVC. Mentre diversi anni fa quella potrebbe essere stata una scelta solida, al giorno d'oggi non è necessariamente così. Ad esempio, ecco un altro approccio .
Supponendo che stiamo parlando di applicazioni Web e di creazione di API:
Un approccio è quello di classificare i file per funzione , in modo molto simile a come sarebbe un'architettura di micro-servizi. La più grande vittoria a mio avviso è che è super facile vedere quali file si riferiscono a una funzionalità dell'applicazione.
Il modo migliore per illustrare è attraverso un esempio:
Stiamo sviluppando un'applicazione di libreria. Nella prima versione dell'applicazione, un utente può:
In una seconda versione, gli utenti possono anche:
In una terza versione, gli utenti possono anche:
Innanzitutto abbiamo la seguente struttura:
books
├─ controllers
│ ├─ booksController.js
│ └─ authorsController.js
│
└─ entities
├─ book.js
└─ author.js
Aggiungiamo quindi le funzionalità utente e prestito:
user
├─ controllers
│ └─ userController.js
├─ entities
│ └─ user.js
└─ middleware
└─ authentication.js
loan
├─ controllers
│ └─ loanController.js
└─ entities
└─ loan.js
E poi la funzionalità dei preferiti:
favorites
├─ controllers
│ └─ favoritesController.js
└─ entities
└─ favorite.js
Per ogni nuovo sviluppatore a cui viene assegnato il compito di aggiungere che la ricerca di libri dovrebbe anche restituire informazioni se un libro è stato contrassegnato come preferito, è davvero facile vedere dove dovrebbe trovarsi nel codice.
Quindi, quando il proprietario del prodotto esegue la scansione ed esclama che la funzione Preferiti deve essere rimossa completamente, è facile rimuoverla.