调用 Web API 与添加对底层 dll 的引用答案

【问题标题】：Calling Web API vs adding reference to underlying dlls调用 Web API 与添加对底层 dll 的引用
【发布时间】：2015-01-15 04:10:53
【问题描述】：

这更像是一个架构问题，我想知道这种方法的所有可能的利弊。

在我的组织中，我们有一个 ASP.NET 应用程序、一个 Web API 项目和底层 DLL，它们调用物理上位于不同服务器上的 App Tier。在 ASP.NET 应用程序中，对于一个特定的部分，我们有一个 SPA。

对于大多数事情（我会说 99% 的事情），我们正在从 SPA 向 Web-API 进行 ajax 调用以访问底层功能。

SPA 和 WebAPI 都作为不同的应用程序部署和托管在同一 Web 服务器上，并且 WebAPI 引用了底层 DLL，因此这些 DLL 与 WebAPI 一起部署。

对于其中一项功能，需要在 ASPX 页面背后的代码上完成一些服务器端处理。

我建议我的团队继续使用 http 客户端从 SPA 调用 WebAPI，并通过 WebAPI 保持应用程序和 dll 之间的松散耦合，但是很多人（我会说我团队中的其他人）都赞成将 DLL 的直接引用添加到 ASP.NET 应用程序，所以现在这些 DLL 将与 ASP.NET 应用程序一起部署。

我的建议不是很好，因为它提供了简单的实现，我们会在 ASP.NET 应用程序中添加对 DLL 的直接引用吗？如果我的解释不够充分，请告诉我。

【问题讨论】：

如果您简单地将它们称为“web app”和“web api”而不是 a、w、d 和 e，那么阅读您的问题会更容易。这让人困惑。
一般来说，让 ui 引用与 webapi 相同的 dll 违反了拥有 webapi 的整个概念。我听到了这个论点，这通常是因为团队发现连接 webapi 调用“矫枉过正”。 . .然而，对消费应用程序隐藏数据访问的好处是巨大的。我们必须在代码隐藏或 javascript 中操作从 webapi 返回的数据。 . .无论哪种方式，我们都从 webapi 获取数据，然后根据消费者的需要改变数据。我无法看到 Web 应用程序绕过 webapi 以引用相同的数据层 dll 的用例。

【解决方案1】：

如果您可以完全摆脱 Web API，我会支持直接使用 DLL。由于听起来您不打算这样做，我认为您建议继续在您的应用程序中使用 Web API：

当然，路径 A-W 也可以帮助您练习 Web API 组件，帮助您及早发现错误。

【讨论】：

我同意您的观点，即只应遵循一种方法，这也是我所支持的。应用程序中 99% 的事情是使用 Web-API 完成的。它的一两个功能需要一些服务器端处理，而我团队中的这个人正在采用双重方法。