I’m a C# developer who hasn’t had the privilege of learning WPF yet. However, I recently initiated the architecture phase of a new project which I expect will eventually employ WPF (probably; although ASP.Net is still an option) — but the GUI development won’t begin for several months. (We need to get buy-in on a WinForm-based proof-of-concept before we proceed with full production-grade development.) When we are ready to begin implementing the GUI, I will either learn WPF myself or hire someone with experience (preferably both).

So my question is, what are some key fundamentals (design patterns, language essentials, etc) that I could employ right away which would facilitate a smoother migration down the road? For example, my code is a simulation model which will contain a very large number of entities that will eventually need to be “visualized”, with interactive user-controls. Are there certain techniques that, if implemented from the ground up, would make wiring up these objects with WPF less painful later on? (Like dependency properties, or what-not.) Similarly, if I stick with the MVC approach that I am familiar with for right now, will it be straight-forward to morph that into an MVVM strategy later? Are there some simple concepts that I could apply now that would make the migration easier, but which won’t take two weeks out of my current dev-cycle to master?

Basically, I am trying to follow Uncle Bob’s advice to postpone architectural decisions (in this case, the GUI layer) until I absolutely have to make them. But I want to know if there are any unnecessary migration costs that I could avoid if I anticipate them in advance.