0
votes

I've been studying Catel framework for few days, considering moving to it from Caliburn Micro + Castle Windsor.

My application has a set of different screens which should be available through tabs in TabControl. Also, application has different configurations which define a set of these screens - so the set of screens varies.

Each screen is a pair of View and corresponding ViewModel following the MVVM pattern. In previous project I used Castle Windsor as IoC container, which allows to register multiple classes as interface implementations and provides a way to resolve all created objects as a collection of this interface type.

For example, I have Screen1VM : IScreen, Screen2VM : IScreen and Screen3VM : IScreen. I register all these 3 classes as implementations for IScreen and then in constructor of TabControlVM, which manages these screens, I provide a parameter screens of type IEnumerable<IScreen>. After executing a program, Castle Windsor injects instances of classes that implement IScreen interface into this parameter (that say, instances of type Screen1VM, Screen2VM and Screen3VM). If I want to have another configuration of screens, I simply register another classes as implementations of IScreen.

So I wanted to ask if Catel provides such or similar functionality, because I didn't find that in Catel documentation.

And bonus question: does Catel provide some service that allows ViewModels to communicate with each other without having references to each other (in other words, something like EventAggregator in Caliburn that allows classes to subscribe to events and publish them)?

1

1 Answers

0
votes

Catel provides all of this out of the box.

  1. For a tabbed interface example, please check out the TabControl from Orc.Controls and the Catel docs

  2. You can register the same interface with different implementations using tags. This means you can register IScreen with Screen1VM with a specific tag, etc. However, we recommend that you let Catel take care of this resolving for you using naming conventions (again, please see the examples at step 1).

  3. Catel supports the IMessageMediator which is something similar. However, we think you should store application state in services because you should not assume the lifetime of view models. Therefore we recommend updating the state in a service and let every view model update based on events coming from this shared (long-living) service. The good thing with Catel is that you can subscribe to events using InitializeAsync and unsubscribe using CloseAsync so you will not leak your view models.

Bonus

  1. A few example apps written with Catel:

  2. Check out all the other components based on Catel: http://opensource.wildgums.com/