使用Backbone.JS在服务器和客户端之间共享常量的最佳实践

Best practices for shared constants between server and client using Backbone.JS

本文关键字：常量 共享 最佳 之间 客户端 JS Backbone 服务器 使用      更新时间：2023-09-26

使用Backbone.JS处理服务器代码和客户端代码之间共享常量的最佳方法是什么?例如，假设我有这样的用户角色映射:

user_roles = {
  1 => "member", 
  2 => "moderator", 
  3 => "admin"}

显然，如果您在客户端和服务器端代码中重复这些定义，这将不能很好地扩展并且容易出错。

我能想到的解决方案是简单地将这些定义公开为主干。集合或主干。建模并从服务器获取它们，但是如果你有大量的常量类型，这可能会导致不必要的开销，而且我不确定它们是否真的属于模型。

解决这个问题的不同解决方案是什么，它们的可扩展性如何?

我已经尝试了几种不同的方法来处理这个问题。我不知道这两种方法是不是最好的方法，但是这两种方法对我来说都很有效，所以我将在这里描述它们，希望它们能对你有所帮助。

两者的核心概念是相同的:常量在服务器端语言(在我的例子中是c#和Java)中定义为true常量，并将其转换为JSON或javascript以方便客户端。我认为这是正确的方式，而不是共享单一的JSON/YML等。配置文件。仅仅因为javascript没有真正的常量并不意味着你的服务器也不应该有它们。

选项1:通过web服务调用加载常量和枚举。

创建一个服务端点(让我们称之为/enums)，它基本上将所有服务器端枚举和常量收集到一个JSON大簇中。为了避免额外的服务调用，如果您还使用一些服务器端模板框架，您可以将其引导到index.html中。

如果你不想引导任何东西到你的静态内容，你可以做其他的优化。因为常量很少改变，所以可以将/enums响应包装到包含服务器应用程序构建版本的包装器对象中。例如:

{
  "version": "1.2.1.0",
  "enums": { ... }
}

当用户第一次点击页面时，请求GET /enums，并将整个响应存储到浏览器的本地存储中。在随后的访问中，从本地存储器中读取常量，并使用GET /enums?v=1.2.1.0请求常量。服务器应该将它的版本与传递的版本进行比较，如果它们相同，它只会返回HTTP 200 OK，以指示客户端它的枚举仍然有效。

如果你在分布式环境中工作，前端和后端开发人员使用不同的工具，或者通常不紧密合作，这个选项是很好的。

选项2:共享常量作为构建过程的一部分

您可以使用文本转换模板(例如T4)从服务器端语言源生成javascript代码。在我的例子中，这是c#。

我将所有服务器端枚举存储在一个目录中，并运行一个构建任务，该任务将该目录中的所有c#源文件转换为javascript对象，并将它们组合成客户端源树中的一个文件enums.js。

我发现这是一个更好的选择，但如果客户端和服务器开发不是同步完成的(一起构建，一起发布)，依赖关系管理可能会变得相当混乱。在我的例子中，我总是将客户机和服务器部署在一起，所以这样做效果很好。

如果你的后端不是JavaScript，用你的常量生成一个JavaScript或JSON文件，然后将它们包含在你的客户端构建或注入到你的初始HTML模板中。我有时会在Django配置设置中这样做，或者在yaml文件中这样做:yaml -> python, yaml -> js或者只是JSON。

我不知道为常量添加所有额外的主干模型逻辑是否有意义。

另一方面，这是我喜欢meteor.js的一个很好的理由。完全使这种事情不必担心，因为您可以轻松地在服务器和客户端之间共享常量。:)

相关文章：