XAML (Silverlight & WPF) complex UI composing with MVVM [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I'm beging to work on a re-design (software design) of XAML-based application, I wrote 2 months ago. I think I made lot's of architectural mistakes during development, which led to situation when the UI part of app is hard to extend, maintain, code is hard to understand. My app is written using PRISM 4 in MVVM style, but despite the fact that Prism was invented for modular design my App turned out to be very monolithic. I'm going to continue to use PRISM 4 in new design, but this time I want to break my UI part of application in smaller, reusable, extendable building blocks.

Suppose we are designing data input form.Top container contains Save,Cancel buttons and TabControl, which contains 2-3 tabs that contain lot's of grouped input controls.

The are 2 completly different aproaches to UI design I can see: static (compile-time), dynamic(run-time). Static it's when you predefine your UI before compiling, i.e DataGrid with columns defined in XAML. Dynamic it's when you compose UI at runtime, i.e you defined DataGrid in XAML but add columns at runtime based on user asctions.

What rules you use when you decide which aproach to use, sattic or dynamic? What you would choose in this particular example?

Next big question is how to break UI to pieces.

What rules you use when you define UserControls, how you would define UserControls for this example form? Now about ViewModels, would you create single VM for this example form or multiple (explain)? What do you think about situations when ViewModel contains other ViewModels (not simple wrapers around model, but real VM which contains logic).

And now the hardest question at least for me. Extending UI building blocks (UserControls and ViewModels).

Situation when you need to create a copy of some Form but with slightly different interface and|or logic is quite often, especially when you need to integrate authorization (permissions) in UI. Suppose we need to support slighly differ开发者_JS百科ent version of out example form (doesn't matter how many exactly versions, suppose 2-6).

I can think of these aproaches to solve this problem:

1. Create duplicates of whole from (usercontrols and viewModels) and modify them (the static way). The good thing all variants are independent, great flexibility, no dependecies, the bad thing code duplicate, if you will need to change something in all variants most likely you will have to modify this everywhere, especially with ViewModels.

2. Conditional presentartion, you add lot's of conditional code to your ViewModel, like IsThisVisible, IsThatDisabled (the dynamic way). The good thing maximum code reuse, the bad thing code bloat and mess. Your code will be hard to understand,maintain.

3. Break UI to very small atomic UserControls, compose separate form variants from this UI pieces, and use ViewModel inheritance with virtual members and overrides. I haven't ever used inheritance of ViewModels, and would like to hear your opinion on this subject.

n. Other aproaches I can't think of.

---

In my experience, the development path tends to work this way:

1. Design a view in Blend or Kaxaml or whatever, and a view model that backs the view.
2. Realize that portions of the view need to be dynamic. Implement flags in the view model and styles in the view to show/hide them.
3. Realize that all the flags are getting out of hand. Get rid of the flags, and refactor the view to present collections of user controls, and the view model to dynamically populate collections of view models.

It sometimes happens that I know well in advance that I'm going to need to use approach #3, and I design for it from the start.

But one of the beauties of WPF and MVVM is that even if I don't design for this from the start, it's not too hard to move in that direction if circumstances demand it. Refactoring a bunch of view model properties into a single collection of view models doesn't take a whole lot of time or effort once you've done it a few times.

I can tell you this, though: making a copy of a XAML object and editing it makes klaxons sound in my head. It's possible to imagine circumstances under which that might be OK, but it's not the way to bet.