As you might have noticed on my blog, I like working with Silverlight, and I like using the MVVM pattern when I do so. As a part of this, I generally create design time ViewModels to get the best help from the tools (VS and Blend). VMs
The annoying thing about this, is that project containing the design time information need to be referenced by the application for the whole thing to work. But when the app is built and released, I really don’t want the extra ViewModels to be included in the xap file. I guess, in most cases, they are fairly simple and small, making the xap bloat minimal. But it still feels wrong. And it feels even worse when your design time VMs become large due to embedded resources such as images and data…
More...
In my last post I wrote about how I had created a ViewModelLocator that was a bit different from what everyone else was using. I had come up with the awesome idea to use the same VMs at design-time as I used at run-time. This idea sounds very good, as it means that I only needed to build a single set of VMs and instead could switch the service implementations using DI. At the time, it sounded like the most “correct” solution. Little duplicated code, no chance of messing up the bindings and so on…but it has a huge problem…
More...
[UPDATE] This post is somewhat interesting, but the idea doesn’t really work in the real world. More info HERE [/UPDATE]
I have tried to stay out of certain areas when I blog. Why? Well, simply because some things are still heavily debated, and some debates even seem a bit infected. Some topics seem to cause people to get somewhat rabid and I don’t feel like causing a big flame war of any kind. But still, I have decided to talk a bit about some of the options we have when binding our views to our viewmodels, or vice versa. I can’t even write that with out having to be careful…
More...