在MVC中，后台任务的代码属于哪里？
我正在使用 ASP.NET，但我确信这适用于任何（或大多数）MVC 框架。
创建新的 Web 项目时，您将获得代码的基本文件夹/语义结构：
- 控制器（来自浏览器的服务请求）
- 模型（存储和操作数据）
- 视图（HTML 页面）
- 内容（静态内容
- 脚本 (JavaScript)
- App_Data（数据库）文件）
那很好，但是如果我想要独立于浏览器请求运行的代码该怎么办——例如，一个请求可能运行一些代码，但在另一个线程中，并在请求结束后继续执行或者，如果代码完全独立于请求而定期运行，
那么代码将处理数据——生成数据、清理数据等——这让我认为它应该进入模型。并没有真正“建模”数据，它只是在后台对其进行处理，这种事情有语义吗？
I'm using ASP.NET, but I'm sure this pertains to any (or most) MVC frameworks.
When a new web project is created, you get a basic folder/semantic structure for your code:
- Controllers (service requests from browsers)
- Models (store and manipulate data)
- Views (HTML pages)
- Content (static content
- Scripts (JavaScript)
- App_Data (database files)
That's fine, but what if I want to have code that runs separately of browser requests -- for example, maybe a request runs some code, but in another thread, and continues executing after the request is completed. Or if the code is just run periodically independent of a request altogether.
In my case, the code would work on data -- generating it, cleaning it up, etc -- which makes me think it should go in models. But it doesn't really "model" data, it just works on it in the background. Is there a semantic place for this kind of thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以在这里使用队列，例如 MSMQ、RabbitMQ 等。每个需要卸载的请求都可以排队，外部服务将从队列中弹出项目并开始一一处理它们。该服务本身可以是普通的 Windows 服务，尽管您可能在这里使用 WCF。您甚至可以将工作流程集成到其中，以实现更复杂的处理场景。我通常为这些类型的项目创建一个名为“services.servicename”的单独命名空间。
编辑：
您可能在这里看到两个部分。为了让这样的事情发挥作用，您需要一个服务来接收来自应用程序的请求并将它们添加到队列中。另一个服务实际处理队列。您可能会在解决方案中考虑 3 个不同的项目来完成此任务。现在，我之前已经使用 WCF 完成了此操作，因此我的建议基于 WCF 技术。这是您的项目结构的外观。
您的 QueueRequest 服务将在 QueueRequestContract 命名空间中实现接口，而不是它自己的接口。我们这样做是为了可以在应用程序层中重用该合同来与服务进行通信。所以它看起来像这样。
您的应用程序 --> QueueRequestContract（IMyService）--> QueueRequest 服务（实现 IMyService）。
You could utilize queues here, such MSMQ, RabbitMQ and etc. Each request which needs to be off-loaded can be queued and an external service would pop items from the queue and start processing them one-by-one. The service itself could be a plain windows service, although you could probably use WCF here. You could even integrate workflow into it for more complex processing scenarios. I generally create a separate namespace called "services.servicename" for these types of projects.
EDIT:
You're probably looking at 2 parts here. For something like this to work, you'd need a service to take requests from your application and add them to the queue. And another service to actually processes the queue. You're likely looking at 3 different projects in your solution to accomplish this. Now, i've done this with WCF before, so my suggestions are based on WCF technology. Here is how your project structure would look.
Your QueueRequest service will be implementing interface in the QueueRequestContract namespace instead of its own. We do that so that we can reuse that contract in your application layer to communicate with the service. So it kind of looks like this.
Your app --> QueueRequestContract (IMyService) --> QueueRequest service (implements IMyService).