Cách tốt nhất để chuyển các biến chung thành các mô-đun riêng biệt trong Node.js là gì?

Question

Tôi sử dụng các tệp bộ định tuyến riêng làm mô-đun cho ứng dụng chính và ứng dụng auth. Tôi không thể có được cách tốt nhất để truyền các biến (db client) vào các router. Tôi không muốn hardcode hoặc vượt qua nó với:

module.exports = function(app, db) { 

Có lẽ cách tốt nhất để sử dụng đăng ký đơn hoặc sử dụng biến db toàn cầu?

experiense của bạn với mẫu thiết kế là gì? Cách nào là tốt nhất và tại sao?

Answer 1

Tôi đã tìm thấy bằng cách sử dụng tính năng tiêm phụ thuộc, để chuyển mọi thứ vào, để trở thành phong cách tốt nhất. Nó thực sự sẽ giống như bạn có:

// App.js 
module.exports = function App() { 
}; 

// Database.js 
module.exports = function Database(configuration) { 
}; 

// Routes.js 
module.exports = function Routes(app, database) { 
}; 

// server.js: composition root 
var App = require("./App"); 
var Database = require("./Database"); 
var Routes = require("./Routes"); 
var dbConfig = require("./dbconfig.json"); 

var app = new App(); 
var database = new Database(dbConfig); 
var routes = new Routes(app, database); 

// Use routes. 

này có một số lợi ích:

• nó buộc bạn phải tách hệ thống của bạn thành các thành phần với sự phụ thuộc rõ ràng, thay vì che giấu sự phụ thuộc đâu đó trong giữa tệp nơi họ gọi require("databaseSingleton") hoặc tệ hơn, global.database.
• Nó làm cho việc kiểm tra đơn vị rất dễ dàng: nếu tôi muốn thử nghiệm Routes cách ly, tôi có thể tiêm nó với các thông số app và database giả và chỉ kiểm tra mã số Routes.
• Nó đặt tất cả các đồ thị đối tượng của bạn nối với nhau ở một nơi duy nhất, cụ thể là gốc thành phần (trong trường hợp này là server.js, điểm vào ứng dụng). Điều này mang lại cho bạn một nơi duy nhất để xem mọi thứ phù hợp với nhau như thế nào trong hệ thống.

Một trong những lời giải thích tốt hơn cho điều này mà tôi đã nhìn thấy là an interview with Mark Seeman, tác giả của cuốn sách tuyệt vời Dependency Injection trong .NET. Nó áp dụng nhiều cho JavaScript, và đặc biệt là với Node.js: require thường được sử dụng như một định vị dịch vụ cổ điển, thay vì chỉ là một hệ thống mô-đun.

Answer 2

Tôi đề nghị bạn tạo một tệp cài đặt với cá thể db và với những thứ khác mà bạn cần sử dụng trên toàn cầu như 'singleton'.

Ví dụ, tôi có settings.js với khách hàng redis db của tôi:

var redis = require('redis'); 
exports.redis = redis.createClient(6379, '127.0.0.1'); 

Và trong nhiều mô-đun khác tôi bao gồm nó:

var settings = require('./settings'); 
setting.redis.<...> 

Nhiều thời gian bao gồm nó tôi luôn luôn có một ví dụ kết nối db.

Answer 3

Đó là hoàn toàn lỗi thời, nhưng bạn có thể sử dụng global trong một kịch bản:

global.foo = new Foo(); 

trong kịch bản khác:

foo.bar(); 

Bạn cũng có thể sử dụng liên tục đã tồn tại:

Object.foo = new Foo(); 

Và tại đây:

Object.foo.bar(); 

Answer 4

Bạn có thể tiết kiệm cho mình tất cả các mã soạn sẵn của dây lên các module của bạn nếu bạn sử dụng một khuôn khổ dependency injection

This answer danh sách một vài trong số họ. Tôi cũng đã xây dựng một simpler DI framework here.

EDIT: dưới đây là một bản sao hình thành câu trả lời trong trường hợp trang đó thay đổi

---

require là cách quản lý phụ thuộc vào Node.js và chắc chắn nó là trực quan và hiệu quả, nhưng nó cũng có những hạn chế của nó.

Lời khuyên của tôi là hãy xem xét một số thùng chứa Dependency Injection hiện có cho Node.js để có ý tưởng về ưu điểm/nhược điểm của chúng. Một số trong số đó là:

• Scatter
• Electrolyte
• Wire
• Intravenous
• Pongular

Chỉ cần đến tên một vài.

Bây giờ câu hỏi thực sự là, bạn có thể đạt được điều gì với vùng chứa DI Node.js, so với đơn giản require?

Ưu điểm: testability

• tốt hơn: module chấp nhận phụ thuộc của họ như là đầu vào
• Inversion of Control: quyết định làm thế nào để dây module của bạn mà không cần chạm vào mã chính của ứng dụng.
• thuật toán tùy chỉnh để giải quyết các mô-đun: phụ thuộc có số nhận dạng "ảo", thường chúng không bị ràng buộc vào đường dẫn trên hệ thống tệp.
• Khả năng mở rộng tốt hơn: được bật bởi số nhận dạng IoC và "ảo".
• khác công cụ ưa thích nhất:
  • Async khởi
  • quản lý vòng đời Mô-đun
  • Khả năng mở rộng của các container DI tự
  • có thể dễ dàng thực hiện trừu tượng mức độ cao hơn (ví dụ AOP)

Nhược điểm:

• Khác với trải nghiệm "Node.js": không sử dụng require chắc chắn có cảm giác như bạn đang lệch khỏi cách suy nghĩ của nút.
• Mối quan hệ giữa sự phụ thuộc và triển khai của nó không phải lúc nào cũng rõ ràng. Một phụ thuộc có thể được giải quyết trong thời gian chạy và bị ảnh hưởng bởi các thông số khác nhau. Mã này trở nên khó khăn hơn để hiểu và gỡ lỗi
• chậm thời gian khởi động
• đáo hạn (tại thời điểm này): không ai trong số các giải pháp hiện nay là thực sự phổ biến tại thời điểm này, vì vậy không quá nhiều hướng dẫn, không có hệ sinh thái, không chiến thử nghiệm.
• Một số vùng chứa DI sẽ không hoạt động tốt với các trình bao gói mô-đun như Browserify và Webpack.