1

私はASP.NETを使用していますが、これはすべての（またはほとんどの）MVCフレームワークに関係していると確信しています。

新しいWebプロジェクトが作成されると、コードの基本的なフォルダー/セマンティック構造が得られます。

  • コントローラー（ブラウザーからのサービス要求）
  • モデル（データの保存と操作）
  • ビュー（HTMLページ）
  • コンテンツ（静的コンテンツ
  • スクリプト（JavaScript）
  • App_Data（データベースファイル）

それは問題ありませんが、ブラウザのリクエストとは別に実行されるコードが必要な場合はどうなりますか？たとえば、リクエストがコードを実行し、別のスレッドで実行し、リクエストが完了した後も実行を継続する場合があります。または、コードがリクエストとはまったく関係なく定期的に実行される場合。

私の場合、コードはデータ（データの生成、クリーンアップなど）で機能するため、モデルに含める必要があると思います。ただし、実際にはデータを「モデル化」するのではなく、バックグラウンドで機能するだけです。この種のもののための意味論的な場所はありますか？

4

1 に答える 1

1

ここでは、MSMQ、RabbitMQなどのキューを利用できます。オフロードする必要のある各リクエストはキューに入れることができ、外部サービスがキューからアイテムをポップして1つずつ処理を開始します。ここではおそらくWCFを使用できますが、サービス自体はプレーンなWindowsサービスである可能性があります。より複雑な処理シナリオのためにワークフローを統合することもできます。私は通常、これらのタイプのプロジェクト用に「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を実装）。

于 2010-12-18T04:47:11.983 に答える