I just started using Caliburn.Micro and I’ve noticed in all the examples that the methods are all public. I decided to test this by adding a button with:
x:Name="CloseMainWindow"
In my VM I added a method:
private void CloseMainWindow()
{
TryClose();
}
When I click the button, nothing happens and I don’t hit the breakpoint, but if I change the method to public it works.
I can’t see this being the best way to do this.
Would creating ICommand properties for all the methods be an acceptable solution?
Edit: I just read the answer to the question immediately above, there is not and never will be ICommands in Caliburn.Micro. So my original question still needs an answer, why does everything have to be public in the VM and is this safe?
I don’t know what you mean by “is this safe?”. Safer than what?
Anyway, Caliburn.Micro could have been designed to allow its conventions to bind to private methods, but that has a couple of drawbacks. First, it wouldn’t work in partial-trust environments, like Silverlight or XBAPs or sandboxed plugins. You need full trust to use Reflection to access private members, and Caliburn.Micro is designed to be able to run in partial-trust (it does support Silverlight, after all).
But a bigger reason is that it would violate encapsulation. These are methods that you intend to be called from outside the class. (The view is a separate class, after all; you’d have to make the viewmodel method public if you were wiring it up yourself in the code-behind.) There’s a word for “I intend to call this from outside my own class” in the language specification, and that’s
public. If you set up some magic that calls private methods from outside the class, you’re violating both encapsulation and the Principle of Least Astonishment, because that’s not whatprivatemeans.If you really want to be able to bind to private methods, you can customize the conventions. But it would make your code much harder to understand, so I wouldn’t recommend it unless you can come up with a really good justification.