UPDATE (2013-10-29) : proszę zobaczyć również moją inną odpowiedź, która ma JavaScript zamiast CoffeeScript według popularnego popytu, a także boilerplate github repo i obszerny README opisujący moje najnowsze zalecenia na ten temat.

Config

#Set the current environment to true in the env object
currentEnv = process.env.NODE_ENV or 'development'
exports.appName = "MyApp"
exports.env =
  production: false
  staging: false
  test: false
  development: false
exports.env[currentEnv] = true
exports.log =
  path: __dirname + "/var/log/app_#{currentEnv}.log"
exports.server =
  port: 9600
  #In staging and production, listen loopback. nginx listens on the network.
  ip: '127.0.0.1'
if currentEnv not in ['production', 'staging']
  exports.enableTests = true
  #Listen on all IPs in dev/test (for testing from other machines)
  exports.server.ip = '0.0.0.0'
exports.db =
  URL: "mongodb://localhost:27017/#{exports.appName.toLowerCase()}_#{currentEnv}"

To jest przyjazne dla edycji sysadmin. Wtedy kiedy potrzebuję czegoś, na przykład informacji o połączeniu DB, to

require('./config').db.URL

Trasy / Kontrolery

Lubię zostawiać swoje trasy za pomocą kontrolerów i organizować je w podkatalogu app/controllers. Potem mogę je załadować i pozwolić im dodać trasy, których potrzebują.

W moim app/server.coffee pliku coffeescript robię:

[
  'api'
  'authorization'
  'authentication'
  'domains'
  'users'
  'stylesheets'
  'javascripts'
  'tests'
  'sales'
].map (controllerName) ->
  controller = require './controllers/' + controllerName
  controller.setup app

Więc mam pliki typu:

app/controllers/api.coffee
app/controllers/authorization.coffee
app/controllers/authentication.coffee
app/controllers/domains.coffee

I np. w moim kontrolerze domen mam funkcję setup jak to.

exports.setup = (app) ->
  controller = new exports.DomainController
  route = '/domains'
  app.post route, controller.create
  app.put route, api.needId
  app.delete route, api.needId
  route = '/domains/:id'
  app.put route, controller.loadDomain, controller.update
  app.del route, controller.loadDomain, exports.delete
  app.get route, controller.loadDomain, (req, res) ->
    res.sendJSON req.domain, status.OK

Views

Umieszczanie widoków w app/views staje się zwyczajowym miejscem. Układam to w ten sposób.

app/views/layout.jade
app/views/about.jade
app/views/user/EditUser.jade
app/views/domain/EditDomain.jade

Pliki Statyczne

Przejdź do podkatalogu public.

Github / Semver / npm

Put a README.md plik markdown w katalogu głównym git repo dla github.

Postaw paczkę.plik json z numerem wersji semantycznej w katalogu głównym git repo dla NPM.

Poniżej znajduje się odpowiedź Petera Lyonsa dosłowna, przeniesiona do vanilla JS z Coffeescript, zgodnie z życzeniem kilku innych. Odpowiedź Piotra jest bardzo zdolna, a każdy głosujący nad moją odpowiedzią powinien głosować również na jego.

Config

// Set the current environment to true in the env object
var currentEnv = process.env.NODE_ENV || 'development';
exports.appName = "MyApp";
exports.env = {
  production: false,
  staging: false,
  test: false,
  development: false
};  
exports.env[currentEnv] = true;
exports.log = {
  path: __dirname + "/var/log/app_#{currentEnv}.log"
};  
exports.server = {
  port: 9600,
  // In staging and production, listen loopback. nginx listens on the network.
  ip: '127.0.0.1'
};  
if (currentEnv != 'production' && currentEnv != 'staging') {
  exports.enableTests = true;
  // Listen on all IPs in dev/test (for testing from other machines)
  exports.server.ip = '0.0.0.0';
};
exports.db {
  URL: "mongodb://localhost:27017/#{exports.appName.toLowerCase()}_#{currentEnv}"
};

To jest przyjazne dla edycji sysadmin. Wtedy, gdy czegoś potrzebuję, podobnie jak DB connection info, jest to

require('./config').db.URL

Trasy / Kontrolery

Lubię zostawiać swoje trasy za pomocą kontrolerów i organizować je w podkatalogu app/controllers. Potem mogę je załadować i pozwolić im dodać trasy, których potrzebują.

W moim app/server.js pliku javascript robię:

[
  'api',
  'authorization',
  'authentication',
  'domains',
  'users',
  'stylesheets',
  'javascripts',
  'tests',
  'sales'
].map(function(controllerName){
  var controller = require('./controllers/' + controllerName);
  controller.setup(app);
});

