The key in understanding MVC lies in the separation of the responsibilities, as MVC is simply SRP applied to UI code. It separates what data has to be displayed, from how to display it, from how to handle screen events. But an important (and often missed) detail of the original definition of MVC is that it was designed for a far more granular level. For instance, you'd have ButtonModel, ButtonView and ButtonController objects, "just" to present a single button on a screen. Missing this detail is what causes so many different opinions on the subject. You can check the Java Swing architecture to see what I mean.
The point of MVC is to allow the code that serves each responsibility to be changed without affecting the code for the others. For instance, you would be able to switch the rendering of (a component on) the screen without having to touch the data representation nor the event-handling logic. So, to a degree, this goes along with what you say here:
From this, I reasoned that given any Model and View, swapping only the controller should not change the data the page initially renders because the controller should change only the behaviour and not the 'content' of the page. I think this aligns with the conceptual visualisation of the controller as a 'station controller' in a rail system, a plan of the rail road as the model and the actual physical manifestation and look/feel of the tracks (in different flavours, say 'Real' or 'Virtual 3D') as the view.
However, in your context, the level of granularity is off; you have a SessionView that seems to be responsible for a whole screen. At this level, the responsibilities get too coupled to fully separate as intended by MVC, thus it may not provide the full benefits.
Your problem is in separating the three UI responsibilities (rendering, the data and the event-handling) for both sessions and processes, a total of six. Because of the level of granularity of the components (whole screen), this becomes impossible, and causes the dissonance you find yourselves into.
You want to separate the rendering and event-handling responsibilities for both Sessions and Processes, but you'd couple their data. Your colleague wants to decouple the data, but couple the event-handling.
So in the end, this is an SRP problem. My way out would be to decrease the level of granularity down to a point where you can clearly separate Sessions from Processes. If you can't do that due to economics, you guys simply have to weight both sides of the trade-off, choose the least worst, and sign it off as technical debt. This is, after all, what design decisions are all about. :)
Best Answer
Because
double.NaNanddouble.PositiveInfinityalready have very specific meanings. It's pretty bad practice to repurpose special values like that in a completely different context, where it would have significantly different meaning. Just because an element cannot beNaNorPositiveInfinity(or for that matter-1) units wide doesn't mean you should reuse that value arbitrarily to mean something else. Suppose you calculated the with of an element dynamically,NaNorPositiveInfinitywould still represent a division by zero and means something is wrong with the calculation, not that element should stretch.It's true that WPF allows you to specify
Width="Auto"which gets stored internally asNaN, however I would argue that this is indeed bad design (or at least not very good design—at least"Auto"is indeed not a number), for the reasons listed above. I can't say why the WPF team chose to allow one special value, and not the other, except that perhaps it was simply the best option to keep their layout algorithms simple and flexible.NaNhas the added benefit that any arithmetic operations performed on it remainNaN, while many operations onPositiveInfinityresult inNaN. This may makeNaNmore suitable for storing special values thanPostitiveInfinity.A much better solution can found in
GridLengthstructure, which represents discreet measurements and special values (such as*andauto) appropriately. The designers of WPF could have used a similar structure to represent the width / height of all framework elements, but that would likely have made most of even the most basic layout algorithms much more difficult.