Ich verwende das ExpressJS-Webframework für NodeJS.
Benutzer von ExpressJS stellen ihre Umgebungen (Entwicklung, Produktion, Test ...), ihre Routen usw. auf die app.js
. Ich denke, dass es kein schöner Weg ist, denn wenn Sie eine große Anwendung haben, ist app.js zu groß!
Ich möchte diese Verzeichnisstruktur haben:
| my-application
| -- app.js
| -- config/
| -- environment.js
| -- routes.js
Hier ist mein Code:
app.js.
var express = require('express');
var app = module.exports = express.createServer();
require('./config/environment.js')(app, express);
require('./config/routes.js')(app);
app.listen(3000);
config / environment.js
module.exports = function(app, express){
app.configure(function() {
app.use(express.logger());
});
app.configure('development', function() {
app.use(express.errorHandler({
dumpExceptions: true,
showStack: true
}));
});
app.configure('production', function() {
app.use(express.errorHandler());
});
};
config / route.js
module.exports = function(app) {
app.get('/', function(req, res) {
res.send('Hello world !');
});
};
Mein Code funktioniert gut und ich finde die Struktur der Verzeichnisse wunderschön. Der Code musste jedoch angepasst werden und ich bin mir nicht sicher, ob er gut / schön ist.
Ist es besser, meine Verzeichnisstruktur zu verwenden und den Code anzupassen oder einfach eine Datei (app.js) zu verwenden?
Vielen Dank für Ihre Ratschläge!
Antworten:
OK, es ist eine Weile her und dies ist eine beliebte Frage. Deshalb habe ich ein Gerüst-Github-Repository mit JavaScript-Code und einer langen README-Datei erstellt, in der erläutert wird, wie ich eine mittelgroße express.js-Anwendung strukturieren möchte.
focusaurus / express_code_structure ist das Repo mit dem neuesten Code dafür. Pull-Anfragen willkommen.
Hier ist eine Momentaufnahme der README-Datei, da der Stackoverflow keine Nur-Link-Antworten mag. Ich werde einige Updates vornehmen, da dies ein neues Projekt ist, das ich weiter aktualisieren werde, aber letztendlich wird das Github-Repo der aktuelle Ort für diese Informationen sein.
Express-Codestruktur
Dieses Projekt ist ein Beispiel für die Organisation einer mittelgroßen Webanwendung von express.js.
Aktuell, um mindestens v4.14 Dezember 2016 auszudrücken
Wie groß ist Ihre Bewerbung?
Webanwendungen sind nicht alle gleich, und meiner Meinung nach gibt es keine einzige Codestruktur, die auf alle express.js-Anwendungen angewendet werden sollte.
Wenn Ihre Anwendung klein ist, benötigen Sie keine so tiefe Verzeichnisstruktur wie hier dargestellt. Halten Sie es einfach und stecken Sie eine Handvoll
.js
Dateien in das Stammverzeichnis Ihres Repositorys, und schon sind Sie fertig. Voilà.Wenn Ihre Anwendung sehr umfangreich ist, müssen Sie sie irgendwann in verschiedene npm-Pakete aufteilen. Im Allgemeinen scheint der Ansatz von node.js viele kleine Pakete zu bevorzugen, zumindest für Bibliotheken, und Sie sollten Ihre Anwendung mithilfe mehrerer npm-Pakete aufbauen, da dies sinnvoll ist und den Overhead rechtfertigt. Wenn Ihre Anwendung wächst und ein Teil des Codes außerhalb Ihrer Anwendung eindeutig wiederverwendbar wird oder ein klares Subsystem ist, verschieben Sie ihn in das eigene Git-Repository und machen Sie ihn zu einem eigenständigen npm-Paket.
So im Mittelpunkt dieses Projektes ist es, eine tragfähige Struktur für eine mittelgroße Anwendung zu illustrieren.
Was ist Ihre Gesamtarchitektur?
Es gibt viele Ansätze zum Erstellen einer Webanwendung, z
Jedes davon passt gut in eine andere Verzeichnisstruktur. In diesem Beispiel handelt es sich nur um ein Gerüst und nicht um eine voll funktionsfähige App. Ich gehe jedoch von den folgenden wichtigen Architekturpunkten aus:
Und was ist mit Ruby on Rails?
Während des gesamten Projekts wird es ein Thema sein, dass viele der in Ruby on Rails und den von ihnen getroffenen Entscheidungen zum "Übereinkommen über die Konfiguration" enthaltenen Ideen, obwohl sie weithin akzeptiert und verwendet werden, nicht wirklich sehr hilfreich sind und manchmal das Gegenteil von dem sind, was dieses Repository darstellt empfiehlt.
Mein Hauptpunkt hier ist, dass der Organisation von Code grundlegende Prinzipien zugrunde liegen. Basierend auf diesen Prinzipien sind die Ruby on Rails-Konventionen (meistens) für die Ruby on Rails-Community sinnvoll. Nur gedankenlos diese Konventionen nachzuahmen, geht jedoch daneben. Sobald Sie die Grundprinzipien verstanden haben, sind ALLE Ihre Projekte gut organisiert und klar: Shell-Skripte, Spiele, mobile Apps, Unternehmensprojekte und sogar Ihr Home-Verzeichnis.
Für die Rails-Community möchten sie, dass ein einzelner Rails-Entwickler von App zu App zu App wechselt und jedes Mal damit vertraut und vertraut ist. Dies ist sehr sinnvoll, wenn Sie 37 Signale oder Pivotal Labs sind, und hat Vorteile. In der serverseitigen JavaScript-Welt ist das allgemeine Ethos einfach viel wilder im Westen, und wir haben damit kein wirkliches Problem. Das ist unsere Art. Wir sind daran gewöhnt. Selbst innerhalb von express.js ist es eine enge Verwandtschaft von Sinatra, nicht von Rails, und Konventionen von Rails zu übernehmen, hilft normalerweise nichts. Ich würde sogar Prinzipien über Konvention über Konfiguration sagen .
Grundprinzipien und Motivationen
app/node_modules
Verzeichnis und habenpackage.json
Dateien in den Proto-Modul Verzeichnissen , dass der Übergang zu erleichtern und als Erinnerung dienen.app
Verzeichnis, sodass Siecd
dort find / grep / xargs / ag / ack / etc ausführen können und sich nicht von Übereinstimmungen mit Drittanbietern ablenken lassenkebab-case
, obwohl der Variablenname dafür in JavaScript sein muss,camelCase
weil-
es in JavaScript ein Minuszeichen ist.kebab-case
transformiert incamelCase
app/views
,app/controllers
,app/models
usw.routes.rb
Datei im Rails-Stil ist praktisch, wenn Sie einen Überblick über alle Routen in der App wünschen. Wenn Sie jedoch Funktionen erstellen und Fehler beheben, kümmern Sie sich nur um die Routen, die für das zu ändernde Teil relevant sind.app/users
da nicht überall ein Rattennest gekoppelter Geschäftslogik vorhanden ist, das die Reinheit der Benutzercodebasis verschmutzt.app/server.js:1
und Sie können alles sehen, was sie lädt und ausführt, indem Sie dem Code folgen.magicRESTRouter.route(somecontroller, {except: 'POST'})
ist ein großer Gewinn für Sie über 3 Grundapp.get
,app.put
,app.del
, Anrufe, sind Sie wahrscheinlich ein monolithisches App bauen , die zu groß ist , effektiv zu arbeiten. Lust auf GROSSE Gewinne, nicht darauf, 3 einfache Zeilen in 1 komplexe Zeile umzuwandeln.Verwenden Sie Dateinamen in Kleinbuchstaben
express.js Besonderheiten
Nicht benutzen
app.configure
. Es ist fast völlig nutzlos und du brauchst es einfach nicht. Es ist in vielen Kesselplatten wegen sinnloser Copypasta.app.use
für Ihre gesamte Anwendung, wenn Sie diese Middleware wirklich nur für zwei Routen benötigen (ich sehe Sie anbody-parser
).server.js
und es klar ist, wie sie bestellt werden. Für eine mittelgroße Anwendung ist es schön, Dinge in separate Routenmodule aufzuteilen, aber es besteht die Gefahr, dass Middleware nicht in Ordnung istDer App-Symlink-Trick
Es gibt viele Ansätze skizziert und ausführlich von der Gemeinschaft in dem großen Kern diskutiert bessere lokale require () Pfade für Node.js . Ich könnte mich bald dafür entscheiden, entweder "nur mit vielen ../../../ .. umzugehen" oder das requireFrom- Modul zu verwenden. Im Moment habe ich jedoch den unten beschriebenen Symlink-Trick verwendet.
Ein Weg, um projektinterne Anforderungen mit lästigen relativen Pfaden wie zu vermeiden,
require("../../../config")
besteht darin, den folgenden Trick zu verwenden:.gitignore
Datei habenvar config = require("app/config");
var DealModel = require("app/deals/deal-model")
;;Aufbau
Im Allgemeinen erwarten Codemodule und Klassen nur ein übergebenes grundlegendes JavaScript-
options
Objekt. Nurapp/server.js
dasapp/config.js
Modul sollte geladen werden. Von dort aus können kleineoptions
Objekte synthetisiert werden, um Subsysteme nach Bedarf zu konfigurieren. Die Kopplung jedes Subsystems an ein großes globales Konfigurationsmodul mit zusätzlichen Informationen ist jedoch eine schlechte Kopplung.Versuchen Sie, die Erstellung von DB-Verbindungen zu zentralisieren und diese an Subsysteme zu übergeben, anstatt Verbindungsparameter zu übergeben und Subsysteme selbst ausgehende Verbindungen herstellen zu lassen.
NODE_ENV
Dies ist eine weitere verlockende, aber schreckliche Idee, die von Rails übernommen wurde. Es sollte genau 1 Stelle in Ihrer App sein,
app/config.js
die dieNODE_ENV
Umgebungsvariable betrachtet. Alles andere sollte eine explizite Option als Klassenkonstruktorargument oder Modulkonfigurationsparameter annehmen.Wenn das E-Mail-Modul eine Option zum Zustellen von E-Mails hat (SMTP, Protokollieren bei stdout, Einfügen in die Warteschlange usw.), sollte es eine Option wie diese verwenden
{deliver: 'stdout'}
, diese sollte jedoch absolut nicht überprüft werdenNODE_ENV
.Tests
Ich behalte meine Testdateien jetzt im selben Verzeichnis wie der entsprechende Code und verwende Namenskonventionen für Dateinamenerweiterungen, um Tests von Produktionscode zu unterscheiden.
foo.js
hat den Code des Moduls "foo"foo.tape.js
hat die knotenbasierten Tests für foo und lebt im selben Verzeichnisfoo.btape.js
kann für Tests verwendet werden, die in einer Browserumgebung ausgeführt werden müssenIch verwende Dateisystem-Globs und den
find . -name '*.tape.js'
Befehl, um bei Bedarf auf alle meine Tests zuzugreifen.So organisieren Sie Code in jeder
.js
ModuldateiIn diesem Projekt geht es hauptsächlich darum, wohin Dateien und Verzeichnisse gehen, und ich möchte nicht viel mehr hinzufügen, aber ich möchte nur erwähnen, dass ich meinen Code in drei verschiedene Abschnitte gegliedert habe.
quelle
UPDATE (29.10.2013) : Bitte beachten Sie auch meine andere Antwort, die auf vielfachen Wunsch JavaScript anstelle von CoffeeScript enthält, sowie ein Github-Repo mit Boilerplate und eine ausführliche README-Datei mit meinen neuesten Empfehlungen zu diesem Thema.
Konfig
Was Sie tun, ist in Ordnung. Ich möchte meinen eigenen Konfigurations-Namespace in einer
config.coffee
Datei der obersten Ebene mit einem verschachtelten Namespace wie diesem einrichten .Dies ist für die Bearbeitung von Systemadministratoren geeignet. Wenn ich dann etwas brauche, wie die DB-Verbindungsinformationen, ist es
Routen / Controller
Ich lasse meine Routen gerne bei meinen Controllern und organisiere sie in einem
app/controllers
Unterverzeichnis. Dann kann ich sie laden und sie die Routen hinzufügen lassen, die sie benötigen.In meiner
app/server.coffee
Coffeescript-Datei mache ich:Also habe ich Dateien wie:
Und zum Beispiel habe ich in meinem Domänencontroller eine solche
setup
Funktion.Ansichten
Das Einfügen von Ansichten
app/views
wird zum üblichen Ort. Ich lege es so aus.Statische Dateien
Gehen Sie in ein
public
Unterverzeichnis.Github / Semver / NPM
Legen Sie eine README.md-Markdown-Datei in Ihrem Git-Repo-Stammverzeichnis für Github ab.
Fügen Sie eine package.json-Datei mit einer semantischen Versionsnummer in Ihr Git-Repo-Stammverzeichnis für NPM ein.
quelle
app.put route, api.needId
Go
diebin
Datei bereits installiert und in die Struktur aufgenommen. Wie führen Sie diesego
Datei ausbin
?Das Folgende ist die wörtliche Antwort von Peter Lyons, die von Coffeescript auf Vanilla JS übertragen wurde, wie von mehreren anderen angefordert. Peters Antwort ist sehr fähig, und jeder, der über meine Antwort abstimmt, sollte auch über seine abstimmen.
Konfig
Was Sie tun, ist in Ordnung. Ich möchte meinen eigenen Konfigurations-Namespace in einer
config.js
Datei der obersten Ebene mit einem verschachtelten Namespace wie diesem einrichten .Dies ist für die Bearbeitung von Systemadministratoren geeignet. Wenn ich dann etwas brauche, wie die DB-Verbindungsinformationen, ist es
Routen / Controller
Ich lasse meine Routen gerne bei meinen Controllern und organisiere sie in einem
app/controllers
Unterverzeichnis. Dann kann ich sie laden und sie die Routen hinzufügen lassen, die sie benötigen.In meiner
app/server.js
Javascript-Datei mache ich:Also habe ich Dateien wie:
Und zum Beispiel habe ich in meinem Domänencontroller eine solche
setup
Funktion.Ansichten
Das Einfügen von Ansichten
app/views
wird zum üblichen Ort. Ich lege es so aus.Statische Dateien
Gehen Sie in ein
public
Unterverzeichnis.Github / Semver / NPM
Legen Sie eine README.md-Markdown-Datei in Ihrem Git-Repo-Stammverzeichnis für Github ab.
Fügen Sie eine package.json-Datei mit einer semantischen Versionsnummer in Ihr Git-Repo-Stammverzeichnis für NPM ein.
quelle
Meine Frage wurde im April 2011 gestellt, sie ist ziemlich alt. Während dieser Zeit konnte ich meine Erfahrung mit Express.js und die Architektur einer mit dieser Bibliothek geschriebenen Anwendung verbessern. Also teile ich hier meine Erfahrungen.
Hier ist meine Verzeichnisstruktur:
App.js.
Das Ziel der
app.js
Datei ist es, die expressjs-Anwendung zu booten. Es lädt das Konfigurationsmodul, das Logger-Modul, wartet auf die Datenbankverbindung, ... und führt den Express-Server aus.Routen /
Das Routenverzeichnis enthält eine
index.js
Datei. Ziel ist es, eine Art Magie einzuführen, um alle anderen Dateien in dasroutes/
Verzeichnis zu laden . Hier ist die Implementierung:Mit diesem Modul ist das Erstellen einer neuen Routendefinition und -implementierung wirklich einfach. Zum Beispiel
hello.js
:Jedes Routenmodul ist eigenständig .
quelle
Ich verwende gerne eine globale "App", anstatt eine Funktion usw. Zu exportieren
quelle
Ich denke, es ist eine großartige Möglichkeit, dies zu tun. Nicht auf Express beschränkt, aber ich habe eine ganze Reihe von node.js-Projekten auf github gesehen, die dasselbe tun. Sie nehmen die Konfigurationsparameter heraus + kleinere Module (in einigen Fällen jeder URI) werden in separaten Dateien berücksichtigt.
Ich würde empfehlen, Express-spezifische Projekte auf Github durchzugehen, um sich ein Bild zu machen. IMO ist die Art und Weise, wie Sie es tun, richtig.
quelle
Es ist jetzt Ende 2015 und nachdem ich meine Struktur für 3 Jahre und in kleinen und großen Projekten entwickelt habe. Fazit?
Führen Sie keine große MVC durch, sondern trennen Sie sie in Module
Damit...
Warum?
Normalerweise arbeitet man an einem Modul (zB Produkte), das Sie unabhängig voneinander ändern können.
Sie können Module wiederverwenden
Sie können es separat testen
Sie können es separat ersetzen
Sie haben klare (stabile) Schnittstellen
- Spätestens wenn mehrere Entwickler arbeiten, hilft die Modultrennung
Das Nodebootstrap- Projekt hat einen ähnlichen Ansatz wie meine endgültige Struktur. ( Github )
Wie sieht diese Struktur aus?
Kleine, gekapselte Module mit jeweils separatem MVC
Jedes Modul hat eine package.json
Testen als Teil der Struktur (in jedem Modul)
Globale Konfiguration , Bibliotheken und Dienste
Integrierter Docker, Cluster, für immer
Ordnerübersicht (Module siehe lib-Ordner):
quelle
Ich gebe MVC-Stil Ordnerstruktur finden Sie unten.
Wir haben für unsere großen und mittleren Webanwendungen die folgende Ordnerstruktur verwendet.
Ich habe ein npm-Modul für die Generierung von Express-MVC-Ordner-Strukturierern erstellt.
Den folgenden https://www.npmjs.com/package/express-mvc-generator finden Sie unten
Nur einfache Schritte zum Generieren und Verwenden dieser Module.
i) Modul installieren
npm install express-mvc-generator -g
ii) Optionen prüfen
express -h
iii) Generieren Sie eine Express-MVC-Struktur
express myapp
iv) Installieren Abhängigkeiten:
npm install
:v) Öffnen Sie Ihre config / database.js. Bitte konfigurieren Sie Ihre Mongo-Datenbank.
vi) Führen Sie die Anwendung aus
node app
odernodemon app
vii) Überprüfen Sie die URL http: // localhost: 8042 / signup ODER http: // yourip: 8042 / signup
quelle
Seit der letzten Antwort auf diese Frage ist eine Weile vergangen, und Express hat kürzlich auch Version 4 veröffentlicht, die einige nützliche Dinge für die Organisation Ihrer App-Struktur enthält.
Im Folgenden finden Sie einen langen, aktuellen Blog-Beitrag über bewährte Methoden zur Strukturierung Ihrer Express-App. http://www.terlici.com/2014/08/25/best-practices-express-structure.html
Es gibt auch ein GitHub-Repository, das die Hinweise im Artikel anwendet. Es ist immer auf dem neuesten Stand der Express-Version.
https://github.com/terlici/base-express
quelle
Ich denke nicht, dass es ein guter Ansatz ist, Routen zur Konfiguration hinzuzufügen. Eine bessere Struktur könnte ungefähr so aussehen:
So enthalten products.js und users.js alle Ihre Routen und die gesamte Logik.
quelle
Nun, ich habe meine Routen als JSON-Datei abgelegt, die ich am Anfang gelesen habe, und in einer for-Schleife in app.js die Routen eingerichtet. Die route.json enthält die Ansicht, die aufgerufen werden soll, und den Schlüssel für die Werte, die an die Route gesendet werden.
Dies funktioniert in vielen einfachen Fällen, aber ich musste einige Routen für Sonderfälle manuell erstellen.
quelle
Ich habe genau zu diesem Thema einen Beitrag geschrieben. Grundsätzlich wird ein verwendet
routeRegistrar
, das Dateien in dem Ordner durchläuft, der/controllers
seine Funktion aufruftinit
. Die Funktion verwendetinit
die Express-app
Variable als Parameter, damit Sie Ihre Routen nach Ihren Wünschen registrieren können.quelle
Dies kann von Interesse sein:
https://github.com/flatiron/nconf
quelle
1) Ihr Express-Projektdateisystem könnte wie folgt aussehen:
app.js - Ihr globaler App-Container
2) Modulhauptdatei (lib / mymodule / index.js):
3) Verbinden Sie das Modul in der Haupt-App.js
4) Beispiellogik
tj sagt / zeigt auf Vimeo interessante Idee, wie man Express-Anwendungen modularisiert - Modulare Webanwendungen mit Node.js und Express . Kraftvoll und einfach.
quelle
http://locomotivejs.org/ bietet eine Möglichkeit, eine mit Node.js und Express erstellte App zu strukturieren.
Von der Website:
quelle
Ich habe kürzlich Module als unabhängige Mini-Apps angenommen.
Für jedes Modul-Routing (# .js) stehen jetzt Ansichten (* .ejs), js, css und Assets nebeneinander. Das Submodul-Routing wird in der übergeordneten # .js mit zwei zusätzlichen Zeilen eingerichtet
Auf diese Weise sind sogar Submodule möglich.
Vergessen Sie nicht, die Ansicht auf das Verzeichnis src zu setzen
quelle
So sieht der Großteil meiner Express-Projektverzeichnisstruktur aus.
Normalerweise
express dirname
initialisiere ich das Projekt, vergebe meine Faulheit, aber es ist sehr flexibel und erweiterbar. PS - das müssen Sie bekommenexpress-generator
(für diejenigen, die danach suchensudo npm install -g express-generator
, sudo, weil Sie es global installieren)Sie müssen sich fragen, warum .env-Dateien? Weil sie funktionieren! Ich benutze
dotenv
Modul in meinen Projekten (viel in letzter Zeit) und es funktioniert! Fügen Sie diese 2 Anweisungen inapp.js
oder einwww
Und eine weitere Zeile, die schnell eingestellt werden muss
/bower_components
, um statische Inhalte unter der Ressource bereitzustellen/ext
Es kann wahrscheinlich für Leute geeignet sein, die Express und Angular zusammen verwenden möchten, oder
javascripts
natürlich nur ohne diese Hierarchie.quelle
Meine Struktur drückt 4. https://github.com/odirleiborgert/borgert-express-boilerplate aus
Pakete
Struktur
quelle
Eine einfache Möglichkeit, Ihre Express-App zu strukturieren:
In main index.js sollte die folgende Reihenfolge beibehalten werden.
quelle
Bester Weg zur MVC-Struktur für ExpressJs-Projekt mit Lenker und Passportjs
quelle