Więc mam pliki typu:

app/controllers/api.js
app/controllers/authorization.js
app/controllers/authentication.js
app/controllers/domains.js

I np. w moim kontrolerze domen mam funkcję setup jak to.

exports.setup = function(app) {
  var controller = new exports.DomainController();
  var route = '/domains';
  app.post(route, controller.create);
  app.put(route, api.needId);
  app.delete(route, api.needId);
  route = '/domains/:id';
  app.put(route, controller.loadDomain, controller.update);
  app.del(route, controller.loadDomain, function(req, res){
    res.sendJSON(req.domain, status.OK);
  });
}

Views

Umieszczanie widoków w app/views staje się zwyczajowym miejscem. Układam to w ten sposób.

app/views/layout.jade
app/views/about.jade
app/views/user/EditUser.jade
app/views/domain/EditDomain.jade

Pliki Statyczne

Przejdź do podkatalogu public.

Github / Semver / npm

Put a README.md plik markdown w katalogu głównym git repo dla github.

Postaw paczkę.plik json z numerem wersji semantycznej w katalogu głównym git repo dla NPM.

Moje pytanie zostało wprowadzone w kwietniu 2011 roku, jest spokojne stare. W tym czasie mogłem poprawić swoje doświadczenie z Express.js i jak zaprojektować aplikację napisaną przy użyciu tej biblioteki. Dzielę się więc tutaj moim doświadczeniem.

Oto moja struktura katalogów:

├── app.js   // main entry
├── config   // The configuration of my applications (logger, global config, ...)
├── models   // The model data (e.g. Mongoose model)
├── public   // The public directory (client-side code)
├── routes   // The route definitions and implementations
├── services // The standalone services (Database service, Email service, ...)
└── views    // The view rendered by the server to the client (e.g. Jade, EJS, ...)

App.js

Celem pliku app.js jest uruchomienie aplikacji expressjs. Ładuje moduł konfiguracyjny, moduł rejestratora, oczekuje na połączenie z bazą danych, ..., i uruchomić ekspres serwer.

'use strict';
require('./config');
var database = require('./services/database');
var express = require('express');
var app = express();
module.exports = app;

function main() {
  var http = require('http');

  // Configure the application.
  app.configure(function () {
    // ... ... ...
  });
  app.configure('production', function () {
    // ... ... ...
  });
  app.configure('development', function () {
    // ... ... ...
  });

  var server = http.createServer(app);

  // Load all routes.
  require('./routes')(app);

  // Listen on http port.
  server.listen(3000);
}

database.connect(function (err) {
  if (err) { 
    // ...
  }
  main();
});

Trasy /

Katalog routes zawiera plik index.js. Jego celem jest wprowadzenie pewnego rodzaju magii do ładowania wszystkich innych plików wewnątrz katalogu routes/. Oto realizacja:

/**
 * This module loads dynamically all routes modules located in the routes/
 * directory.
 */
'use strict';
var fs = require('fs');
var path = require('path');

module.exports = function (app) {
  fs.readdirSync('./routes').forEach(function (file) {
    // Avoid to read this current file.
    if (file === path.basename(__filename)) { return; }

    // Load the route file.
    require('./' + file)(app);
  });
};

Dzięki temu modułowi tworzenie nowej definicji trasy i implementacja jest naprawdę prosta. Na przykład, hello.js:

function hello(req, res) {
  res.send('Hello world');
}

module.exports = function (app) {
  app.get('/api/hello_world', hello);
};

Każdy moduł trasy jest samodzielny.

Lubię używać globalnej "aplikacji", zamiast eksportować funkcję itp

Myślę, że to świetny sposób, aby to zrobić. Nie ogranicza się do express, ale widziałem sporo węzłów.projekty js na GitHubie robią to samo. Wyjmują parametry konfiguracyjne + mniejsze moduły (w niektórych przypadkach każdy URI) są uwzględniane w osobnych plikach.

Polecam przejrzeć konkretne projekty na GitHubie, aby uzyskać pomysł. IMO sposób w jaki robisz jest poprawny.

Jest teraz koniec 2015 roku{[2] } i po rozwijaniu mojej struktury przez 3 lata oraz w małych i dużych projektach. Wniosek?

Nie rób jednego dużego MVC, ale rozdzielaj go w Moduły

Więc...

Dlaczego?

• Zazwyczaj pracuje się na jednym module (np. produktach), który można zmieniać niezależnie.

• Możesz ponownie wykorzystać Moduły

• Możesz go przetestować oddzielnie

• Jesteś w stanie aby zastąpić go oddzielnie

