我正在构建一个两个服务应用程序，一个使用Entity Framework（我的数据访问层）连接数据库，另一个应用程序处理我的所有业务逻辑。这两个应用程序都是Web API应用程
我想最终将业务API中的一个JSON响应返回给我的外部客户端，但我不确定幕后最好的方法是什么。返回的数据将是描述公司成员的嵌套JSON响应。我的业务层是否应该对数据api进行多次异步调用以收集数据？或者我的业务层是否应该进行一次调用并让数据访问层在一个方法中进行多次调用并将一个嵌套的json响应返回给业务层？
我对这种类型的架构还不熟悉所以我想确保我遵循最佳实践。
答案 0 :(得分：-2)
如果数据太大，并且您认为性能是一个问题，那么最好分割您的网络API，以便让最终用户选择他想要获得的数据，因为他肯定会遇到同样的问题。
这可以通过在不同的功能中拆分信息类型，或者在API上鼓励过滤器和分页功能（甚至设置限制）来实现。
您的API是否必须进行多次调用，还取决于您收集数据的查询...如果您进行多次调用，您将始终必须按客户对查询进行分组，并以某种方式重复某些映射在您的模型上使用EF，当您返回数据时，您必须对结果做同样的工作。这只能通过巨大的数据加载来推动（当您锁定一个或多个表时，SQL查询的性能会下降）
答案 1 :(得分：-2)
取决于。
无论如何，您需要确定瓶颈在哪里。负载测试是你的朋友。
不要仅仅因为它受欢迎或因为它在图表中看起来很整洁而使用某种类型的架构。选择最简单的方法，然后让需求和测试结果告诉你下一步该去哪里。
通过这种方式，您可以根据业务角度实际需要做出最明智的决策。这是一个明显但常被忽视的最佳实践。
如果您和您的客户正在使用OData，而您的业务逻辑层只处理验证等基本内容，那么大多数情况下，您对每个请求的操作/功能都会对您的API进行一次HTTP调用。客户端。 OData查询将包含有关GET，POST或PUT的属性/实体的信息。因此，您永远不会通过线路发送超过必要的更多信息，因此请求可以按原样传递到您的数据层。
当（任何或所有）：
时，这会改变请记住，异步处理的性能优势仅在请求实际同时执行时才会出现。如果某个操作或函数被拆分为链中的多个请求，那么您的API需要返回完全相同的结果，而不是根本不拆分。
为了能够对此说些有用的话，我需要更多关于API调用与BLL和DAL的相同程度的信息程度和相互依赖性的信息。
说了这么多，表演可能不是你在这里首先关注的问题。如果您的主要目标是拥有一个高度可扩展的可插拔架构，其中不同的组件可以彼此独立开发，那么通常有两种风格：
与管道类似的OWIN方法。您可以轻松地将其他中间件插入管道（甚至可以从外部程序集中插入），以及是否在通信链的任何部分中拆分JSON取决于这样做是否有性能优势。
< / LI>一个成熟的SOA，其中每个组件本身都是一个Web服务，也称为＆＃34;微服务＆＃34;。如果您的数据来自不同的（内部和/或外部）来源，您可能会采用这种方法。当其中一个源更新其规范时，这为您提供了更大的灵活性 - 您只需要更新并重新部署该特定API。
但是，我不能强调这一点：从最简单的事情开始，然后尝试找出你实际上需要的内容。