.Net CF Running Thread на время жизни приложения - PullRequest
Новая
       14

.Net CF Running Thread на время жизни приложения

2 голосов
/ 28 апреля 2009

Я занимаюсь разработкой приложения .Net Compact Framework на C #, в котором используется некоторое стороннее программное обеспечение для организации очередей сообщений, установленное на устройстве.

Я довольно новичок в этой среде, и мне было интересно, смогу ли я пропустить несколько ключевых концепций архитектуры через несколько умных глаз, чтобы увидеть, нахожусь ли я на правильном пути или как это можно улучшить.

Пока мое приложение работает, мне нужно, чтобы библиотека очереди сообщений работала в фоновом режиме, чтобы она могла генерировать уведомления и информировать мое приложение о любых входящих сообщениях и обрабатывать сообщения, которые генерирует мое приложение. Оно должно выполняться в течение всего срока службы моего приложения, поэтому я думаю, что лучший способ сделать это - запустить его в своем собственном потоке при запуске моего приложения?

Я не хотел наполнять этот пост кодом, поэтому я добавил разделы, которые я считаю важными, пожалуйста, дайте мне знать, если мне нужно уточнить больше.

Я запускаю процесс обработки сообщений в отдельном потоке, когда приложение запускается следующим образом: 

[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, чтобы продолжить и отвечать на другие уведомления и сообщения.

Выглядит ли это разумным подходом и обеспечит ли моя библиотека очередей сообщений возможность обрабатывать отдельно от моего приложения?

Любой совет будет принят с благодарностью, спасибо за ваше время.

Ответы [ 2 ]

0 голосов
/ 28 июня 2011

Кажется вполне разумным. Я сделал это немного по-другому в реализации, так как я обычно использую DI-фреймворк, но концепция была бы той же. Единственное, что я хотел бы добавить, это установить для свойства IsBackground потока значение true.

.
0 голосов
/ 28 июня 2011

Концептуально это правильный выбор, чтобы поместить его в отдельную ветку.

Есть несколько условий, когда фоновый поток может перестать работать:

  1. все приложение закрыто (получено сообщение WM_CLOSE)
  2. исключение было сгенерировано и не перехвачено в контексте фонового потока
  3. операционная система должна завершить работу всего приложения из-за ограничений памяти

В своем коде вы можете запретить только условие номер 2.

С другой стороны, если вам нужна идеальная изоляция, вы можете написать службу Windows и установить ее на устройство. Но я не думаю, что .NET CF сервисы изначально доступны. Однако есть некоторые реализации , которые можно использовать для преодоления этого препятствия.

Другой способ - создать отдельное приложение с этим циклом и скрытым главным окном.

...