3 ms·

You appeared to be making a hard assertion that "The MVC abstraction ... cuts the wrong way for a client-server application" Implying that there's something f

by mjw 17y ago

You appeared to be making a hard assertion that "The MVC abstraction ... cuts the wrong way for a client-server application" Implying that there's something fundamental about MVC-like patterns which makes them unsuitable for client-server apps. As someone using an MVC-like pattern for a client-server app, I was interested in what you think that might be. Seems I misunderstood and you were just making a point about your dislike of the term MVC and the way people are dogmatic about it. Which I broadly agree with (I'm not using the conventional variant, after all), but don't think was stated very clearly. Re 'well-factored': of course, people should learn to factor code well before trying to shoe-horn it into a Pattern. But in my experience a simple iterative process of keeping things well-factored will only get you so far - it's quite a fine-grained process that doesn't always help with the bigger architectural decisions. So ultimately architecture needs ideas, and it does help to talk about those ideas and give them names, much as this can lead to abuse by the lazy. (depending on what you mean by 'well-factored' anyway - it can be used as something of a broad, catch-all bit of terminology for 'well-structured code', but as I understand it, refers merely to code which has had duplicated pieces of logic factored out). There's also the fact that application frameworks are often tied to architectural styles, and application frameworks have a lot of value to people, such that oftentimes it's a worthwhile tradeoff to use one even when the architectural style isn't a perfect fit. You just have to be aware of the trade-off.

jerf 17y ago
"(I'm not using the conventional variant, after all)" Well, that's the thing, isn't it? It's always some variant. It's never "pure" MVC, where of course by "never" I don't mean literally "never" but close enough. So I get to asking myself what's the point of the MVC purists pushing the model when "nobody" actually uses it? What really prompted this was the continual torrent of "Is X Actually MVC?" essays, which inevitably turn out to be "No, X is not MVC." You name it, it's not MVC. Just about the only other technology that has the same suite of essays is "Is X Truly REST?", which, again, is always a "no", because you can't actually stay absolutely pure. If you're using MVC in a client-server app, I give 95% probability that you have done one of the following: Got at least one of the MVC split between server and client, not have the "pure" MVC separation that would satisfy an MVC dogmatist (V and C are really easy to mix, personally I'm somewhat less convinced they are cleanly separable even in theory in most cases, as unless your views are all virtually identical the control ends up reasonably tightly coupled to your view by sheer logical necessity), or horribly contorted the code to fit into MVC. Roughly in order of probability. Also: Well-factored code that is poorly factored at the architectural level is an oxymoron. I mean well-factored at all levels. MVC ideas can help, but jamming an architecture into that template is no better than jamming it into any other pattern; that's always a mistake and MVC is no exception.
- mjw 17y ago
  Just noticed this. Agreed, although I think we may be working from different definitions of MVC. I read it as a broad (but still useful) term describing a class of related architectural patterns designed to decouple presentational logic from domain logic. While I've heard different people describe different (related) kinds of architectures as MVC, I've not actually encountered that much religious debate about which is the "one true" definition. So I'm not sure exactly which MVC variant is the one that you're reacting against as the dogmatic "pure" one. You're more-or-less right about my client-server architecture - I have a split model, and my V and C are somewhat mixed. As the unit of reuse (outside the model) is the Widget, there's quite a fluid spectrum between "view-y" widgets and "controller-y" widgets, meaning you can make a decision based on the individual merits of the situation on how far to split the two. But still have a useful framework in which to do so. It's my favourite kind of MVC, but perhaps need a more specific name for it!

by mjw 17y ago

jerf 17y ago

"(I'm not using the conventional variant, after all)" Well, that's the thing, isn't it? It's always some variant. It's never "pure" MVC, where of course by "never" I don't mean literally "never" but close enough. So I get to asking myself what's the point of the MVC purists pushing the model when "nobody" actually uses it? What really prompted this was the continual torrent of "Is X Actually MVC?" essays, which inevitably turn out to be "No, X is not MVC." You name it, it's not MVC. Just about the only other technology that has the same suite of essays is "Is X Truly REST?", which, again, is always a "no", because you can't actually stay absolutely pure. If you're using MVC in a client-server app, I give 95% probability that you have done one of the following: Got at least one of the MVC split between server and client, not have the "pure" MVC separation that would satisfy an MVC dogmatist (V and C are really easy to mix, personally I'm somewhat less convinced they are cleanly separable even in theory in most cases, as unless your views are all virtually identical the control ends up reasonably tightly coupled to your view by sheer logical necessity), or horribly contorted the code to fit into MVC. Roughly in order of probability. Also: Well-factored code that is poorly factored at the architectural level is an oxymoron. I mean well-factored at all levels. MVC ideas can help, but jamming an architecture into that template is no better than jamming it into any other pattern; that's always a mistake and MVC is no exception.

mjw 17y ago
Just noticed this. Agreed, although I think we may be working from different definitions of MVC. I read it as a broad (but still useful) term describing a class of related architectural patterns designed to decouple presentational logic from domain logic. While I've heard different people describe different (related) kinds of architectures as MVC, I've not actually encountered that much religious debate about which is the "one true" definition. So I'm not sure exactly which MVC variant is the one that you're reacting against as the dogmatic "pure" one. You're more-or-less right about my client-server architecture - I have a split model, and my V and C are somewhat mixed. As the unit of reuse (outside the model) is the Widget, there's quite a fluid spectrum between "view-y" widgets and "controller-y" widgets, meaning you can make a decision based on the individual merits of the situation on how far to split the two. But still have a useful framework in which to do so. It's my favourite kind of MVC, but perhaps need a more specific name for it!