我们有一个带有SQL Server 2005后端的.NET电子商务应用程序。新订单需要某些“后处理”。这些任务包括发送电子邮件，创建文件，将文件上传到FTP服务器以及对WCF数据服务执行CRUD操作。作为几个.NET类库，已经执行了所有这些任务的代码。
我的团队正在进行的辩论是在哪里放置此代码。我编写了一个简单的Windows服务，该服务会定期轮询数据库，并且在检测到数据库中的新事务(基于标志)后，它将执行必要的操作并记录任何错误。已提出的替代方法是将启动处理的SQLCLR INSERT触发器。
我知道在SQLCLR中完成以上所有任务在技术上是可能的-我什至已经找到了许多文章来解释如何在SQLCLR中使用Web服务，因此显然人们正在这样做。但是我仍然犹豫。 SQLCLR是否曾经打算用于这种事情吗？如果没有，实际的不利之处是什么？至于SQLCLR触发器对Windows服务的潜在好处，我只能看到一个:更少的数据库流量。我们期望最初的交易量很小，因此Windows服务将产生一些“浪费”的流量。但是该服务与数据库位于同一盒子上，因此它甚至不会影响网络，而只会影响内部服务器资源。
最后，第三种可能性是使用SQLCLR触发器在文件系统上保存一个简单的 token ，然后在Windows服务(而不是Timer)中使用FileSystemWatcher来执行所需的任务。
请分享您对这些不同方法的取舍的想法，或提出更好的选择。
最佳答案
在查看类似过程时，我们考虑了一些事项。
我们之所以选择使用Windows服务，是因为它为那些将支持该系统的人(将更多的时间花在serverfault而不是stackoverflow上的人们)提供了最佳体验。由于它具有停止和启动服务的既定方式，因此可以进行监视，集群支持，易于将处理拆分到多台计算机，与事件日志集成等。
关于.net - SQLCLR触发器与Windows服务。什么时候使用SQLCLR？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/3963134/