メールキューをアプリケーションプールで実行するのは間違っていますか？

Question

自動メールを送信する必要があります。彼らは確実にディスパッチする必要があるので、データベースに書き込んでいます。同時に、Application_Startで開始されたSystem.Threading.Timerは、30秒ごとにメソッドを呼び出してデータベースから読み出し、送信されたエントリを削除して送信します。これは長時間実行されるタスクとしては発生しません。 db-queueをクリアするプロセスが非同期メソッドを使用するように注意が払われているので、送信/キューイングのフェーズはブロックされず、プロセス全体がshort-livedメソッドで実行されます（ThreadPool）。アプリリサイクルのコストも最小限に抑えられます（おそらく、1つのメールを再送することになります...問題ではありません）。

従来の知恵は、Webアプリケーションでこれを実行するとそれほど良くないと言い、サービスにこれをスピンアウトする必要があります。

書き込みサービスはPITAです。私はむしろそれを避けたい。だから私はなぜ私は効率的な非同期メールキューを私のアプリケーションプールで実行しないでください？誰でも私を啓発することはできますか？

Answer 1

サイトが使用されていない場合、アプリケーションプールは開始されず、メールは送信されません。

Answer 2

ライティングサービスは、私はそれは主観的だと思いPITA

です。しかし、それをサービスに入れることは有益だろうと思いませんか？実装を変更したい場合は、私の経験では、より小さい個別のコンポーネントを維持するのがずっと簡単です。あなたがすべてのものを1つの場所に持っていると、それは通常PITAになります。

すでに電子メールをデータベースに書き込んでいます。単にデータベースをスキャンして電子メールを送信するシンプルなWindowsサービスを作成するのは非常に簡単です。私はこれが理想的ではないかもしれないことは知っていますが、SOや他の場所に浮かんでいる多くの例があります。あなたはすべてのファンシーを取得し、ESBを使用する必要はありません（あなたがしたい場合を除きます）。

最終的には、はの場合がありますので、とする必要はありません。コストとメリットを比較検討する必要があります。