MVC4 客户端获取异步与调用 business-Logic/Repositories 获取数据？
MVC4 client Get Async vs Calling business-Logic/Repositories to fetch data?
我们正在从 Web 表单迁移到 MVC4 架构。我们在同一个解决方案中有我们的 Web API 和 MVC。所以我们的选择很少：
1) 我们可以从我们的 MVC 控制器调用 Web API，就像其他客户端所做的那样：
var response = await client.GetAsync("api/method");
由于 MVC 和 Web API 都在同一个项目中，我们很困惑放置这个额外的 HTTP 调用是否有意义，如果我们直接访问 repository/businessLayer 就可以避免这种调用与我们在 Web API 中所做的方式相同。 （代码重复很少，但性能有好处）
2) 我们有很多资源有多个这样的请求。例如，我们必须调用 8-10 个不同的存储库来获取数据。
可能的解决方案（我们应该如何从 MVC 控制器获取数据）：
1) 我们是否应该通过 client.GetAsync 方法调用这些多个存储库，该方法会异步从存储库中获取所有数据。异步意味着并行逻辑会更快。缺点是我们一直有额外的 HTTP 调用来调用不同的 APIs。
要么
2) 我们是否应该像这些 Web API 最终所做的那样，直接一一调用这 8-10 个存储库？我看不出这有什么好处，因为它是同步的。唯一的好处可能是我们在这里避免了额外的 HTTP 调用。但这是以重复代码的额外成本为代价的。 （从 Web API 和 MVC 访问相同的 BL/Repository 代码）。我不知道是否可以使用一些异步方法从 MVC 控制器调用存储库？
我们应该选择哪一个？具有异步编程功能的额外 HTTP 调用或直接访问存储库或是否有人可以建议两者的混合？
这当然是一个有趣的问题，我也必须做出这个决定。最有趣的部分是用户身份验证。 MVC 和 Web API 都有很好的身份验证过程。 API 当然是为无状态 http 调用（在每个经过身份验证的请求上使用令牌）而 MVC 使用 cookie 和所有其他东西。
对我来说，最好的选择是将此身份验证分开，同时仍指向同一个数据库，这样就不会在我每次想访问数据库时都调用我的 API。即使您的 API 是 运行 在同一台服务器上，我确信直接调用您的数据库会更快。
我认为如果你做得对，你不会有那么多重复代码。
首先，有一个应用核心项目，如果它更大，有一个数据库核心和一个网络核心。您的业务逻辑应该为您的应用程序执行 business。如果它是 api 或 mvc 应用程序，我假设您希望通过这两个应用程序实现相同的目标：以安全和受控的方式获取或更新您的数据。但是不要错误地这样做太多。在您的 mvc/api 项目的控制器中可以包含一些逻辑。
从维护的角度来看：对您的 BL 进行类型安全调用然后通过 API 请求执行此操作要安全得多，这可能会改变功能（或者您必须在所有地方更新版本).
建筑，是一个有趣的世界。
我们正在从 Web 表单迁移到 MVC4 架构。我们在同一个解决方案中有我们的 Web API 和 MVC。所以我们的选择很少：
1) 我们可以从我们的 MVC 控制器调用 Web API，就像其他客户端所做的那样： var response = await client.GetAsync("api/method");
由于 MVC 和 Web API 都在同一个项目中，我们很困惑放置这个额外的 HTTP 调用是否有意义，如果我们直接访问 repository/businessLayer 就可以避免这种调用与我们在 Web API 中所做的方式相同。 （代码重复很少，但性能有好处）
2) 我们有很多资源有多个这样的请求。例如，我们必须调用 8-10 个不同的存储库来获取数据。
可能的解决方案（我们应该如何从 MVC 控制器获取数据）： 1) 我们是否应该通过 client.GetAsync 方法调用这些多个存储库，该方法会异步从存储库中获取所有数据。异步意味着并行逻辑会更快。缺点是我们一直有额外的 HTTP 调用来调用不同的 APIs。 要么 2) 我们是否应该像这些 Web API 最终所做的那样，直接一一调用这 8-10 个存储库？我看不出这有什么好处，因为它是同步的。唯一的好处可能是我们在这里避免了额外的 HTTP 调用。但这是以重复代码的额外成本为代价的。 （从 Web API 和 MVC 访问相同的 BL/Repository 代码）。我不知道是否可以使用一些异步方法从 MVC 控制器调用存储库？
我们应该选择哪一个？具有异步编程功能的额外 HTTP 调用或直接访问存储库或是否有人可以建议两者的混合？
这当然是一个有趣的问题，我也必须做出这个决定。最有趣的部分是用户身份验证。 MVC 和 Web API 都有很好的身份验证过程。 API 当然是为无状态 http 调用（在每个经过身份验证的请求上使用令牌）而 MVC 使用 cookie 和所有其他东西。
对我来说，最好的选择是将此身份验证分开，同时仍指向同一个数据库，这样就不会在我每次想访问数据库时都调用我的 API。即使您的 API 是 运行 在同一台服务器上，我确信直接调用您的数据库会更快。
我认为如果你做得对，你不会有那么多重复代码。 首先，有一个应用核心项目，如果它更大，有一个数据库核心和一个网络核心。您的业务逻辑应该为您的应用程序执行 business。如果它是 api 或 mvc 应用程序，我假设您希望通过这两个应用程序实现相同的目标：以安全和受控的方式获取或更新您的数据。但是不要错误地这样做太多。在您的 mvc/api 项目的控制器中可以包含一些逻辑。
从维护的角度来看：对您的 BL 进行类型安全调用然后通过 API 请求执行此操作要安全得多，这可能会改变功能（或者您必须在所有地方更新版本).
建筑，是一个有趣的世界。