2009-04-28 10 views
2

私はC#でデバイスにインストールされているサードパーティのメッセージキューソフトウェアを使用して.NET Compact Frameworkアプリケーションを開発しています。.Net CFアプリケーションの存続期間中にスレッドを実行

私はこのような環境にかなり新しいですし、私は右のトラックまたはどのようにそれが改善される可能性の午前かどうかを確認するためにいくつかの賢明な目を過ぎアーキテクチャのいくつかの重要な概念を実行することができればと思いまして。

私のアプリケーションは、私はそれが通知を上げ、私のアプリケーションが生成するすべての受信メッセージとプロセスメッセージの私のアプリケーションに通知することができるように、バックグラウンドで実行中のライブラリをメッセージキューイングを維持する必要が動作している間。私のアプリケーションの生涯を通して実行する必要があるので、私はアプリケーションを起動するときに、これを行うための最善の方法を独自のスレッドで実行することを考えていますか?私はコードでこの記事をあふれさせることを望まなかった

ので、私は私が重要だと思うのセクションを入れている、私はより多くを明確にする必要がある場合は私に知らせてください。アプリケーションは、このように起動したときに

私は別のスレッドでメッセージ処理を開始し、

[MTAThread] 
static void Main() 
{ 
    //Run the message processor in its own thread 
Thread messagingThread = new Thread(new ThreadStart(msgProcessorStart)); 
messagingThread.Priority = ThreadPriority.Highest; 
messagingThread.Start(); 

….. 
Application.Run(splashForm); 
} 

private static void msgProcessorStart() 
{ 
MessageProcessor.Start();      
} 

MessageProcessorは、相互作用を簡素化し、それの単一のインスタンスを維持するためのメッセージングライブラリオーバーファサードです。私はその下にその一部を掲載しました。配信不能イベントを発生させ、メッセージがいつ受信されるかを通知します。

public static class MessageProcessor 
    { 
     #region Declarations 

//private static reference to the MessageProvider as specified in the configuration files. 
private static readonly IMessageProcessor _messageProcessor = MessageAccess.MessageProvider; 

     #endregion 

     #region Constructor 

     /// <summary> 
     /// Static constructor, connects to the events on the messageProcessor instance which 
     /// relate to messages received, notifications received and exceptions raised. 
     /// </summary> 
     static MessageProcessor() 
     { 
      //Connect up events specifed on the IMessageProcessor interface. 
      _messageProcessor.MessageReceived += messageReceived; 
     } 

     #endregion 

     #region Public Methods 

     /// <summary> 
     /// Sends a request based data message. 
     /// </summary> 
     /// <typeparam name="T">Message which implements RequestBase</typeparam> 
     /// <param name="message">The message to send</param> 
     public static void SendMessage<T>(T message) where T : RequestBase 
     { 
      _messageProcessor.SendMessage(message); 
     } 

     /// <summary> 
     /// Starts the Message Processor. 
     /// </summary> 
     /// <returns>bool, true if started successfully.</returns> 
     public static void Start() 
     { 
      _messageProcessor.Start(); 
     } 

     #endregion 

     #region Private methods 

     //Registered listener of the IMessageProcessor.MessageReceived event 
     private static void messageReceived(object sender, MsgEventArgs<IMessage> message) 
     { 
      ThreadPool.QueueUserWorkItem(new WaitCallback(processMessage),(object)message.Value); 
     } 


     //Invoked via messageReceived. 
     private static void processMessage(object msg) 
     {    
      //process the message 
     } 

     #endregion 
    } 

Startメソッドが最初に呼び出され、セッションが確立されます。通知を受け取り、メッセージを送信できるようになります。

メッセージを受信した場合、私は現在、継続して他の通知やメッセージに対応するためには、ThreadPoolのを経由して別のスレッドでイベント処理を管理しています。

これは合理的なアプローチを見ていますし、それは私のメッセージ・キューイング・ライブラリは自分のアプリケーションから分離して処理することができるようになりますことを保証しますか!

あなたのお時間をいただき、ありがとうございました。

答えて

0

概念的には、別のスレッドに入れるのが正しい選択です。

は、バックグラウンドスレッドが動作を停止することができ、いくつかの条件があります。

  1. 全体のアプリケーションが閉じられました(受信WM_CLOSEメッセージ)
  2. 例外がスローされ、
  3. オペレーティングシステムが持っているバックグラウンドスレッドコンテキストでキャッチされていませんでした

コードでは、条件番号2のみを防ぐことができます。

一方、完全な分離が必要な場合は、Windowsサービスを作成してデバイスにインストールすることができます。しかし、ネイティブに.NET CFサービスが利用できるとは考えていません。しかしながら、この障害を克服するために使用できるいくつかの実装out thereがあります。

もう一つの方法は、そのループと隠しメインウィンドウで別のアプリケーションを持つことです。

0

完全に妥当と思われます。私は通常、DIフレームワークを使用しているので、少し違って実装しましたが、コンセプトは同じでした。私が追加することの1つは、スレッドのIsBackgroundプロパティをtrueに設定することです。

関連する問題