• Mają przejrzyste (stabilne) interfejsy

  - najpóźniej, jeśli pracowało wielu programistów, separacja modułów pomaga

Projekt nodebootstrap ma podobne podejście do mojej ostatecznej struktury. ( github )

Jak wygląda ta struktura?

1. Małe, otoczkowane Moduły , każdy z osobnym MVC

2. Każdy moduł ma paczka.json

3. Testowanie jako części struktury (w każdym module)

4. Konfiguracja globalna , biblioteki i usługi

5. Integrated Docker, Cluster, forever

Folderoverview (patrz folder lib dla modułów):

Minęło sporo czasu od ostatniej odpowiedzi na to pytanie, A Express również niedawno wydała wersję 4, która dodała kilka przydatnych rzeczy do organizowania struktury aplikacji.

Poniżej znajduje się długi, aktualny wpis na blogu o najlepszych praktykach dotyczących struktury aplikacji Express. http://www.terlici.com/2014/08/25/best-practices-express-structure.html

Istnieje również repozytorium GitHub stosujące porady zawarte w artykule. Jest zawsze na bieżąco z najnowszymi Wersja Express.
https://github.com/terlici/base-express

Nie sądzę, aby dodawanie tras do config było dobrym podejściem. Lepsza struktura może być coś takiego:

application/
| - app.js
| - config.js
| - public/ (assets - js, css, images)
| - views/ (all your views files)
| - libraries/ (you can also call it modules/ or routes/)
    | - users.js
    | - products.js
    | - etc...

Więc produkty.js i użytkowników.js będzie zawierać wszystkie trasy będzie wszystkie logiki wewnątrz.

Cóż, Moje trasy umieszczam jako plik json, który czytałem na początku, i w pętli for w aplikacji.js ustawił trasy. Trasa.json zawiera widok, który ma być wywołany, oraz klucz dla wartości, które zostaną wysłane do trasy.
Działa to w wielu prostych przypadkach, ale musiałem ręcznie utworzyć kilka tras dla specjalnych przypadków.

To może być interesujące:

Https://github.com/flatiron/nconf

Węzeł hierarchiczny.konfiguracja js z plikami, zmiennymi środowiskowymi, argumentami wiersza poleceń i scalaniem obiektów atomowych.

Napisałem post dokładnie na ten temat. W zasadzie korzysta z routeRegistrar, która iteracji poprzez pliki w folderze /controllers wywołując swoją funkcję init. Funkcja init przyjmuje zmienną express app jako parametr, dzięki czemu możesz rejestrować swoje trasy tak, jak chcesz.

var fs = require("fs");
var express = require("express");
var app = express();

var controllersFolderPath = __dirname + "/controllers/";
fs.readdirSync(controllersFolderPath).forEach(function(controllerName){
    if(controllerName.indexOf("Controller.js") !== -1){
        var controller = require(controllersFolderPath + controllerName);
        controller.init(app);
    }
});

app.listen(3000);

1) Twój system plików Express project może wyglądać następująco:

/ ...
/lib
/node_modules
/public
/views
      app.js
      config.json
      package.json

App.js-you global app container

2) Plik główny modułu (lib/mymodule / index."js"): {]}

var express = require('express');    
var app = module.exports = express();
// and load module dependencies ...  

// this place to set module settings
app.set('view engine', 'jade');
app.set('views', __dirname + '/views');

// then do module staff    
app.get('/mymodule/route/',function(req,res){ res.send('module works!') });

3) podłącz moduł w głównej aplikacji.js

...
var mymodule = require('mymodule');
app.use(mymodule);

4) przykładowa logika

lib/login
lib/db
lib/config
lib/users
lib/verify
lib/
   /api/ 
   ...
lib/
   /admin/
      /users/
      /settings/
      /groups/
...

• najlepszy do testowania
• najlepsze dla skali
• Separate depends by module
• grupowanie trasy według funkcjonalności (lub modułów)

TJ mówi / Pokaż na Vimeo ciekawy pomysł jak modularize ekspresowa aplikacja - Modułowe aplikacje internetowe z węzłem.js i Express . Potężny i prosty.

Http://locomotivejs.org / zapewnia sposób na strukturę aplikacji zbudowanej z węzła.js i Express.

Ze strony:

"Locomotive to web framework dla Node.js. Lokomotywa obsługuje MVC wzorców, tras RESTful i konwencji nad konfiguracją, podczas gdy bezproblemowa integracja z dowolnym silnikiem bazy danych i szablonów. Lokomotywa opiera się na Express, zachowując moc i prostotę oczekujesz od Node."

Podaję strukturę folderów w stylu MVC, proszę znaleźć poniżej .

