数据应该在后端格式化还是在前端格式化？

Question

我有一个 Web 应用程序，我想知道在前端或后端格式化数据是否更好？ 他们都完成了工作，但有人可以帮我集思广益，哪个是两者之间更好的选择。

例如，假设我有一个后端以某种格式返回名称的家谱，但在前端我需要调整格式以匹配小部件期望的格式，如果在后端进行此调整还是前端？

如果在后端完成，我可以直接将数据推送到前端的小部件中，否则我必须事先在前端解析。 谁能想到这种情况的利弊？ 谢谢。

Answer 1

很好的问题。 我做了一个分层的 MVC-inspired 架构。

后端

我根据其“自然”顺序对后端的数据进行建模（格式化）。 换句话说，我遵循数据的内部组织。 这是因为我的 API 经常被多个、不断变化或不断发展的客户端使用，并且多次重写 API 或拥有多个版本需要太多时间来维护。

这并不意味着您应该在每次 API 调用时发送数据库的内容。 您绝对应该为每次调用缩减数据模型，但它应该是后端（“自然”）数据模型的缩减版本，而不是针对特定视图定制的数据结构。

前端

在前端，我有一个紧密耦合的控制器，它从服务器接收数据并将数据转换为适合给定视图的模型。 根据客户端使用的技术，可能会有对此的库支持（例如，用于 Java 的 javascript/HTML Swing 的 AngularJS、用于 C# 的 WPF 等）

我发现这种架构可以实现干净的分离和高生产力。

Answer 2

这实际上取决于您需要对数据进行的转换的性质，以及需要进行某种类型转换的频率。

我会让后端默认返回原始数据，但对于前端通常需要的特定数据格式，我会让后端端点接受一个请求参数，该参数告诉后端应该以什么格式返回数据。

Answer 3

我和另一个我一起工作的开发人员处理这个问题。 他喜欢在 SQL 方面工作，并且基本上完成了那里的所有工作，包括业务逻辑、格式设置等。让我无所适从。 在我看来（至少对于我们开发的应用程序而言）SQL 用于处理数据存储和检索，服务器代码/客户端代码用于将数据呈现给用户并处理用户与该数据的交互。

不过，这不仅限于 SQL（或其他数据库引擎）与您的应用程序代码。 在服务器代码更多是一个 API 的情况下，将数据传递给一个 javascript 重的 web 应用程序，同样的事情也适用。 API 不知道 UI 可能想要对数据做什么，API 的目的应该是提供原始数据，并让 javascript/presentation 代码以所需的方式处理它的格式化。

我确信这有例外，但这是我喜欢遵循的一般规则。 格式化属于表示领域，而不是业务逻辑或数据检索。 把它放在那里。

编辑：我重读了你的问题，我想我错过了一个微妙但关键的点。 如果您有一个构造函数或模型，或者需要特定格式的输入，那么在 SQL 中进行格式化/转换以避免在使用数据之前转换数据的额外步骤可能是明智的。 不过，这将在很大程度上取决于试图解决的问题，以及数据来自何处以及将在何处使用的细节。

Answer 4

要考虑的另一个方面是区域设置意识（千位分隔符、逗号分隔符、日期格式等）。

如果消费应用程序旨在从支持区域设置的客户端（例如 Web 浏览器）访问，我更愿意尽可能将格式推送到前端。 从技术上讲，可以将语言环境作为参数发送到后端 API，但现代前端库在默认情况下通常非常擅长处理语言环境，这使得在前端执行此操作变得更加容易。

例外情况是当您确定您的受众仅限于一个语言环境时。

Answer 5

我想提供前端开发人员/用户体验的观点和示例。

现在，在我的前端，我循环遍历从 API 接收到的“原始”JSON 对象，并将其“转换”为不同的 JSON 对象，该对象将直接输入到我的 UI 表中。 请记住，在进行此解析时，UI 几乎冻结了。 作为解决方案，我可以在 API 中进行“转换”，然后传入一个对象，我可以直接将其输入 UI 表中，而无需更改它。

我确实看到了后端转换的理论问题（关注点分离）。 我还看到了一个问题，在某些其他 UI 组件需要相同数据但格式不同的情况下，构建/维护需要更长的时间。 但我确实相信让 UI 自由而不被冻结是有道理的。