2

我正在开发从后端获取 JSON 后生成布局的 Web 应用程序。但是从后端接收的对象非常复杂，需要在对象周围循环很多次才能获得布局。

将数据发布到后端时也会发生同样的情况。

我的感觉是，如果我们按照前端布局生成JSON Object to Post数据，即使后端的对象结构发生变化，布局生成也不需要那些额外的循环。

那么json对象总是后端给出的还是应该根据前端给出的？

例如后端给

[
  {
    "keyid": "value",
    "attr1": "value1",
    "attr2": "value2"
  },
  {
    "keyid": "value",
    "attr3": "value3",
    "attr4": "value4"
  }
]

但是前端很容易以以下格式接收和发送对象：

{
    "keyid": "value",
    "attr": {
        "attr1": "value1",
        "attr2": "value2",
        "attr3": "value3",
        "attr4": "value4"
    }
}
4

2 回答 2

4

好问题，尽管它可能会因为“太宽泛”而被关闭。

一般来说，后端负责持久化数据，执行业务逻辑，准备和接收进出前端的数据包，理想的情况是前端可以限制自己的角色，这主要是显示数据、管理导航和处理用户交互，进行任何必要的预处理和操作来完成这些事情。

如果后端“做得不够”，那么你看到前端需要发出太多的数据请求来获取它需要的数据，做相当于“连接”来组合和关联数据，并执行业务逻辑。这会减慢前端的速度并使其更加复杂，并将业务逻辑分散到后端和前端。

另一方面，如果后端“做得太多”，并且计算和提供所有内容，只需要填充到一些 HTML 模板中，结果就是它最终过于依赖特定的前端——最终设计，这意味着更改需要对双方进行太多修改。

因此，人们试图达到中庸之道。后端应该检索所有必要的数据，关联和操作它，并执行业务逻辑。它提供了一组相对抽象但充实的数据对象，然后前端可以为 UI 准备和操作这些对象。在哪里划界没有硬性规定。

例如，分页可以被认为是一个“UI”问题，并且可以被大多数客户端框架轻松处理，但是如果有数百或数千个对象，性能考虑可能会要求在服务器上处理这个问题。排序也一样。

考虑购物车中商品总价的计算。前端可以轻松地执行这种业务逻辑，但可能会有一些规则，例如批量折扣或货币兑换，最好在后端处理。当然，如果要在服务器上进行计算，则每次将商品添加到购物车时都需要再次往返服务器以重新计算总数。往返相对便宜，但在某些情况下，性能问题可能会导致人们希望在客户端上执行此操作以避免往返。

归根结底，这是一组设计选择。当然，后端 API 被“冻结”并且前端人员只需要使用他们提供的东西来工作的情况经常发生。

于 2015-07-11T06:07:54.860 回答
1

我认为后端和前端没有两个不同版本的 JSON 对象。它们对两者都是一样的。它的区别仅在于您如何访问它以及您使用什么方法来访问它。

您可以在http://json.org/上找到相同的各种实现

于 2015-07-11T05:48:20.187 回答