Extensibility

Jul 19, 2010 at 10:04 PM

Great work on Caliburn Micro, I have more of design question more than a problem and thought it would make an interesting discussion.

 

One of the differences I noticed between Caliburn and Micro was that a lot of the functionality such as ViewModelBinder and ViewLocator has shifted to static classes with the major methods being publicly assignable delegates (I'm assuming so you can override behavior if required).

 

Can I ask the reasoning for this change and your thought process about it as I haven't seen this pattern before.

 

Cheers

Coordinator
Jul 20, 2010 at 12:45 AM

Basically, if I took the standard approach of creating interfaces for all the services + default implementations, that was going to:

1. Increase the size of the .dll which I am desperately trying to keep as small as possible.

2. Require more intricate configuration on the part of the developer, especially registering lots of things with an IoC.

3. If I tried to come up with a generic registration system like Caliburn, that was going to force me to introduce a significan IoC abstraction, along with all its complexities, which would again increate the .dll size significantly.

 

I felt that making public static Func/Action fields was a reasonable compromise which would enable extensibility in the most common places without adding lots of interfaces or an IoC abstraction. Also, having looked at the types of things that Caliburn users have customized in the past, I felt it was overkill to try to push all of Caliburn.Micro's services into a container. That's the brief explanation at least.

Jul 20, 2010 at 12:47 AM

Makes sense, thanks for the prompt reply.