Многопоточность в приложении WPF + WCF + Prism
Я начинаю проект - клиентское приложение WPF, которое обменивается данными через WCF WebSockets с некоторой службой. Я также использую фреймворк Prism. Мне интересно, какой способ является правильным способом реализации многопоточности (мне нужно, чтобы пользовательский интерфейс оставался отзывчивым):
- Используйте асинхронные методы службы вместе с ожиданием.
- Вручную создайте новый поток, который будет отвечать за связь между клиентом и сервисом.
Как это:
Thread thread =new Thread(NewClientConnection);
thread.Start(some_arguments);
Я новичок в WPF / Prism, и я боюсь, что у меня могут возникнуть проблемы в Prism, когда модули находятся в разных потоках, не знаю, правильно ли это. Как вы думаете?
Это то, о чем я думал. Итак, вы говорите, что первый вариант правильный, верно? Я не буду блокировать пользовательский интерфейс, потому что для каждого метода службы e.x GetLogins () WCF генерирует сам GetLoginsAsync (), который я могу использовать.
Вам нужна ожидаемая задача, чтобы дождаться ее. То, что закончилось async, обычно бывает таким. Однако это чисто соглашение об именах.
Правильно - WCF может генерировать асинхронные версии ваших методов интерфейса службы в клиентском прокси, но даже синхронные вызовы могут быть довольно безболезненно маршалированы в пул потоков в качестве задачи, без необходимости создавать собственные потоки и управлять ими. Нитки дорогие.
В настольном приложении редко имеет значение, что создание отдельного потока требует больших затрат процессора. Гораздо важнее то, что с помощью async await проще кодировать. Вы просто ожидаете результата вызова в переменной, а затем ваша следующая строка кода может автоматически использовать эту переменную.
Ответы 2
Сделайте вызовы службы асинхронными на стороне клиента.
issues in Prism, when modules are in different threads
Модуль в контексте Prism - это в основном определение сервисов, реализующих интерфейсы. Он живет только для того, чтобы вызвать его метод Initialize, а затем умирает.
Не помещайте какую-либо часть пользовательского интерфейса в поток, отличный от пользовательского интерфейса, потому что это не сработает. В противном случае вы можете поместить службы и прочее в отдельные потоки, если необходимо, но обычно в этом нет необходимости.
Используйте async await.
Лично я бы выбрал wep api, а не wcf, если бы у меня была возможность. Может быть, нет.
Если вы новичок в wpf, я предлагаю вам дважды подумать перед использованием PRISM. В нем много функциональных возможностей, и он очень сложен. Однако большинству приложений все это не нужно.
С PRISM довольно сложно работать. По моему опыту, даже с динамически созданным пользовательским интерфейсом это в значительной степени просто добавляло сложные накладные расходы нашим проектам. Если они хотят по существу определить разные области и разместить в них предметы, тогда вам вообще не нужна призма. Вы можете создать пользовательский интерфейс с помощью xamlreader.parse, чтобы предоставить 1,2,3 или любые другие элементы управления содержимым, которые они хотят в представлении, а затем установить содержимое каждого элемента управления.
WCF не устарел, просто веб-API проще в использовании. Если он делает то, что вам нужно.
Большое спасибо за дополнительную информацию. О Prism: Я хотел попробовать. Это упростит реализацию шаблона MVVM. Кроме того, в моем приложении мне нужно динамически создавать пользовательские элементы управления cusom (пользователь открывает вкладку настроек из главного окна, выбирает настраиваемые элементы управления, которые он хочет видеть в MainWindow, где он хочет их разместить, как он хочет их настроить и т. д. О Web Api, Как вы думаете, почему так будет лучше? Мне нужно простое общение через WebSockets, поэтому я не думаю, что это будет иметь большое значение. WCF все еще законен, я думаю, я ошибаюсь?
Хорошо, я понимаю. Но из того, что я слышал, PRISM - это "легкий" фреймворк, поэтому не стоит ли использовать его в некоторых областях, где он действительно упрощает работу (шаблон mvvm, свойства призмы), а также для других вещей, когда все становится действительно сложным, просто не делайте этого. не использовать это?
PRISM - массивный и тяжелый фреймворк. Есть урезанная версия самородка, которая дает вам всего пару вещей, но MVVMLight - лучший вариант, чем этот. По моему опыту.
В наши дни действительно нет необходимости управлять своими собственными потоками в приложениях пользовательского интерфейса. Вы открываете себя миру боли с синхронизацией потоков и маршалингом обновлений пользовательского интерфейса в поток диспетчера. Вот аналогичный ответ с хорошим советом: stackoverflow.com/questions/26129182/…