none
Можно ли написать службу Windows на C# и "подстыковать" к ней UI на WPF? RRS feed

  • Вопрос

  • С наступающим Новым Годом всех!

    У меня следующий вопрос. Можно ли написать службу Windows и "подстыковать" или "связать" с ней UI на WPF, что бы через этот UI пользователь мог "общаться" с службой Windows во время её работы? Т.е. чтобы этот UI визуально отображал в своих текстбоксах и гридах данные, обрабатываемые службой. Что бы пользователь имел возможность вводить в UI данные, которые служба, во время своей работы динамически "на лету", могла каким-либо образом брать от туда и использовать в своей работе. Я слышал, что такой подход используется при написании приложений .NET. Говорили, что это сочетает в себе преимущества скорости работы службы и удобства взаимодействия с ней через UI на WPF (т.к. простое оконное приложение WPF по скорсти работы, если есть требования к времени, увы оставляет желать лучшего). И используется ли при построении такого типа приложений шаблон ModelViewViewModel (MVVM)?

    29 декабря 2012 г. 11:30

Ответы

  • Шаблоны можно использовать во всем. Это ответ на последний вопрос, а теперь на главный. Ваша служба и UI должны взаимодействовать по любому из возможных способов. На вскидку я назову 2 (кто то может еще добавит).

    Первый это TCP. То есть используете localhost как завязку для клиент-сервера и любой порт на ваш вкус (не занятый другими програми).

    Второй это каналы. Эту тему мне юзать не доводилось, поэтому конкретных рекомендаций не дам.

    Уверен есть еще способы, но как и сказал выше, чего то больше ничего в голову не идет.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    • Помечено в качестве ответа TownSparrow 29 декабря 2012 г. 14:35
    29 декабря 2012 г. 12:13
    Отвечающий

Все ответы

  • Шаблоны можно использовать во всем. Это ответ на последний вопрос, а теперь на главный. Ваша служба и UI должны взаимодействовать по любому из возможных способов. На вскидку я назову 2 (кто то может еще добавит).

    Первый это TCP. То есть используете localhost как завязку для клиент-сервера и любой порт на ваш вкус (не занятый другими програми).

    Второй это каналы. Эту тему мне юзать не доводилось, поэтому конкретных рекомендаций не дам.

    Уверен есть еще способы, но как и сказал выше, чего то больше ничего в голову не идет.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    • Помечено в качестве ответа TownSparrow 29 декабря 2012 г. 14:35
    29 декабря 2012 г. 12:13
    Отвечающий
  • Спасибо, LXGDARK. Я сам такими вещами (написанием службы Windows и приделыванием к ней UI на WPF) ещё не занимался, вот только буду пробовать. Хотел бы уточнить - я предполагаю, что и служба Windows и UI на WPF к ней работают на одном и том же компьютере. Так что здесь подойдёт TCP как способ взаимодействия между ними? Там же предполагается использование сокетов. А это тоже для меня новая область, поэтому и спрашиваю.
    29 декабря 2012 г. 12:33
  • Как я и написал если мы в качестве имени сервера используем localhost то это подразумевает что взаимодействующие приложения находятся на одном компьютере. К слову это один из способов связи между обычным приложением и приложение WinRT на одном компьютере.

    Пробуйте примеры из ссылки, что я вам дал с использованием localhost. Сможете понять принцип.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    29 декабря 2012 г. 12:37
    Отвечающий
  • Посмотрю обязательно. Хочу ещё спросить - если к работе приложения предъявляются жесткие временные требования, т.е. важна скорость, то описанная выше конфигурация - служба Windows, взаимодействующая с пользователем через UI на WPF - подойдёт? Я просто недавно написал оконное приложение WPF - робота для торговли на фондовой бирже - и скажу, что работает медленно. Мне в нём, в частности, нужно выводить графики и информацию в гридах для пользователя. И конечно, что б он быстро делал вычисления. Это кроме всего прочего - многопоточное приложение. Вот сейчас стою перед дилеммой - что для написания такого приложения лучше предпочесть. Писать его в .NET Framework в виде службы Windows, взаимодействующей с пользователем через UI на WPF или же писать его как приложение неуправляемого кода, например, диалоговое приложение MFC?


    • Изменено TownSparrow 29 декабря 2012 г. 12:58
    29 декабря 2012 г. 12:54
  • Если вы хотите написать то же самое приложение по работе с биржей, но хотите увеличить скорость за счет разделения на службу и UI, то вы ничего не добъетесь. Медленно ваше приложение работало вероятно всего из за плохой оптимизации графики, а не из за того, что у вас один процесс делает всю работу.

    UI для службы создают, когда основную часть времени службе не нужно участие пользователя (потому она и служба), а участие возникает только если службу нужно настроить или посмотреть отчет работы за период. Для постоянного взаимодействия в он-лайн режиме она не подходит.

    Если ваш вопрос в том, что ваше приложение на WPF работало медленно, то вам нужно вплотную заняться изучением всего, что связано с повышением производительности и оптимизацией работы с большим объемом векторной графики. Начать можно отсюда.

    P.S. Если этот ответ вас удовлетворит, то не стоит его помечать как ответ, так как к первоначальному вопросу он мало относится. Либо поменяйте первоначальный вопрос.


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    29 декабря 2012 г. 13:03
    Отвечающий
  • Я извиняюсь, что несколько отвлекаюсь от темы, но хотел бы узнать, если хорошо оптимизировать исходный код оконного приложения WPF, то его можно использовать как приложение реального времени, когда речь идёт о единицах миллисекунд. Если, скажем, расчётную часть я построю с использованием библиотеки TPL (т.к. процессор многоядерный), а вывод графиков с использованием класса Visual?

    29 декабря 2012 г. 13:58
  • Да можно. С появлением WinRT она стала приоритетом и о WPF говроят мало, но вы удивитесь если увидите какие приложение делаются на данной платформа. Например Blend и VisualStudio 10/12 написаны на нем, а так же известный на весь мир 3D редактор (не помню название).

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


    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    29 декабря 2012 г. 14:03
    Отвечающий
  • Я прошу прощения - а что такое WinRT? Это ещё один вид приложений .NET, как, например, WPF, WindowsForms и.т.д.?
    29 декабря 2012 г. 14:14
  • Я прошу прощения - а что такое WinRT? Это ещё один вид приложений .NET, как, например, WPF, WindowsForms и.т.д.?
    Да. Это новый тип приложений для Windows 8.

    Женат на WPF. Тайно встречаюсь с WinRT. Не сложилось с C#!

    29 декабря 2012 г. 14:18
    Отвечающий
  • Хорошо. Спасибо за помощь.

    29 декабря 2012 г. 14:34