Web Api - 每个数据库实体或每个 UI 屏幕的控制器答案

【问题标题】：Web Api - Controller Per Database Entity or per UI ScreenWeb Api - 每个数据库实体或每个 UI 屏幕的控制器
【发布时间】：2016-02-12 11:25:53
【问题描述】：

我在我的项目中使用 web api 来公开数据，这些数据又打算供移动应用程序和 web 应用程序使用。

我想知道公开数据的最佳做法是什么。

例如，我有一个客户注册表单，我在其中捕获客户详细信息，包括城市和国家/地区。

公开数据的一种方法是为城市和国家/地区设置单独的控制器，并在客户注册表单上分别调用两者以加载城市和国家/地区的数据。

这种方法的问题是，如果我必须加载一百个字段，我将不得不对 api 进行一百次不同的调用来加载数据，因此应用程序会很慢。

第二种方法是设计 api 层，使一个控制器公开表单/屏幕（客户注册）所需的所有查找数据（城市、国家/地区）。在这种情况下，我将不得不对 api 进行一次调用以获取所有必需的数据。

感觉就像，使用第二种方法我违反了关注点分离。

走哪条路？

【问题讨论】：

我倾向于为每个实体保留一个控制器，尽可能少地创建。如果我需要加载超过 10 个字段，我会移动服务器端以在视图中编译，或者在 SPA 的情况下，创建一个返回表单所需的所有数据的单个控制器方法，而不是从 10 多个控制器请求数据。 stackoverflow.com/questions/25148951/…
tnx @Prime03 .. 所以你的意思是，在客户示例中，我们应该通过单独的控制器（城市、国家）以及另一个控制器公开数据，其中所有数据用于如果字段或更多，则返回视图以避免多次调用。在那种情况下，你不认为我们会重复自己吗？
在客户示例中，如果我只需要加载城市/国家/电话类型/地址类型等...我将从各自的控制器加载它们。在页面上提供此数据所需的 http 请求数量超过性能/资源阈值后，我将创建另一个方法，在单个 json 数组中返回所有所需数据。这完全取决于您的架构。您正在用一些 DRY 点换取一些性能点。艺术处于平衡之中。我应该注意，我从来没有为表单这样做过。
正是.. 这就是这篇文章的重点.. 我们什么时候应该追求性能，什么时候应该追求设计最佳实践:)
您显然希望在任何给定页面上根据需要在页面加载时进行尽可能少的 http 调用。如果您需要发出 100 个 http 请求，请将其合并为 1 个或 2 个。您的问题是“如果我必须加载一百个字段”。你有，还是没有？如果没有，请从正确封装实体（地址而不是城市和国家/地区）的控制器开始。如果您需要减少请求，请在新方法中重用现有方法进行整合。

标签： asp.net architecture asp.net-web-api

【解决方案1】：

您不能只拆分 UI 和 API 层吗？

如果它们不是您域的核心部分，我认为您不应该创建 API 来获取国家或任何其他侧面引用。

我想您应该只公开api/v1/users 资源端点以供用户注册，它需要有效的用户数据进行注册。

另外，您应该公开/users UI，这将生成完整的 UI，包括您需要的所有列表并将其呈现给用户。此 UI 控制器将在内部调用您的域模型，而不是通过 API 来获取生成 UI 所需的所有详细信息。然后客户端的 UI 将使用用户选择的数据调用您的 API 控制器来注册用户。

这是否适合您的开发模型？

【讨论】：

调用 /user 并绑定 UI 中的列表如果我使用 web 并且渲染 UI 的逻辑与配置（数据库用户、密码）一起在服务器中连接到数据存储并获取列表数据，但如何在移动应用程序的情况下完成，因为理想情况下应用程序不应该知道如何直接连接到数据存储。
@ZedBee 好吧，我明白了。当然，移动应用程序有点不同。在这种情况下，您可能需要以某种方式通过 REST 公开数据库中的所有内容。
正是，这就是我们的目标，设计一个单一的rest api，供不同的应用程序使用，如移动、Web、桌面等。
@ZedBee 否，每个 REST 资源一个 api 控制器。 REST 实体并不总是直接映射到您的模型。例如，您的 Cheque 模型可能具有 pay 方法。但在 REST 中，您将拥有“虚拟”/transaction 资源，它在创建时表示 pay 操作。
tnx.. 知道了.. +1 发帖:)