2

デバイスにインストールされているサードパーティのメッセージ キューイング ソフトウェアを利用する C# で .Net Compact フレームワーク アプリケーションを開発しています。

私はこの環境にかなり慣れていないので、アーキテクチャのいくつかの重要な概念を実行して、正しい軌道に乗っているかどうか、またはどのように改善できるかをより賢明な目で確認できるかどうか疑問に思っていました.

アプリケーションの実行中は、メッセージ キュー ライブラリをバックグラウンドで実行し続ける必要があります。これにより、通知が発生し、受信メッセージがアプリケーションに通知され、アプリケーションが生成するメッセージを処理できるようになります。アプリケーションの存続期間全体で実行する必要があるため、これを行う最善の方法は、アプリケーションの起動時に独自のスレッドで実行することだと考えていますか?

この投稿をコードであふれさせたくなかったので、重要だと思われるセクションを追加しました。さらに明確にする必要がある場合はお知らせください。

このようにアプリケーションが起動すると、別のスレッドでメッセージ プロセスを開始します。

[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 を介して別のスレッドでイベント処理を管理しています。これは、他の通知やメッセージに継続して応答するためです。

これは合理的なアプローチに見えますか? また、メッセージ キューイング ライブラリがアプリケーションから分離して処理できるようになりますか?

アドバイスをいただければ幸いです。お時間をいただきありがとうございます。

4

2 に答える 2

0

完全に合理的なようです。私は通常 DI フレームワークを使用するため、実装では少し異なる方法で行っていますが、概念は同じでした。追加したいことの 1 つIsBackgroundは、スレッドのプロパティをに設定することtrueです。

于 2011-06-28T14:00:42.930 に答える