CODEWITHSUNDEEP
wpfmvvmnavigation
athos
athos

Reputation: 6425

How to design a flexible navigation logic in a MVVM project?

I'm designing a project using MVVM pattern, so WPF, binding, etc. are used.

Now, the problem is, requirement of navigation layout and logic keeps on changing. Today the navigation logic is hard-coded in ViewModel by bindings. I'm wondering, is there a good design pattern can make this easy?

For example, there's a horizontal bar on the top as 1st level navigation, then a vertical Accordion control on the left as 2nd & 3rd level navigation, and some CollapsiblePanels on the main area as 4th level navigation.

Whenever any navigation element is clicked, a ViewModel property is set, so that binding triggers Views refresh.

Our requirement guys keeps on changing ideas on how a business logic part (take it as a user control) shall be on 1st, 2nd, 3rd, or 4th level: Yesterday UserControlA might be inside a CollapsiblePanel, so it's a 4th level navigation; today it may be promoted to a 2nd level item, due to some users' request.

I won't blame requirement engineers, as it shall be possible to design a delicate navigation framework in a MVVM project, to make the GUI layout change easy, or even configurable.

Any suggestion? Code samples are most welcome!

Upvotes: 0

Views: 369

Answers (1)

stijn
stijn

Reputation: 35901

You should have a look at Prism in combination with MEF or Unity. Together they allow you to write modular applciations which sounds exactly what you are looking for. Basically what you'll do is

  • create stand-alone controls that know nothing about each other nor where they end up in the layout. You create UserControlA, UserControlB etc and their corresponding viewmodels.
  • communicate between the VMs using an EventAggregator/Mediator of choice. These are handed to the VMs using dependency injection (that's what MEF/Unity do)
  • you create a main layout that does not contain any concrete controls, just empty spaces called regions. These are identified by a name.
  • then, at a single point somewhere in code, xaml or even a configuration file, you link everything together by saying 'region with name A needs a control of type UserControlA'. Now if the requirement changes, you just change that single line so that UserControlA now goes into region AA. Nothing else in the application changes.

It does require some studying to get used to it, but in the end it is worth it. Since I started using Prism I never looked back.

Upvotes: 1

Related Questions