就解决方案体系结构而言，ASP.NET Web API适合哪些方面？

周末我学习了一门关于ASP.NETWebAPI的课程，但我很难理解它的使用情况。做了一些谷歌调查，但仍然感到困惑

我可以看出它对于在数据库上实现CURD操作很好，但我应该在webapi中实现业务逻辑吗

假设我有一个工作单元。检查数据库中是否存在客户，如果存在，则获取最后10个订单。这应该是web api中的一种方法，还是两种方法，一种用于检查客户，另一种用于获取订单？到目前为止，我已经看到了在单个数据库资源上实现CURD的示例

如果我必须想象一个使用WebAPI的应用程序架构，我想

前端-在MVC中 业务逻辑-从控制器调用的独立业务逻辑类库，而控制器又调用Web API？

---

数据库逻辑-使用Web-API实现CURD

最好保持简单，以下是我在一个大型（1000用户）企业应用程序上的结构：

2个ASP.net项目，还有3个类库

第一个asp.net项目-是一个标准的MVC应用程序，但大多数情况下，它只是用作所有HTML/cshtml、javascript和css资产的容器。我们几乎不使用razor/controller MVC语法。这个“前端”项目使用angular.js（单页应用程序-SPA体系结构）进行javascript驱动，调用第二个Asp.net web api项目来收集所有数据

第二个asp.net项目正在使用asp.net Web API 2模板。该项目负责收集所有数据。该项目来自多个地方，移动/平板电脑应用程序，是第一个asp.net项目，并向第三方公司公开，以便集成到我们的平台中

类库1（可移植类库）-是我们的数据模型项目，它跨多个层共享，包括业务层、数据层、web api层，由于它是一个可移植类库，因此在我们的移动项目中共享。在可能的情况下，我们将同一个模型从db直接重用到API层，有时这是不可能的，我们使用业务层在模型之间进行映射

类库2-引用自API和MVC项目。这个dll包含我们所有的业务逻辑，有时它只是一个传递层，在CRUD操作的情况下很少执行逻辑，只调用数据层，但大多数时候，所有与检查字段输入相关的业务逻辑，如上面所述的对db的多个调用，都被包装在这一层后面。正如我之前所说的，我们的第一个asp.net项目几乎没有逻辑，我们从前端项目中引用它的唯一原因是因为该层包含所有身份验证、授权和权限逻辑，以便用户能够访问给定页面

类库3-仅从我们的业务层引用，该层与多个数据库平台进行所有数据库和中间件交互

---

通过上述结构，它可以将事情分割开来，以允许注入MOQ接口，允许更简单的测试，并允许跨多个项目甚至多个设备（iOS/android/windows应用程序）进行最佳重用。我们将这两个asp.net项目分开的唯一原因是因为基础设施的原因，每个项目的流量配置文件完全不同，因此它允许我们优化适合流量配置文件的硬件-许多人将能够将它们组合到一个项目中。

您听说过基于REST的API吗？感谢您提供详细的回答。为什么您在创建时在MVC项目中引用类库2提到你的MVC项目正在调用WebAPI，所以，难道不是所有的东西都要通过WebAPI吗。然而，在我看来，上面提到的应用程序太大了，无法在一个单页应用程序中运行——因此我们使用了一个“混合单页应用程序体系结构”，它有几个SPA的集合。因此，要控制允许哪个用户访问给定视图/控制器的权限，最后1%是所有身份验证/权限逻辑。可以说，这也可以转移到WebAPI，但我们有一些传统的合作来阻止这一点。即使收集了几个SPA，似乎也没有足够的理由这样做。传统的合作可能会，我只是想知道它们是什么类型的，因为我最近开发了一些做同样事情的应用程序，并且我能够消除这种双重依赖。。。