nearly a year ago I underwent the step to walk the SL-path. Meanwhile I'm happy to have done so, since I think SL has much potential to outclass winforms in terms of great UI's. (THAT and not architectural reasons in first line are imho most important for a UI-technology, since UI should present the "window" to our users and are not primarily a dev's- toy )
Working with SL and intentionally ignoring MVVM not to add further stuff to the learning stack, I found myself writing more and more separate classes to which controls are bound beside my CSLA-business objects. You know, classes with properties like 'canProceed' that enable buttons if certain conditions are true and so on. Sounds like a natural way to a VM, doesn't it?
OK, I should give MVVM a try. But a lot of questions arouse, reading the first samples:
1) Who is responsible to trigger things like an animation? Let me give you two samples:
a) a certain BO-property drives the visibility state of an image (via value converter bool->visibility) But as soon as the image is shown, it should pulse let's say 5 times to makes sure the user really sees it. Actual I trigger the animation through code behind (the cause of all evil, I know)
b) I animate appearance and disappearance of views, but not all the same in a standard way but according to actual data. So a detail view of an item in a listbox zooms in (and out, of course) from the position where the item is, not just from the middle of nowhere...
2) BxF (what's with other MVVM frameworks?) has the conception of a shell. OK all SL-apps must have RootVisual, but that doesn't have to be a view. In my case it's a stupid grid. There I load a login-view which doesn't contain anything else but login-related controls. No menu, status or similar. That only comes into play when there was a succesfull login. (Did I mention that since it's a LOB-app, no unauthenticated user-access is allowed?) Furthermore even the loaded views have regions where they can load other (detail)views... From all I read, BxF may be a little to basic?
At the bottom line I ask myself the following question: Is usage of MVVM-pattern (and certain frameworks) capable of supporting UI's that are "heavily designed" or does it restrict UI-design? In case of the second I'll drop MVVM, since this would definitly limit SL's potential.
Thanks for sharong your thoughts!
There are plenty others who can share much better thoughts than I can, but for what it's worth: I did what you did in the past year or two...I began working with XAML-based apps but decided not to jump into MVVM right away. A few months back I decided to read about and learn MVVM concepts, which at first seemed complicated. I would not want to go back. I've talked with and read a number blog entries by some who say MVVM is over-rated or adds too much work without the benfit, but I've never heard that (yet) from someone who uses CSLA. It feels like a great fit. As Rocky has described in his e-book series, CSLA has the concept of a rich model, whereas many other examples on MVVM suposse an anemic model. This makes a huge difference with MVVM.
I have not done a lot with animation at this point, so I can't speak to that. However, I have seen some of Rocky's examples that include basic animation (like the busy indicator) which is easily handled without code-behind. Regarding code-behind, I know Rocky's stated goal is zero code behind. I've done everything I can do adhere to that and have succeeded in most of my views. But I've also read a bit from others who aren't as strict in their desire for getting rid of code behind. Their take is that if code behind is necessary and it doesn't involve business logic, then it isn't completely evil. That is kind of freeing to me.
Finally, regarding MVVM frameworks, I used Bxf for learning and it was great for that purpose. I'm now learning Caliburn.Micro (as I had seen others talk about that here) and so far I like what I see.
Copyright (c) Marimer LLC