使用Backbone.JS在服务器和客户端之间共享常量的最佳实践 [英] Best practices for shared constants between server and client using Backbone.JS

问题描述

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

What is the best way to handle shared constants between server code and client code using Backbone.JS ? For example, say I have this map of user roles:

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

很明显，如果您在客户端和服务器端在代码中重复这些定义，则扩展性不好，并且容易出错.

Obviously, if you duplicate these definitions in code at both client and server side, this doesn't scale well and is error-prone.

我想出的解决方案只是将这些定义公开为Backbone.Collection或Backbone.Model并从服务器获取它们，但是如果您有大量的常量类型，这可能会导致不希望的开销，而我我不确定它们是否真正属于模型.

The solution I could come up with is simply expose these definitions as a Backbone.Collection or Backbone.Model and fetch them from the server, but this might cause undesired overhead if you have a large amount of constant types, and I'm not sure whether they actually belong inside the model at all.

解决此问题的解决方案有哪些?扩展性如何?

What are the different solutions to solve this problem, and how well do they scale?

推荐答案

我尝试了几种不同的方法来处理此问题.我不知道它们是否是最好的方式，但是两者对我来说都效果很好，所以我只在这里描述它们，希望对他们有所帮助.

I've tried a couple of different ways of handling this issue. I don't know if either of them is the best way, but both have worked well for me, so I'll just describe them here and hope they're of help.

两者的核心概念相同:常量在服务器端语言(在我的情况下为C#和Java)中定义为 true常量，并转换为JSON或javascript以获取好处.客户.我认为这是要走的路，而不是共享一个JSON/YML/etc.配置文件.仅仅因为javascript没有真正的常量，并不意味着您的服务器也不应该拥有它们.

The core concept is the same in both: Constants are defined as true constants in the server-side language (C# and Java in my case), and are converted to JSON or javascript for the benefit of the client. I think this is the way to go, as opposed to sharing a single JSON/YML/etc. configuration file. Just because javascript doesn't have true constants doesn't mean your server shouldn't have them either.

选项1:通过Web服务调用在运行时加载常量和枚举.

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

Create a service endpoint (let's call it /enums) that basically collects all the server-side enumerations and constants into one big clump of JSON. To avoid an extra service call, if you're also using some server-side templating framework, you can bootstrap this into your index.html.

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

If you don't want to bootstrap anything to your static content, there are other optimizations you can do. Because constants change so rarely, you can wrap /enums response into a wrapper object that includes the server application build version. For example:

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

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

When the user hits the page for the first time, request GET /enums, and store the whole response into browser's local storage. On subsequent visits read the constants from the local storage and request the constants with GET /enums?v=1.2.1.0. The server should compare it's version to the passed version, and if they were identical, it would only return HTTP 200 OK to indicate to the client that its enumerations were still valid.

如果您在前端和后端开发人员使用不同工具的分布式环境中工作，或者通常不紧密协作，则此选项很好.

This option is good if you work in a distributed environment where frontend- and backend-developers are using different tools, or don't generally work closely together.

选项2:在构建过程中共享常量

您可以使用文本转换模板(例如 T4 )来从服务器端语言源生成javascript代码.就我而言，这是C#.

You can use text transformation templates (such as T4) to generate javascript code from server side language source. In my case this was C#.

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

I stored all server-side enumerations in one directory and ran a build task which transformed all C# source files in that directory into javascript objects and combined them into one file enums.js in the client side source tree.

我发现这是一个更好的选择，但是如果客户端和服务器开发不是同步完成(一起构建，一起发布)，则依赖项管理可能会变得非常混乱.就我而言，我总是同时部署客户端和服务器，因此效果很好.

I found this to be a preferrable option, but if the client and server development is not done synchronously (built together, released together), the dependency management can get pretty messy. In my case I always deployed both client and server together, so this worked out great.

这篇关于使用Backbone.JS在服务器和客户端之间共享常量的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！