Użyliśmy poniżej struktury folderów dla naszych dużych i średnich aplikacji internetowych .

 myapp   
|
|
|____app
|      |____controllers
|      |    |____home.js
|      |
|      |____models
|      |     |___home.js
|      |
|      |____views
|           |___404.ejs
|           |___error.ejs
|           |___index.ejs
|           |___login.ejs
|           |___signup.ejs
|   
|
|_____config
|     |___auth.js
|     |___constants.js
|     |___database.js
|     |___passport.js
|     |___routes.js
|
|
|____lib
|    |___email.js
|
|____node_modules
|
|
|____public.js
|    |____css
|    |    |__style.css
|    |    
|    |____js
|    |    |__script.js
|    |
|    |____img
|    |    |__img.jpg
|    |
|    |
|    |____uploads
|         |__img.jpg
|      
|   
|
|_____app.js
|
|
|
|_____package.json

Stworzyłem jeden moduł npm dla generation express mvc folder structurer.

Proszę znaleźć poniżej https://www.npmjs.com/package/express-mvc-generator

Proste kroki do wygenerowania i wykorzystania tych modułów .

I) install module npm install express-mvc-generator -g

Ii) sprawdź opcje express -h

Iii) Generowanie struktury express mvc express myapp

Iv) instalowanie zależności: npm install:

V)otwórz konfigurację/bazę danych.js, proszę skonfigurować mongo db.

Vi) Uruchom aplikację node app lub nodemon app

Vii) Sprawdź URL http://localhost:8042/signup lub http://yourip:8042/signup

Ostatnio przyjęłam Moduły jako niezależne mini-aplikacje.

|-- src
  |--module1
  |--module2
     |--www
       |--img
       |--js
       |--css
     |--#.js
     |--index.ejs
  |--module3
  |--www
     |--bower_components
     |--img
     |--js
     |--css
  |--#.js
  |--header.ejs
  |--index.ejs
  |--footer.ejs

Teraz dla dowolnego modułu (#.js), widoki (*.ejs), js, css i zasoby są obok siebie. routing podmodułów jest ustawiony w rodzicu #.js z dwoma dodatkowymi liniami

router.use('/module2', opt_middleware_check, require('./module2/#'));
router.use(express.static(path.join(__dirname, 'www')));

W ten sposób możliwe są nawet submodule.

Nie zapomnij ustawić widoku w katalogu src

app.set('views', path.join(__dirname, 'src'));

Tak wygląda większość struktury mojego projektu express.

Zazwyczaj robię express dirname, aby zainicjować projekt, wybacz moje lenistwo, ale jest bardzo elastyczny i rozszerzalny. PS-musisz za to dostać express-generator (dla tych którzy go szukają sudo npm install -g express-generator, sudo bo instalujesz go globalnie)

|-- bin
    |-- www //what we start with "forever"
|-- bower_components
|-- models
    |-- database.js
    |-- model1.js //not this exact name ofcourse.
    |-- .
|-- node_modules
|-- public
    |-- images
    |-- javascripts
        |-- controllers
        |-- directives
        |-- services
        |-- app.js
        |-- init.js //contains config and used for initializing everything, I work with angular a lot.
    |-- stylesheets
|-- routes
    |-- some
    |-- hierarchy
    .
    .
|-- views
    |-- partials
    |-- content
|-- .env
|-- .env.template
|-- app.js
|-- README.md

var dotenv = require('dotenv');
dotenv.config({path: path.join(__dirname + "/.env")});

I kolejny wiersz do szybkiego ustawienia /bower_components do serwowania statycznej zawartości pod zasobem /ext

app.use('/ext', express.static(path.join(__dirname, 'bower_components')));

Prawdopodobnie może być odpowiedni dla osób, które chcą używać Express i Angular razem, lub po prostu express bez tej hierarchii javascripts oczywiście.

Moja struktura express 4. https://github.com/odirleiborgert/borgert-express-boilerplate

Pakiety

View engine: twig
Security: helmet
Flash: express-flash
Session: express-session
Encrypt: bcryptjs
Modules: express-load
Database: MongoDB
    ORM: Mongoose
    Mongoose Paginate
    Mongoose Validator
Logs: winston + winston-daily-rotate-file
Nodemon
CSS: stylus
Eslint + Husky

Struktura

|-- app
    |-- controllers
    |-- helpers
    |-- middlewares
    |-- models
    |-- routes
    |-- services
|-- bin
|-- logs
|-- node_modules
|-- public
    |-- components
    |-- images
    |-- javascripts
    |-- stylesheets
|-- views
|-- .env
|-- .env-example
|-- app.js
|-- README.md