在解决方案体系结构方面，ASP.NET Web适合哪里？

Question

在周末，我上了一门关于Web的课程，但我很难理解它在使用上适合什么地方。做了一些谷歌的研究，但还是很困惑。

1. 我可以看出它对数据库上实现CURD操作是有益的，但是我应该在web中实现业务逻辑吗？
2. 说我有个工作单位。检查客户是否存在于数据库中，如果是的话，得到最后的10份订单。这是在web中的一种方法还是两种方法--一种是检查客户，另一种是获取订单？到目前为止，我已经看到了在单个数据库资源上实现CURD的示例。
3. 如果我不得不想象一个使用web-api的应用程序体系结构，我想

前端-在MVC业务逻辑-独立的业务逻辑类库调用从控制器，谁反过来调用Web？数据库逻辑--使用网络-API实现CURD？

Answer 1

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

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

1 asp.net Project --是一个标准的应用程序，但是大多数情况下，它只是用作所有HTML/cshtml、javascript和css资产的容器。我们很少使用或不使用剃刀/控制器MVC语法。这个“前端”项目使用angular.js (单页应用程序-SPA体系结构)非常javascript驱动，调用第二个Asp.net web项目来收集和收集所有数据。

第二asp.net项目-正在使用ASP.net Web 2模板。这个项目负责收集所有数据。这个项目被称为从多个地方，移动/平板应用程序，第一asp.net项目，并暴露给第三方公司，以集成到我们的平台。

Class lib 1 (可移植类库)是我们的数据模型项目，它跨多个层共享，包括业务层、数据层、web层，因为它是一个可移植类库，因此在我们的移动项目中共享。在可能的情况下，我们将相同的模型从db权限重用到API层，有时这是不可能的，我们使用业务层在模型之间进行映射。

类Lib 2 -来自于API和MVC项目。这个dll包含了我们所有的业务逻辑，有时它只是一个通过层，在CRUD操作中只执行很少的逻辑，并且只调用数据层，但是大多数时候，所有与检查字段输入有关的业务逻辑，像上面描述的对db的多个调用，都被包装在这个后面。正如我前面说过的，我们的第一个asp.net项目几乎没有什么逻辑，我们从前端项目引用这一点的唯一原因是，这一层包含了所有用于建立的身份验证、授权和权限逻辑，即用户可以访问给定的页面。

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

有了上面的结构，就可以将事情分开，以允许MOQ接口被注入，允许更容易的测试，并允许在多个项目甚至多个设备(iOS/android/windows应用程序)之间进行最佳重用。我们分离出两个asp.net项目的唯一原因是由于基础设施的原因，每个项目的流量配置是完全不同的，因此它允许我们优化适合于流量配置文件的硬件--许多人将能够将这些合并成一个项目。