mise à jour (2013-10-29) : s'il vous plaît voir mon autre réponse ainsi que qui a JavaScript au lieu de CoffeeScript par la demande populaire ainsi que d'un boilerplate GitHub repo et un README détaillé de mes dernières recommandations sur ce sujet.

Config

ce que vous faites est très bien. J'aime avoir mon propre namespace de configuration installé dans un fichier config.coffee de haut niveau avec un emboîtement espace de noms comme ça.

#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}"

c'est convivial pour l'édition sysadmin. Puis quand j'ai besoin de quelque chose, comme les informations de connexion DB, c'est

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

Routes/Contrôleurs

j'aime bien laisser mes routes avec mes contrôleurs et les organiser dans un sous-répertoire app/controllers . Alors je peux les charger et les laisser ajouter toutes les routes dont ils ont besoin.

dans mon app/server.coffee coffeescript fichier je fais:

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

donc j'ai des fichiers comme:

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

et par exemple dans mon contrôleur de domaines, j'ai une fonction setup comme celle-ci.

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

vues

Mettre des points de vue dans app/views est en train de devenir le coutumier. Je la donne comme ceci.

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

statique Fichiers

Aller dans un public sous-répertoire.

Github / Semver/NPM

mettez un README.md markdown file à la racine de votre compte rendu git pour github.

mettre un paquet.fichier json avec un "1519550920 sémantique" version le nombre dans votre repo git racine de MNP.

est Peter Lyons réponse mot à mot, porté sur vanilla JS de Coffeescript, comme demandé par plusieurs autres. La réponse de Peter est très compétente, et quiconque votera sur ma réponse devrait aussi voter sur la sienne.

Config

ce que vous faites est très bien. J'aime avoir mon propre namespace de configuration dans un fichier config.js de haut niveau avec un namespace imbriqué comme celui-ci.

// 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}"
};

c'est convivial pour l'édition sysadmin. Puis quand j'ai besoin de quelque chose, comme les informations de connexion DB, c'est

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

Routes/Contrôleurs

j'aime bien laisser mes routes avec mes contrôleurs et les organiser dans un sous-répertoire app/controllers . Alors je peux les charger et les laisser ajouter toutes les routes dont ils ont besoin.

dans mon fichier javascript app/server.js Je fais:

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

donc j'ai des fichiers comme:

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

et par exemple dans mon contrôleur de domaines, j'ai une fonction setup comme celle-ci.

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);
  });
}

vues

Mettre des points de vue dans app/views est en train de devenir le coutumier. Je la donne comme ceci.

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

Fichiers Statiques

Aller dans un public sous-répertoire.

Github / Semver/NPM

mettez un README.md markdown file à la racine de votre compte rendu git pour github.

mettre un paquet.fichier json avec un "1519550920 sémantique" version le nombre dans votre repo git racine de MNP.

ma question a été introduite en avril 2011, il est calme vieux. Pendant ce temps, je pourrais améliorer mon expérience avec Express.js et comment l'architecture d'une application écrite en utilisant cette bibliothèque. Donc, je partage ici mon expérience.

Voici la structure de mon répertoire:

├── 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

le but du fichier app.js est de bootstrap l'application expressjs. Il charge le module de configuration, le module logger, attendre la connexion à la base de données, ..., et exécutez le serveur express.

'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();
});

routes /

le répertoire des routes contient un fichier index.js . Son but est d'introduire une sorte de magie pour charger tous les autres fichiers à l'intérieur du répertoire routes/ . Voici la mise en œuvre:

