3

From what I understand, the ViewModel should only contain validation methods, properties, and Commands. There shouldn't be any programming functionality in the ViewModel.

In my program, I want to start threads when a property changes. For example, every time the user types something in a textbox, a new thread is started. Can I have methods like backgroundWorker1_DoWork, backgroundWorker1_ProgressChanged, and backgroundWorker1_RunWorkerCompleted defined in my ViewModel?

Sergey Vyacheslavovich Brunov
  • 17,291
  • 7
  • 48
  • 81
Leopard81
  • 59
  • 4
  • 2
    Although not entirely clear what your requirements are, but to me it sounds a perfect case to use [Rx](https://msdn.microsoft.com/en-us/data/gg577609.aspx). For example with your textbox text change, check this 2 part blogs on msdn [part 1](http://blogs.msdn.com/b/argumentnullexceptionblogpost/archive/2013/06/21/an-rx-enabled-wpf-control-part-1-2.aspx) and [part 2](http://blogs.msdn.com/b/argumentnullexceptionblogpost/archive/2013/06/21/an-rx-enabled-wpf-control-part-2-2.aspx). Although you don't need autocomplete, but they might illustrate the point of using Rx. – Michael May 26 '15 at 20:46
  • 1
    http://stackoverflow.com/questions/16338536/mvvm-viewmodel-and-business-logic-connection This has an excellent answer by a user called Jon. I'd recommend reading it. – Daniel Lane May 26 '15 at 20:48
  • "_Every time the user types something in a textbox, a new thread is started_" Well, there goes your CPU. Did you mean that a new thread is started which monitors any changes and fires those events? Or events are added to a queue that fires them from a separate thread? – Nic May 26 '15 at 21:02
  • *There shouldn't be any programming functionality in the ViewModel.* Nope. And that's why you have a problem. Also, get with the times. Use Tasks rather than the old hackneyed BackgroundWorker stuff. –  May 26 '15 at 21:09
  • What Daniel Lane referring is [this](http://stackoverflow.com/a/16338888/1977871) – VivekDev Jul 23 '16 at 13:03
  • @Will Then where you put the code? What is the alternative? – Phil1970 Oct 18 '16 at 21:27
  • @Phil1970 Your question doesn't make sense. But your code, you put it *where it makes sense*. Nothing says that place isn't in a view model. –  Oct 19 '16 at 12:57
  • @Will Well as in the original question, I try to figure out what is the best way to have something that run in background and report progress... I have not used WPF much and even less MVVM. You suggest not to put code in ViewModel and to uses Tasks but it would be helpful if you would write a more detailed answer that show how you would do that. – Phil1970 Oct 20 '16 at 15:10
  • Many have given some comments or links... but it would be useful to have a specific answer on either the best way to use a background worker or if you think that alternatives are more appropriates, then a "pattern" on how you would implement something that replace all the functionalities of a background worker (reporting progress, allowing cancellation, allows to return a final result, and allows to detect if some processing is in progress). – Phil1970 Oct 20 '16 at 15:18
  • 1
    @Phil1970 oh, you misread me. Or I was a bit unclear. I quoted the line "There shouldn't be any programming functionality in the ViewModel" and said ***Nope.*** meaning that I disagree with that statement. There are a few good patterns for doing what you ask, including using async/await in the view model to move from the UI context to a worker thread and back again without any difficulty. That's my new fav, which often suggests a layer transition (vm => BLL, which exposes async methods). –  Oct 20 '16 at 15:21
  • I'll pin this and come back to it when I have time, I suppose I could answer with a couple different versions of the pattern... –  Oct 20 '16 at 15:22

0 Answers0