This project is read-only.

Suggestions rather than questions

Feb 22, 2014 at 4:59 PM
First of all I would like to apologize as I couldn't find a better place to post these suggestions to, so I thought I put theme here and you do whatever you want with them.

I am not a senior developer, but I had a little experience with a bunch of WPF/MVVM frameworks and .NET frameworks in general so I thought there are some areas of the CODE framework that could be improved.

I have been working with the framework for a short amount time now, so this list is just a birds eye view.
  1. Why not make NotifyChanged accept a lambda expression instead of a literal string, most of WPF/MVVM frameworks seem to do that and it makes code refactoring easier and less error prone.
  2. The same for Controllers, Why not make Controller.Action method and its variants, so instead of calling _Controller.Action("Home", "Index"), perhaps we can do Controller<Home>(homeController => homeController.Index()) or something similar, also aids in refactoring, less error prone and you can later obfuscate the code base easily.
  3. Why not put InvalidateCanExecute() on the IViewAction interface instead of the putting it directly on the ViewAction implementation, this seems more appropriate.
  4. I asked about this before in the discussions, and it seems there is no easy way to do constructor injection with the controllers.
I hope I haven't board you with my little ideas, I just thought they could make things a little bit better out of my love for the framework.

Again thank you for the great effort.
Regards
Feb 25, 2014 at 5:04 AM
You raise some valid points. Pretty much all of these things have actually come up before at one point or another. Some we may actually do. Here are some of the thoughts that have gone into the specifics you raise:
  1. Lambdas in INPC are something we are potentially considering. Same as the new caller attribute. If we do this, it will be as alternative options people can use in addition to, or as a replacement of the stuff we already support. I think all these options would be good to have. The downsides to consider are that a lot of people get confused by passing lambdas to pass property information. I also don't particularly like the way the implementation of this has to dig out the property name. Especially on large scale scenarios with lots of notifications going on, that is a concern.
  2. Again, something we have considered and we may provide some other option in the future. You are kind of already pointing out some of the downsides yourself though. In short: The syntax would be a) nasty and b) different from ASP.NET MVC, and keeping it compatible with ASP.NET MVC is a design goal. Actually, the syntax would be Controller.Action<HomeController>(homeController => homeController.Index(parameters)), which is frankly nasty. Maybe a better way would be Controller.Action(new HomeController().Index), but that also isn't cool. And again, we also have to consider what it then implies we do to dig up appropriate invocation context stuff and so on. But yes, it would be nice to (optionally) provide a more strongly typed approach.
  3. Historic reasons. We would force a lot of people to add a whole bunch of stuff to their implementation of IViewAction. Actually, it isn't just entirely historic. It is also that we want to keep that interface relatively simple, so people do not have to implement tons of methods when they want to implement this interface themselves. InvalidateCanExecute() is not core to the function of view actions. For this reason, it shouldn't be on the core interface. (We also want to be very careful with adding more and more and more stuff to the core interface). So this is more in the realm of a more advanced version of actions. We want to provide certain non-core convenience features without polluting everyone's interface. We have done so in our abstract ViewAction implementation. This works OK, but it could be better. An idea that has been thrown around before is whether we should introduce something like an IViewActionEx interface or something like that. So maybe that may be a good option.
  4. Yes, this is on the list to provide more information about. I am curious though: Do you have sophisticated logic in the actual controller? While this is fairly common in ASP.NET MVC, most CODE Framework controllers I ever see are mostly glue and not a lot of logic, and most logic is in the models and such. So people tend to want to test that.
Markus
Marked as answer by abnajjar on 2/24/2014 at 10:53 PM
Feb 25, 2014 at 6:55 AM
Thank you very much for the thorough review, I agree with most of what you have said.

Just one comment, you said that the lambda syntax is ugly and confusing (totally agree), but as all other stuff in programming. Sometimes you have to make tradeoffs.

Thank you again Markus,
Regards
Feb 26, 2014 at 2:27 AM
Yes, true. I think providing some of these features as an optional way to go would be ideal. This way, people who like this syntax can use it, while others can go the more conventional route.

So many ideas, so little time :-)


Markus
Marked as answer by abnajjar on 2/25/2014 at 10:38 PM
Mar 12, 2014 at 7:42 PM
I'd love to see constructor injection as an option. I started in today to see if I can figure out how to do it with Code Framework. Not sure how the controllers are built yet, but am thinking it wouldn't be to hard to do something like this... http://blog.thekfactor.info/posts/dependency-injection/
Mar 12, 2014 at 7:51 PM
Yeah, probably not too hard. I have added it to my list to put together some information about this and to maybe simplify how people can do this.

Honestly: I think I would never use this myself. There are several reasons why this pattern has become very problematic in WPF apps. It has impacts on runtime behavior (especially performance). We have a lot of customers who come to us with apps that are basically unusable because this type of architecture. It also has implications on readability and maintainability. There is a def. cut-off between the top-of-the-line developers who "get it" and the rest of the world. It is very costly for maintainability.

But I can see adding it for people who understand these downsides and still want to use it.


Markus