Architektura aplikacji oparta na mongoose

Question

To nie jest konkretne pytanie dotyczące aplikacji/kodu, chodzi tylko o powszechną architekturę aplikacji.

Próbuję zrozumieć właściwy sposób na uporządkowanie mojej aplikacji mangusty. Ponieważ jestem nowy Mangusta, to w jaki sposób mogę to zrobić teraz:

rdzeń/settings.js

var mongoose = require('mongoose'); 
exports.mongoose = mongoose; 
mongoose.connect('mongodb://localhost/blog'); 
exports.db = mongoose.connection; 

rdzeń/models.js

settings = require("./settings"); 

// post schema 
var postSchema = settings.mongoose.Schema({ 
    header: String, 
    author: String, 
    text: String 
}) 

//compiling our schema into a Model 
exports.post = settings.mongoose.model('post', postSchema) 

rdzeń/db-layer.js

settings = require("./core/settings"); 
models = require("./core/models"); 

exports.function = createAndWriteNewPost(function(callback) { 
    settings.db.on('error', console.error.bind(console, 'connection error:')); 
    settings.db.once('open', function callback() { 
     new models.post({ 
      header: 'header', 
      author: "author", 
      text: "Hello" 
     }).save(function(err, post) { 
      callback('ok'); 
     }); 
    }); 
}); 

trasy/post.js

db = reqiure("../core/db.js") 

exports.get = function(req, res) { 
    db.createAndWriteNewPost(function(status){ 
    res.render('add_material', { 
     //blah blah blah   
     }); 
    }); 
}; 

app.js

var post = require ('routes/post.js') 
... 
app.get('/post', post.get); 

Tak, ten kod został bardzo uproszczony (jeszcze nie testowane), żeby pokazać moje aktualne architektury myśli. To nie jest konkretna aplikacja, po prostu coś w rodzaju tworzenia abstrakcyjnego posta na blogu. Tak to działa:

app.js --> routes/post.js <--> core/db-layer.js 
            | 
            v 
           core/models.js <--> core/settings.js 

Dla mnie wydaje się zbyt niepotrzebny. Czy możesz zaproponować bardziej optymalną strukturę aplikacji? Dzięki.

Answer 1

To dość dużo jak się do tego zabrać, z kilkoma różnicami:

• Nie sądzę, można mieć otwarty słuchacza wewnątrz swojej funkcji w DB-warstwy. Zwykle robię to, gdy używam trwałego połączenia, takiego jak twoje, uruchamiasz samą aplikację w programie obsługi otwartych plików db. Jeśli nie chcesz używać stałych połączeń, użyj funkcji createConnection w funkcji warstwy db i upewnij się, że zamknąłeś ją przed wywołaniem wywołania zwrotnego. Nie jestem pewien, czy wyrażam się jasno. Daj mi znać, jeśli chcesz podać przykład kodu.
• To jest bardziej ogólna wskazówka node.js, ale zachowuję ciąg połączenia z bazą danych i inną konfigurację w pliku json i wymagam go tam, gdzie jest potrzebny. Prawdopodobnie nie będziesz już potrzebował innego pliku settings.js.
• Można również użyć funkcji schematu (http://mongoosejs.com/docs/api.html#schema_Schema-method), aby zakodować niektóre funkcje aplikacji w samych modelach.

Answer 2

Kiedy po raz pierwszy dostałem się do Node.js, Express i Mongoose, zmagałem się ze skalowaniem mojego kodu. Intencją mojej odpowiedzi jest pomoc komuś, kto pracuje nad czymś więcej niż tylko prostym blogiem, ale aby pomóc w jeszcze większym, skalowalnym projekcie.

• Ja zawsze podłączony do bazy danych, nie otwieranie i zamykanie połączeń, gdy są potrzebne
• używam index.js jako pliku głównego folderu, tak jak chcielibyśmy zrobić w innych językach
• modeli są przechowywane w ich własnych dokumentach, a require() d do pliku models/index.js.
• trasy są podobne do modeli, każdy poziom trasy ma folder, który ma po kolei plik index.js. Łatwo więc zorganizować coś takiego, jak http://example.com/api/documents/:id. Ma również więcej sensu, gdy przechodzi się przez strukturę pliku.

Oto struktura czego używam:

-- app.js 
-- models/ 
---- index.js 
---- blog.js 
-- mongoose/ 
---- index.js 
-- routes/ 
---- index.js 
---- blog/index.js 
-- public/ 
-- views/ 
---- index.{your layout engine} => I use Jade.lang 
-- methods/ 
---- index.js => use if you'd rather write all your functions here 
---- blog.js => can store more complex logic here 

app.js

var db = require('./mongoose'), 
    express = require('express'); 
// note that I'm leaving out the other things like 'http' or 'path' 
var app = express(); 

// get the routes 
require('./routes')(app); 
// I just require routes, without naming it as a var, & that I pass (app) 

mongoose/index.js

// Mongoose connect is called once by the app.js & connection established 
// No need to include it elsewhere 
var mongoose = require('mongoose'); 
mongoose.connect('mongodb://localhost/blog'); 

// I have just connected, and I'm not exporting anything from here 

Modele/index.js

// Logic here is to keep a good reference of what's used 

// models 
Blog = require('./blog'); 
// User = require('./user'); 

// exports 
exports.blogModel = Blog.blogModel; 
// exports.userModel = User.userModel; 

Modele/blog.js

Więc dla każdego modelu, które pracują na utworzenie dokumentu model.js i dodać go w powyższym models/index.js. Jako przykład dodałem model User, ale go skomentowałem.

// set up mongoose 
var mongoose = require('mongoose'); 
var Schema = mongoose.Schema, 
ObjectId = Schema.ObjectId; 

var BlogSchema = Schema({ 
    header: {type: String }, 
    author: {type: String }, 
    text: {type: String }, 
    _id: { type: ObjectId } // not necessary, showing use of ObjectId 
}); 

Blog = mongoose.model('Blog', BlogSchema); 
// the above is necessary as you might have embedded schemas which you don't export 

exports.blogModel = Blog; 

trasy/index.js

module.exports = function(app) { 
    app.get('/', function(req, res) { 
    // do stuff 
    }); 
    require('./blog')(app); 
    // other routes entered here as require(route)(app); 
    // we basically pass 'app' around to each route 
} 

szlaki/blog/index.js

module.exports = function(app) { 
    app.get('/blog', function(req, res) { 
    // do stuff 
    }); 
    require('./nested')(app); 
    // this is for things like http://example.com/blog/nested 
    // you would follow the same logic as in 'routes/index.js' at a nested level 
} 

zaproponował wykorzystanie

0 Modele
• : do tworzenia logiki, która zajmuje się dokumentami, tj. Tworzenie, aktualizowanie, usuwanie i wyszukiwanie.
• trasy: minimalne kodowanie, tylko tam, gdzie muszę parsować dane http, tworzyć wystąpienia modeli, a następnie wysyłam zapytania do odpowiedniego modelu.
• metody: dla bardziej złożonej logiki, która nie dotyczy bezpośrednio modeli. Jako przykład mam folder algorithms/, w którym przechowuję wszystkie algorytmy, których używam w mojej aplikacji.

Mam nadzieję, że to zapewni większą przejrzystość. Ta struktura działa dla mnie cudownie, ponieważ uważam, że jest łatwa do naśladowania.