Coupling between controller and view
- by cheez
The litmus test for me for a good MVC implementation is how easy it is to swap out the view. I've always done this really badly due to being lazy but now I want to do it right. This is in C++ but it should apply equally to non-desktop applications, if I am to believe the hype.
Here is one example: the application controller has to check some URL for existence in the background. It may connect to the "URL available" event (using Boost Signals) as follows:
BackgroundUrlCheckerThread(Controller & controller)
{
// ...
signalUrlAvailable.connect(
boost::bind(&Controller::urlAvailable,&controller,_1))
}
So what does Controller::urlAvailable look like?
Here is one possibility:
void
Controller::urlAvailable(Url url)
{
if(!view->askUser("URL available, wanna download it?"))
return;
else
// Download the url in a new thread, repeat
}
This, to me, seems like a gross coupling of the view and the controller. Such a coupling makes it impossible to implement the view when using the web (coroutines aside.)
Another possibility:
void
Controller::urlAvailable(Url url)
{
urlAvailableSignal(url); // Now, any view interested can do what it wants
}
I'm partial to the latter but it appears that if I do this there will be:
40 billion such signals. The application controller can get huge for a non-trivial application
A very real possibility that a given view accidentally ignores some signals (APIs can inform you at link-time, but signals/slots are run-time)
Thanks in advance.