/**
 * 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);
  });
};

avec ce module, la création d'une nouvelle définition de route et la mise en œuvre est vraiment facile. Pour exemples, hello.js :

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

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

chaque module de route est autonome .

, je tiens à utiliser une "app", plutôt que d'exporter une fonction etc

je pense que c'est une excellente façon de le faire. Pas limité à exprimer, mais j'ai vu un certain nombre de nœud.js projette sur github de faire la même chose. Ils prennent les paramètres de configuration + modules plus petits (dans certains cas chaque URI) sont pris en compte dans des fichiers séparés.

je vous recommande de passer par des projets spécifiques sur GitHub pour avoir une idée. IMO la façon dont vous faites est correcte.

il est maintenant fin de 2015 et après avoir développé ma structure pendant 3 ans et dans les petits et grands projets. Conclusion?

ne pas faire un grand MVC, mais le séparer dans les modules

So...

pourquoi?

• habituellement, on travaille sur un module (par exemple des produits), que vous pouvez changer indépendamment.

• vous pouvez réutiliser les modules

• Vous êtes en mesure de tester séparément

• Vous êtes en mesure de remplacer séparément

• ils ont des interfaces claires (stables)

  - au plus tard, s'il y avait plusieurs développeurs travaillant, la séparation des modules aide

le projet nodebootstrap a une approche similaire à ma structure finale. ( github )

à quoi ressemble cette structure?

1. petits modules capsulés , chacun avec MVC séparé

2. chaque module comporte un colis.json

3. Test comme une partie de la structure (dans chaque module)

4. configuration Globale , de bibliothèques et de Services

5. Docker intégré, Cluster, pour toujours

Folderoverview (voir le dossier lib pour les modules):

Cela fait longtemps que la dernière réponse à cette question et Express a également récemment publié la version 4, qui a ajouté quelques choses utiles pour organiser la structure de votre application.

ci-dessous est un billet de blog à jour sur les meilleures pratiques sur la façon de structurer votre application Express. http://www.terlici.com/2014/08/25/best-practices-express-structure.html

il y a aussi un dépôt GitHub qui applique les conseils article. Il est toujours à jour avec la dernière version Express.

https://github.com/terlici/base-express

Je ne pense pas que ce soit une bonne approche d'ajouter des routes à config. Une meilleure structure pourrait être quelque chose comme ceci:

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...

Ainsi les produits.js et les utilisateurs.js contiendra toutes vos routes sera toute la logique à l'intérieur.

Eh bien j'ai mis mes routes comme un fichier json, que j'ai lu au début, et dans une boucle-for Dans app.js a établi les routes. Route.json inclut la vue qui doit être appelée, et la clé pour les valeurs qui seront envoyés dans la route.

Cela fonctionne pour beaucoup de cas simples, mais j'ai dû créer manuellement quelques routes pour des cas spéciaux.

cela peut être intéressant:

https://github.com/flatiron/nconf

noeud hiérarchique.configuration de js avec fichiers, variables d'environnement, arguments en ligne de commande et fusion d'objets atomiques.

j'ai écrit un billet sur cette affaire. Il utilise essentiellement un routeRegistrar qui itère à travers les fichiers du dossier /controllers appelant sa fonction init . La fonction init prend la variable app comme paramètre pour que vous puissiez enregistrer vos routes comme vous le souhaitez.

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) votre système de fichiers Express project peut-être comme:

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

app.js - vous mondial de l'app container

2) Module principal (fichier 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) Connecter le module dans l'application principale.js

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

4) logique de L'échantillon

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

• test
• échelle
• Separate dépend du module
• groupage route par fonctionnalité (ou modules)

tj , dit - /afficher sur Vimeo intéressante idée de comment modulariser demande expresse - Modulaire d'applications web avec un Nœud.js et Express . Puissant et simple.

http://locomotivejs.org / fournit un moyen de structurer une application construite avec un noeud.js et Express.

à Partir du site web:

" Locomotive est un cadre web pour le noeud.js. Supports de Locomotive MVC les modèles, les routes reposantes, et la convention sur la configuration, tandis que intégration transparente avec n'importe quelle base de données et moteur de modèle. Locomotive construit sur Express, en préservant la puissance et la simplicité vous avez venus à attendre de Nœud."

je donne la structure de dossier de style MVC s'il vous plaît trouver ci-dessous .

nous avons utilisé la structure de dossier de bellow pour nos applications web grandes et moyennes .

 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

j'ai créé un module npm pour le structureur de dossier MVC generation express.

s'il vous Plaît trouver le soufflet https://www.npmjs.com/package/express-mvc-generator

simples étapes pour générer et utiliser ce module.

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

ii) cocher les options express -h

iii) Générer express structure mvc express myapp

iv) dépendances D'installation: npm install :

v) ouvrez votre configuration/base de données.js, veuillez configurer votre Mongo db.

vi) exécuter l'application node app ou nodemon app

vii) vérifier L'URL http://localhost:8042/signup ou http://yourip:8042/signup

j'ai récemment adopté les modules comme mini-applications indépendantes.

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

maintenant pour tout routage de module (#.js), vues (*.ejs), js, css et assets sont côte à côte. le routage des sous-modules est configuré dans le #parent.js avec deux lignes supplémentaires

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

ainsi, même des sous-modules sont possibles.

n'oubliez pas de définir view au répertoire src

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

voici à quoi ressemble la structure de mon répertoire express project.

je fais habituellement un express dirname pour initialiser le projet, pardonnez Ma paresse, mais il est très souple et extensible. PS - vous devez obtenir express-generator pour cela (pour ceux qui le cherchent sudo npm install -g express-generator , sudo parce que vous l'installez dans le monde entier)

|-- 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

Vous devez vous demander pourquoi .des dossiers env? Parce qu'ils travaillent! J'utilise le module dotenv dans mon projets (beaucoup récemment) et ça marche! Pop dans ces 2 énoncés dans app.js ou www

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

et une autre ligne pour définir rapidement /bower_components pour servir le contenu statique sous la ressource /ext

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

il peut probablement être un ajustement pour les gens qui cherchent à utiliser Express et Angular ensemble, ou tout simplement express sans que javascripts hiérarchie bien sûr.

Ma structure express 4. https://github.com/odirleiborgert/borgert-express-boilerplate

colis

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

Structure

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