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

Question

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

作为一个例子，假设我有一个后端以特定格式返回名称的族谱，但在前端我需要调整格式以匹配小部件期望的格式，如果这个调整完成的话在后端还是前端？

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

Answer 1

好问题。我做了一个分层的MVC风格的架构。

BACKEND

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

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

FRONTEND

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

我发现这种架构可以实现清洁分离和高生产率。

Answer 2

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

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

Answer 3

我与另一位与我合作的开发人员处理此问题。他喜欢在SQL中工作，并且基本上做了所有事情，业务逻辑，格式化等等。这让我无所适从。在我看来（至少对于我们工作的应用程序而言）SQL用于处理数据存储和检索，服务器代码/客户端代码用于向用户呈现数据并处理用户与该数据的交互。

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

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

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

Answer 4

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

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

我确实看到了在后端进行转换的理论问题（关注点分离）。我还看到在某些其他UI组件需要相同数据但格式不同的情况下，构建/维护所需时间更长的问题。但我确实相信有话要说，让UI保持不冻结状态。

Answer 5

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

如果打算从支持区域设置的客户端（例如Web浏览器）访问使用的应用程序，则我希望将格式尽可能多地推送到前端。 从技术上来说可以将语言环境作为参数发送到后端API，但是默认情况下，现代的前端库通常在处理语言环境方面非常出色，这使得在前端执行操作更加容易，结束。

当您确定您的听众仅限于一种语言环境时，例外。