This project is read-only.

If I don't use a controller....

Sep 30, 2015 at 7:18 PM
Hey guys...
In keeping with the theme of the CODE framwork, "Hey use the pieces that you like..", what if instead of using a controller, you were to just manually wired up a view with the viewmodel... what would I be loosing from the framework?

This came up because when I showed this framework, the Controller part of this had little value to one of the senior people and felt that to use anything but MVVM would be going against the grain... since the controller in WPF, just needs to associated the vm with view, it doesn't by us anything.. I want to know if that is true or not..

If I just created a static utility method "CreateView( string view, object viewModel) and wired them up, would I be shooting myself in the foot? I know it wouldn't be true MVC at that point, but it is what it is... :(

Oct 25, 2015 at 8:33 PM
You somehow have to trigger loading of a view. When you do a Controller.Action(), that triggers a chain of events that causes the method on the controller to be fired, which in turn calls up the current view engine to load the view and all the associated resources and package them up in to a ViewResult (a special version of an ActionResult). Then, the whole thing is handed over to the registered view-handler, which knows how to display the view and host it within the current UI (such as by adding the views into the shell or loading it into a new window that needs to be opened).

So there is quite a bit to it. You could of course find a different way of doing it. But you are basically looking to build a major part of the framework (or at least call those parts of the framework in some other ways). After all, the theming and handling of resources and bringing together the right files is a major part of what CODE Framework does (and certainly the part that no other framework does).

I am not sure I agree that the Controller isn't really a part of the MVVM story. You need something that does all this, no matter what you call it. Personally, I like having a well defined place (such as a controller) that does this, rather than the somewhat ill defined approach other apps often take.

Oct 28, 2015 at 2:33 PM
Thanks Markus... with some more digging around I traced more through the framework and saw all the things that are wired up when instantiating a view... I wouldn't want to bypass that.

Also, the new biomed app I am working on, uses multiple "patterns" and is pretty tough to pull apart to work in CODE. It's amazing how people get hung up on what really needs to get done. IN WPF, once the datacontext of a view is set, no matter how it's done, it's pretty much MVVM from there forward. Same binding abilities etc... But the gyrations people go through to simply set the datacontext is nuts sometimes. The "Castle" framework with DI is used here in places and geez, what a PITA for simply wiring up a view... Using a controller pattern is SO much easier.. Still will be trying to work it in once the code is de-spaghettized. :)
Oct 29, 2015 at 8:15 PM
I agree.

I feel very strongly that one of the key framework design guidelines should be to "keep simple things simple". In most WPF frameworks, when you ask how you actually launch a UI, the answer usually is "weeeeeeeeelllll.... it depends" and then brace yourself for a 1-hour discussion of some really odd mechanisms. In fact, solving this very problem was one of the original key design goals of CODE Framework.