Использование MFC в службе Windows? - PullRequest
Новая
       34

Использование MFC в службе Windows?

5 голосов
/ 22 июля 2009

Я начинаю разрабатывать службу Windows. Я хочу использовать некоторые собственные классы, которые мало зависят от некоторых классов MFC, таких как CString, CSocket, CArchive, CMemFile и CObject. MSDN говорит, что вам нужно быть очень осторожным в отношении того, какие части MFC вы используете в службе Windows, но не указывает их и не описывает проблемы, которые могут возникнуть.

Мои вопросы:

  • какие кусочки MFC можно использовать?
  • Какие проблемы можно ожидать при использовании MFC?
  • какие части службы Windows являются критически важными для использования MFC?
  • Желательно ли использовать ATL вместо службы MFC for Windows?

Ответы [ 3 ]

4 голосов
/ 22 июля 2009

Я не уверен, что они имеют в виду в статье MSDN. Пока вы не используете какую-либо функциональность графического интерфейса, все будет в порядке - но это общая проблема проектирования при разработке сервисов.

При этом ATL обладает функциональностью, специально разработанной для создания сервисов IIRC, поэтому вам будет лучше использовать ее.

Чтобы ответить на ваши вопросы (насколько мне известно):

1) те, которые вы указали, не являются проблемой.

2) Полагаю, они имеют в виду проблемы с синхронизацией компонентов пользовательского интерфейса. Пока вы не используете какие-либо CWnd-производные классы, все будет в порядке.

3) не понимаю вопроса.

4) Смотрите раньше, плюс ATL более легок, поэтому вам придется распределять меньше и предоставляет встроенную функциональность, которая облегчит разработку службы. Смотрите, например CAtlServiceModuleT. Вы по-прежнему сможете в основном использовать свои собственные классы, поскольку CString в настоящее время используется совместно с MFC и ATL, а ATL имеет классы для программирования сокетов и отображения файлов памяти. У него нет эквивалента для CArchive, и я не уверен, какую функциональность вы используете в CObject, поэтому я не могу сказать, есть ли аналог в ATL. Итак, в заключение я бы сказал «да» на этот вопрос.

3 голосов
/ 19 августа 2009

(я знаю, что этот ответ немного запоздал, и на этот вопрос уже был дан ответ, но MFC в сфере услуг - это больное место для меня ...)

CSockets, насколько я помню, требует окно . Это делает невидимым на заднем плане. Я обнаружил, что это трудный путь, когда я попытался включить какой-нибудь существующий код MFC в службу Windows. Может быть, это было необходимо, только если вы приняли сокетное соединение - я не могу вспомнить? Но это не сработало! (Сколько именно я потратил столько времени на выполнение этого без осознания этого ограничения - длинная история)

CObject? Если вам нужны вещи с идентификатором класса среды выполнения, используйте RTTI (dynamic_cast и т. Д.)

CString, мне нравится CString, я знаю, что он теперь используется совместно с ATL, не уверен, что вы используете его без MFC или ATL ... Вы можете использовать std :: string. Кроме того, я помню, кто-то создал производную std :: string, которая предоставляла те же методы, что и CString. (РЕДАКТИРОВАТЬ: нашел код - человек !! это взрыв из прошлого ...)

CArchive, CMemFile: они вам действительно нужны?

В любом случае, как сказал Роэл, ATL может быть более полезным. Я бы не использовал MFC в серверном приложении (никогда!) ATL? Может быть. Если мне нужен COM, вызывающе. Нет COM, но для CAtlServiceModuleT и т. Д. ... возможно ....

0 голосов
/ 02 марта 2010

И еще одна плохая вещь о MFC в сервисах, с которой я только что столкнулся при попытке превратить обычное приложение MFC-ATL в сервис: использование AfxConnectionAdvise () фактически бесполезно без процедуры Window. Потоки в моем сервисе - это просто обычные темы без сообщений. Я считаю, что именно поэтому я никогда не получаю события с другого разработанного мной COM-сервера. Этот другой COM-сервер зависает в Fire_xxxEvent (), вызывая большой беспорядок во всей системе.

...