我经常使用这些原型：
在不同的文件中反复要求相同或相似的功能。 如下所示，在范围内或范围之外要求Element会更好吗？
我想它应该在外面，否则我将在我的代码中创建大量的Element副本， 不是吗？
var Element = require("./Element.js") var _ = function(){ this.element = new Element(); this.stuff; } _.prototype.setStuff = function(stuff){ this.stuff = stuff } _.prototype.doStuff = function(){ this.stuff(); } module.exports = _;I often use prototypes such as these:
requiring the same or similar functions over and over in different files. Would it be better to require Element inside the scope or outside the scope as done so below?
I guess it's should be outside, otherwise I will be creating lots of copies of Element all over my code, No?
var Element = require("./Element.js") var _ = function(){ this.element = new Element(); this.stuff; } _.prototype.setStuff = function(stuff){ this.stuff = stuff } _.prototype.doStuff = function(){ this.stuff(); } module.exports = _;Thanks.
最满意答案
由于这是一个node.js模块，因此这里有几个注意事项：
require()是同步的。 因此，您不希望在实时服务器请求中使用它，因为这会阻止服务器的可伸缩性。 初始化模块并初始化服务器时，通常需要使用一次require() 。
在node.js模块中声明的变量仅限于模块。 从技术上讲，模块范围在模块函数内部，因此在那里声明的任何变量都已经是局部变量，因此不需要任何额外的范围保护。
模块被缓存。 因此，如果您在同一路径上多次执行require() ，则速度非常快。 在第一次实际加载和初始化模块之后，所有后续调用都会返回相同的缓存模块句柄。 因此，不要试图弄乱代码结构以减少调用require()的位置数量。 编写干净的代码，如果require()在同一个模块上调用几次require() ，这没什么大不了的。
在不同的文件中反复要求相同或相似的功能。 如下所示，在范围内或范围之外要求元素会更好吗？
您通常希望在node.js模块中的最高级别放置require()语句，因为您希望在模块首次初始化时初始化它们，并且您希望与模块中的所有代码共享该模块句柄。 如果你的代码足够复杂，你想在几个不同的地方为同一个模块调用require()来保持你的代码更加分区，那么你可能应该将你的代码分解成单独的模块，让每个模块require()它需要自己。
我想它应该在外面，否则我将在我的代码中创建大量的Element副本，
在模块的最高范围之外。 没有理由不加载模块一次，并与模块中可能想要使用它的所有代码共享模块句柄。
在某些特殊情况下，您可能希望仅在需要模块时才在运行时在某些特定条件下动态加载模块。 这种情况很少见，并且由于加载模块的同步特性而在执行此操作时会产生性能影响，因此很少这样做。 因此，我不想在我之前的建议中保持绝对，但也想解释只按需加载某些内容很少并且会产生后果。
Since this is a node.js module, there are several considerations here:
require() is synchronous. Thus you don't ever want to use it inside of live server requests because that blocks the scalability of your server. You will generally want to use require() once when a module is initialized and your server is being initialized.
Variables declared within a node.js module are scoped only to the module. Technically the module scope is inside a module function so any variables declared there are already local variables and thus don't need any extra scope protection.
Modules are cached. So, it is very fast if you do require() multiple times on the same path. After the first time when the module is actually loaded and initialized, all subsequent calls just return the same cached module handle. So, don't try to mess with the structure of your code to reduce the number of places you call require(). Write clean code and if that necessitates calling require() a few times on the same module, that's no big deal.
requiring the same or similar functions over and over in different files. Would it be better to require Element inside the scope or outside the scope as done so below?
You usually want to put require() statements at the highest level in your node.js modules because you want to initialize them once when the module is first initialized and you want to share that module handle with all the code in the module. If your code is complex enough that you feel like calling require() for the same module in several different places to keep your code more partitioned, then you probably should be breaking your code into separate modules anyway and let each module require() in whatever it needs itself.
I guess it's should be outside, otherwise I will be creating lots of copies of Element all over my code,
Outside at the highest scope in your module. There's really little reason not to just load the module once and share the module handle with all the code in the module that might want to use it.
There are a few special cases where you might want to dynamically load modules only in some specific conditions at run-time only when a module is needed. This is rare and has performance consequences when doing so because of the synchronous nature of loading modules so it is rarely done. So, I didn't want to be absolute in my earlier recommendation, but also wanted to explain that loading something only on-demand is rare and has consequences.
更多推荐
发布评论