express.js, définition de la route, l'emplacement du contrôleur et de documentation api

Question

Utilisation express.js 4.X avec NodeJS 6.x

je mes itinéraires déjà en train de définir ainsi:

/** 
* @api {get} /users/:userId Get a user 
* @apiName GetUser 
* @apiGroup User 
* 
* @apiParam {Integer} userId Users unique ID. 
* 
* @apiSuccess (Success 201) {text} User email 
* @apiError {text} 401/Unauthorized. 
* @apiError {text} 404/Not Foud Unknown userId 
*/ 
router.get('/users/:userId', function(req, res, next) { 
    const userId = req.params.userId; 
    //get user 
    res.json(user); 
} 

Je l'ai trouvé était la bonne façon de le faire parce que:

• Vous écrivez la documentation de l'itinéraire ci-dessus la définition de l'itinéraire
  • Si vous modifiez la route, vous modifiez la documentation
• Vous avez la documentation d'itinéraire au-dessus de votre contrôleur
  • params/contenu du corps URL (req.params.name // de req.body.name)
  • code d'erreur HTTP pour revenir
  • IDE comme WebStorm pour utiliser ces commentaires autocomplétion

Vous cherchez des meilleures pratiques, on m'a dit plusieurs fois que je devrais créer un contrôleur et faire ailleurs la route défintion, se terminant par le code suivant:

class UserController { 
    constructor() { 
     this.listAll = this.listAll.bind(this); 
    } 
    getUser(req, res, next) { 
     const userId = req.params.userId; 
     //get user... 
     res.json(user); 
    } 
} 
router.get('/users/, UserController.getUser); 

La seule bonne raison que je vois avec cette façon d'organiser votre code est que si vous avez 2 routes faisant la même chose, vous pouvez les faire utiliser le même contrôleur.

• Devrais-je continuer à séparer mon contrôleur & mes itinéraires?
• Si oui, comment dois-je le documenter?
• Quels sont les avantages d'une telle organisation de code?

Answer 1

Bit d'une question philosophique qui devrait être posée plutôt sur la page http://programmers.stackexchange.com. Mais en tout cas ...

Mon approche personnelle lorsque j'utilise un framework est de suivre le style du framework lui-même, et ne jamais changer le style de codage. Pour moi, c'est important surtout si je travaille avec d'autres développeurs.

Supposons que vous souhaitiez amener quelqu'un de nouveau dans l'équipe. Vous ne pouvez plus exiger d'expérience ExpressJS puisque vous modifiez la façon dont le code est structuré. Cela signifie que vous devrez vous asseoir avec la nouvelle personne et expliquer le style de codage différent.

Une autre chose est que de tout transformer en classe est une exagération. C'est une couche supplémentaire de complexité inutile, que vous et d'autres devrez contourner. En outre, vous n'utiliserez pas les avantages de la classe dans ce cas.

Si c'était moi, je garderais le style de codage comme ExpressJS l'avait prévu, et aussi simple que possible :). Commentaires? Chaque itinéraire avec une bonne explication comme ceci par exemple:

/** 
* Nice description 
* 
* @param {string} var-name description 
* @param {int} var-name description 
*/