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

好问题。我做了一个受MVC启发的分层体系结构。

后端

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

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

前端

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

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

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

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

我与另一个开发人员一起处理这个问题。他喜欢在SQL中工作，基本上什么都做，业务逻辑，格式化等等。在我看来（至少对于我们开发的应用程序来说）SQL用于处理数据存储和检索，服务器代码/客户端代码用于向用户呈现数据，并处理用户与该数据的交互。

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

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

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

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

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

例外情况是，当您确信您的受众仅限于一个区域设置时。

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

现在，在我的前端，我正在循环通过从API接收的"原始"JSON对象，并将其"转换"为一个不同的JSON对象，该对象将直接输入到我的UI表中。请记住，在进行此解析时，UI几乎处于冻结状态。作为一种解决方案，我可以在API中进行"转换"，只需传入一个对象，我就可以直接将其输入到UI表中，而无需更改它

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