在 ASP.NET 页面中执行批量处理
我们需要能够在特定日期发生或满足某些业务条件时发送自动电子邮件。我们正在设置此系统以与现有 ASP.NET 网站配合使用。我在这里与其他一位开发人员进行了交谈，并讨论了一些问题。
需要注意的事项：
- 我们需要的所有信息都已经在 ASP.NET 网站中建模了
- 电子邮件生成所需的一些业务逻辑也已经在网站中
我们决定理想的解决方案是拥有一个单独的可执行文件该程序计划通宵运行并进行处理和发送电子邮件。该解决方案有两个主要问题：
- 如果网站已更新（业务逻辑或模型），但可执行文件意外丢失，则可执行文件可能会停止发送电子邮件，或者更糟糕的是，根据过时的逻辑发送电子邮件。
- 我们希望使用类似 此 使用 UserControls 来模板化电子邮件，我认为这在 ASP.NET 网站之外是不可能的
第一个问题可以通过构建和部署脚本来避免（无论如何我们目前正在研究），但我认为我们无法解决第二个问题。
因此，我们决定的解决方案是拥有一个由 SSIS 定期调用的 ASP.NET 页面，并让它执行一定量的处理（例如 30 秒）然后返回。我知道 ASP.NET 页面不是进行此类处理的理想位置，但这似乎最能满足我们的要求。我们考虑生成一个新线程（不是从工作池）来进行处理，但决定如果我们这样做，我们就不能使用返回的页面来表示成功或失败。通过在页面的生命周期内进行处理，我们可以使用页面内容来指示处理的进行情况。
所以问题是： 此设置是否存在任何技术问题？
显然，如果您尝试过类似的事情，任何成功/失败的报告都会受到赞赏。替代设置的建议也是如此。
干杯，
We need the ability to send out automatic emails when certain dates occur or when some business conditions are met. We are setting up this system to work with an existing ASP.NET website. I've had a chat with one of the other devs here and had a discussion of some of the issues.
Things to note:
- All the information we need is already modelled in the ASP.NET website
- There is some business-logic that is required for the email generation which is also in the website already
We decided that the ideal solution was to have a separate executable that is scheduled to run overnight and do the processing and emailing. This solution has 2 main problems:
- If the website was updated (business logic or model) but the executable was accidentally missed then the executable could stop sending emails, or worse, be sending them based on outdated logic.
- We are hoping to use something like this to use UserControls to template the emails, which I don't believe is possible outside of an ASP.NET website
The first problem could have been avoided with build and deployment scripts (which we're looking into at the moment anyway), but I don't think we can get around the second problem.
So the solution we decided on is to have an ASP.NET page that is called regularly by SSIS and to have that do a set amount of processing (say 30 seconds) and then return. I know an ASP.NET page is not the ideal place to be doing this kind of processing but this seems to best meet our requirements. We considered spawning a new thread (not from the worker pool) to do the processing but decided that if we did that we couldn't use the page returned to signify a success or failure. By processing within the page's life-cycle we can use the page content to give an indication of how the processing went.
So the question is:
Are there any technical problems we might have with this set-up?
Obviously if you have tried something like this any reports of success/failure will be appreciated. As will suggestions of alternative set-ups.
Cheers,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
不要使用 asp.net 线程来执行此操作。如果站点正在生成您创建或触发电子邮件发送所需的一些信息，则让站点将一些信息写入文件或数据库。
创建一个 Windows 服务或计划进程，从该文件或数据库收集所需的信息，并在完全独立的进程/线程上运行电子邮件发送进程。
您想要避免的是由于进程处理程序中的限制而导致您的网站崩溃或电子邮件发送器崩溃。根据您在问题标题中使用“批量”一词，两者需要相互独立。
Don't use the asp.net thread to do this. If the site is generating some information that you need in order to create or trigger the email-send then have the site write some information to a file or database.
Create a Windows service or scheduled process that collects the information it needs from that file or db and run the email sending process on a completely seperate process/thread.
What you want to avoid is crashing your site or crashing your emailer due to limitations within the process handler. Based on your use of the word "bulk" in the question title, the two need to be independent of each other.
我想你应该没问题。我们公司使用类似的方法已经好几年了，并没有遇到很多问题。有时需要一个多小时才能完成该过程。最近我们将第二个线程（正如您所说）移至单独的服务器。
I think you should be fine. We use the similar approach in our company for several years and don’t get a lot of problems. Sometimes it takes over an hour to finish the process. Recently we moved the second thread (as you said) to a separate server.
将电子邮件发送器和网站结合在一起是可行的，但这并不是一个好的设计，而且从长远来看，您需要更多的维护工作。您可以通过做一些事情来解决您所提出的问题。
将通用业务逻辑移至 Web 服务或通用库。您的网站和可执行文件/WCF 服务都可以使用它，并且它集中了逻辑。如果您复制并粘贴代码，您就知道出了问题;)
如果您需要模板邮件程序，则可以调用 ASP.Net 类来动态创建页面（请参阅 BuildManager 类，以及 像这样的博客文章。如果邮件程序不依赖于页面事件（它似乎并不依赖于页面事件） ），您的可执行文件从网站程序集中加载 Page 类、动态构建它并填充内容应该没有任何问题。
这显然意味着大量的工作，但将为您带来更具可扩展性的解决方案。
Having the emailer and the website coupled together can work, but it isn't really a good design and will be more maintenance for you in the long run. You can get around the problems you state by doing a few things.
Move the common business logic to a web service or common library. Both your website and your executable/WCF service can consume it, and it centralizes the logic. If you're copying and pasting code, you know there's something wrong ;)
If you need a template mailer, it is possible to invoke ASP.Net classes to create pages for you dynamically (see the BuildManager class, and blog posts like this one. If the mailer doesn't rely on Page events (which it doesn't seem to), there shouldn't be any problem for your executable to load a Page class from your website assembly, build it dynamically, and fill in the content.
This obviously represents a significant amount of work, but would lead to a more scalable solution for you.
听起来您应该创建一个工作线程来完成这项工作。
Sounds like you should be creating a worker thread to do that job.
也许你应该看看类似 https://blog.stackoverflow.com/2008/ 07/easy-background-tasks-in-aspnet/
Maybe you should look at something like https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
当满足某些业务条件时，您可以而且应该在域逻辑（这意味着您的 ASP.NET 应用程序）中构建消息正文（模板化消息正文），并将其发送到仅发送您的消息的外部服务。所有消息都会有正确的信息。
对于“当某些日期发生时”场景，您可以使用简单的解决方案进行后台任务（查看 Craig 答案）并执行与上面相同的操作：解析模板、构建消息并快速发送到指定服务。
当然，您应该安全地执行此操作，这样应用程序池重新启动就不会中断您的任务。
You can and should build your message body (templated message body) within domain logic (it means your asp.net application) when some business conditions are met and send it to external service which should only send your messages. All messages will have proper informations.
For "when certain dates occur" scenario you can use simple solution for background tasks (look at Craig answer) and do the same as above: parse template, build message and fast send to specified service.
Of course you should do this safe then app pool restarts does not breaks your tasks.