[RESOLVED] Shared data and Models Advice

I'm working on a big project(big for me:D), where I've one main window that host 3 usercontrols using a library like avalondock to have an IDE-like apparance like visualstudio.
The app should work like this: the main window is loaded and ask with a openfiledialog to open a binary log file, then this log it's displayed in the 3 usercontrols in differtent way (pie chart,line chart and text), if the user change some value in the text view the other have to reflect it. Then if the user want, he can save the changed log with a savefiledialog.
So, I have more than 4k line of code for each usercontrol now; and things start to be a little messy..
So I'm planing to refactor it. For UI reasons I opted to wpf instead of winform; Now the thing that I would avoid is that:
I defined a shared array in the main window, and then to manipulate it from the usercontrol (placed into the mainwindow), I have to refer it as instance, that is not very readable.
I searched and tryed to implement MVVM pattern using a framwork (test done with caliburnmicro and stylet), but I'm struggling to understand how to share data between VMs. Considering that, test after test I had already rewrite the all project 6 time, I'm looking for some advice to made the code more readable and how structure the app, like use or not user design pattterns like mvvm, etc..
So anyone have any advice?

Without being two specific, the approach I would be inclined to take would be to have a single object that holds the data from the file. It is responsible for getting the data from the file and storing the data back to the file. It would also have events that get raised whenever the data is changed. It sounds like the data is only changed from one of the three user controls, but whether or not that provides any advantages is hard to say. When a change is made to the data, the object should raise an event to indicate this. It could be a very simple 'datachanged' event that has no real information associated with it other than the fact that the data changed. The other controls would handle that event and know to redraw themselves when it happens. Of course, if there is information that could be included in the event that would make it easier for the controls to redraw, then it might make sense to include that information, but it also might not. The controls should be capable of redrawing based on the state of that data object, regardless of what that state is, so there's no point in tying your code in knots to make for a bunch of special cases.

Thanks.

Quote:

---

Originally Posted by Shaggy Hiker

so there's no point in tying your code in knots to make for a bunch of special cases.

---

Are you referring to MVVM ? Sorry for my low level english.

No, I'm not. I'm not all that familiar with MVVM.