StaticCommand - dependency injection

Since the static command uses static methods, we cannot do dependency injection easily. We should allow to call also instance methods from the staticCommand binding. The class which contains the method would be instantiated for every command and this could be extended by IoC/DI.

Also, we should introduce the StaticCommandHandlerBase class and the IStaticCommandHandler interface which will have the Context property to allow to interact with the HTTP request. This property would by injected by the framework automatically.

It will be optional to implement this interface, I think we can allow static command targets in any class.

However, to keep things secure, any method called from the binding will have to be marked with the AllowStaticCommand attribute.

[exyi]

Static commands of course works with static commands, they are just not resolved from scope parameter by the resolver - so you have to type ViewModel.SomeCommand(). Instance static commands work exactly the same way as static static commands, the this parameter is just passed as any other parameter, it has no special meaning, technically it work exactly the same like static methods. It does not send the entire view model to the server, it only sends the parameters, including the possible this parameter. So it send the entire viewModel iff you call it on root viewModel, it may be completely reasonable in some situations IMO, but it is your choice. It is also reasonable to use it on parts of the viewmodel, something like GetEntireText() on ArticleInfo.

Just a note, the tests will not help at all, we are not talking now about bugs but about flaws in the design. We’d write the tests to match these flaws so they will be completely useless, we would just have to rewrite them with fixing these flaws, so it will be two times more expansive. The discussion can help, hopefully 😃.

[exyi]

resolved in #416