在 MVC 中，后台任务的代码属于哪里？

Question

我使用的是 ASP.NET，但我确信这适用于任何（或大多数）MVC 框架。

创建新的 Web 项目后，您将获得代码的基本文件夹/语义结构：

• 控制器（来自浏览器的服务请求）
• 模型（存储和操作数据）
• 浏览量（HTML 页面）
• 内容（静态内容
• 脚本 (JavaScript)
• App_Data（数据库文件）

这很好，但是如果我想让代码与浏览器请求分开运行——例如，也许一个请求运行一些代码，但在另一个线程中，并在请求之后继续执行完成了。或者，如果代码只是定期运行，完全独立于请求。

在我的例子中，代码可以处理数据——生成数据、清理数据等等——这让我认为它应该放在模型中。但它并没有真正“建模”数据，它只是在后台处理它。这种东西有语义上的地方吗？

Answer 1

您可以在这里使用队列，例如 MSMQ、RabbitMQ 等。每个需要卸载的请求都可以排队，外部服务将从队列中弹出项目并开始一个接一个地处理它们。该服务本身可以是一个普通的 Windows 服务，尽管您可能在这里使用 WCF。您甚至可以将工作流集成到其中以用于更复杂的处理场景。我通常为这些类型的项目创建一个名为“services.servicename”的单独命名空间。

编辑： 您可能在这里查看 2 个部分。要使这样的事情起作用，您需要一个服务来从您的应用程序中获取请求并将它们添加到队列中。还有另一个实际处理队列的服务。您可能会在解决方案中查看 3 个不同的项目来完成此操作。现在，我以前用 WCF 做过这个，所以我的建议是基于 WCF 技术的。这是您的项目结构的外观。

1. MyCompany.Services.QueueRequest - 接受来自您的应用程序的请求。
2. MyCompany.Services.QueueRequestContract - 提供一个合同（接口），允许您的应用程序与您的 QueueRequest 服务进行交互。
3. MyCompany.Services.QueueProcessor - 后台处理器。

您的 QueueRequest 服务将在 QueueRequestContract 命名空间中实现接口，而不是它自己的。我们这样做是为了在您的应用程序层中重用该合同以与服务进行通信。所以它看起来像这样。

您的应用 --> QueueRequestContract (IMyService) --> QueueRequest 服务（实现 IMyService）。