IHandle marker interface needed?

First of all thanks for your great work!

I wonder if you guys can get rid of the IHandle marker interface if you query the generic IHandle<T> interfaces in this fashion:

var interfaces = handler.GetType().GetInterfaces().Where(x => x.IsGenericType && x.GetGenericTypeDefinition() == typeof(IHandle<>));

Or do i omit something?

[jonnybi]

I personally like the convention over configuration approach most new frameworks follow.

But for me there are drawbacks. All developers are forced to dive deeper into the frameworks too fully understand what’s going on (that’s maybe not a drawback but not all developers on a team are always willing to do this).

If you use multiple of these frameworks you most likely have one or many aspects in your viewmodels that are “hidden”.

For example Fody PropertyChanged moved away from the ImplementPropertyChangedAttribute and as a convention every class that implements INotifyPropertyChanged is automatically weaved. But I like these attributes because they make code more readable.

If caliburn moves away from the handle interfaces and other frameworks follow this approach you have to have a high awareness which frameworks are used in your project. Because an accidently chosen method name could have a huge impact.

I think a good example is the Startup class in asp.net core projects. There is convention used too but the startup is used only for a single purpose and there are only the conventions of a single frame-work you have to know. But in viewmodels you most likely will hit multiple aspects…and then it’s getting messy…

But maybe with developers getting more and more used to the approach these apprehensions will disappear.

[nigel-sampson]

I don’t think I want to head down the convention over configuration approach too much for a lot of reasons above. It can cause too much confusion about what’s actually happening under the covers.

We see this already a little with the binding / action conventions the framework already has and I’m not sure doubling down on it is the right idea.

The Fody example is a great one because my understanding is a little different than above in that Fody automatically added weaving to classes already implementing INotifyPropertyChanged and you needed to opt out using a different attribute. ImplementPropertyChangedAttribute was only ever required on classes that wanted weaving but didn’t already implement the interface.

At the moment I’d like to concentrate on things like

• Removing IHandlle if it’s not being used, as I write this I can think of one reason why it may need to stay.
• Providing subscriber options for thread dispatching.
• Considering adding some async love.

At the same time making sure we don’t stand in the way of letting people layer conventions down on top of this in a way that makes sense for them.