MVVM pattern for flowchart designer implementation

I'm new to WPF and after glancing thru this article,

MVVM-Pattern for a Diagraming Application with WPF - Convert enum to xxxViewModel

I like to know if MVVM could be used or encouraged to use for a simple app that I like to try:

• The simple app is a WPF flowchart designer that allows user to add icons to the canvas such that they are related to one another.

Also, I'd like to know how developers implement the code-behind where the active node is highlighted after a short time duration in a while loop.

suppose there are 3 nodes in the app after drag and drop.

time                active node 
1st-5ths              A
6th-10th              B  (active node moved from A t开发者_开发技巧o B)
11th-15th             C  (active node moved from B to C)
16th-20th             A  (active node from C to A because of while loop link)

Is this a good fit for MVVM pattern use?

Thanks

---

What MVVM comes down to is two major components:

• Maintenance
• Testability

The core benefits you get from the MVVM pattern are:

1. Everything MVP / MVC brings to the table
2. Your view model (logic behind your views) are easily testable because you can instantiate them outside of the context of the WPF/Silverlight/ASP/Whatever system (since they're essentially POCO.
3. Your logic is separates so you can easily hot-swap out the logic behind a view using IoC/DI or just plain using a different model. One line code-change and your entire behaviour changes.

There's quite a lot of overhead that goes into designing your application around MVVM, and personally I wouldn't recommend it for small apps as it can likely double your development time.

However if you expect to be constantly maintianing / upgrading / expanding your app and need to unit test the ui functionality, it's invaluable. It can save you immense time on a large ui refactor if you took the time to set it up correctly at the start.

I know this may not answer your question specifically, but I feel these points are more relevant to chosing the MVVM pattern.

Note: remember MVVM are guidelines, not the rule, you're allowed to break it where it makes sense to, just remember to think of the implications of doing so