4 ms·

Genuinely interested here in what you'd propose as an alternative. Separating model logic from presentational logic helps me a lot in client side code. Then t

by mjw 17y ago

Genuinely interested here in what you'd propose as an alternative. Separating model logic from presentational logic helps me a lot in client side code. Then the 'two models' problem seems inescapable if you want to divide the load of model-level computation between client and server. Sure, if you do all the non-trivial computation server-side, then the client-side model becomes less important. But sometimes you need to do more complex computation in the client, whether for UI latency or scalability reasons. If you didn't, you'd just be writing a traditional server-side web app (which of course is fine, but not what we're talking about). On the other hand, if you do most of the computation client-side, the server-side can be a relatively trivial persistence layer, and sometimes that works out really well. But even if all you're doing is calling on a persistence layer, it can still require a fair bit of bookkeeping logic in your client-side model code. versioning, caching and cache expiry, object identity, managing consistency of local copies of denormalised data etc. As for 'two controllers', I'm not sure I get what you mean there. In most verisons of MVC I've seen, the controller talks to both model and view, not just the view. But it is a poorly-defined term. Personally I prefer an approach something like "M + Tree(V + C)". That is, a model layer, and then a tree of 'widgets' or user-interface components, each of which has its own controller and view logic. Widgets may create and manage child widgets. etc. Finding this works quite well, especially when you throw data-binding into the mix too. Agree that the 'VV' approach you describe sounds quite a crazy optimisation, depending on how far you take it. Although might make more sense if you have more of a unified development environment between client and server eg GWT or a javascript-based server framework.

jerf 17y ago
"Genuinely interested here in what you'd propose as an alternative." Honestly? Read the motivations for MVC. Read carefully about the reason why some people think it's a good idea, because I think the ideas are valuable. Then... just write your code, and focus on keeping it well-factored, not MVC. MVC is really about keeping your code well-factored, but it only applies literally in a handful of circumstances. The ideas apply everywhere, but you're better off understanding how to keep things well-factored than how to jam things into MVC. MVC is giving a man a fish, understanding factoring is teaching them how to fish, but the metaphor breaks down here in that it's actually easier to learn how to fish here. Replying to this with an elaborate explanation of when MVC applies would be missing the point. If it is the best-factored organization, then go for it. But it is the best solution fairly rarely, where the best may be MMVC, or MVCC, or MVC+tree, or, frankly, endless variations on the theme. There's so many valid variations of such diversity that viewing everything through the lens of MVC just isn't that helpful.
- 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.

by mjw 17y ago

jerf 17y ago

"Genuinely interested here in what you'd propose as an alternative." Honestly? Read the motivations for MVC. Read carefully about the reason why some people think it's a good idea, because I think the ideas are valuable. Then... just write your code, and focus on keeping it well-factored, not MVC. MVC is really about keeping your code well-factored, but it only applies literally in a handful of circumstances. The ideas apply everywhere, but you're better off understanding how to keep things well-factored than how to jam things into MVC. MVC is giving a man a fish, understanding factoring is teaching them how to fish, but the metaphor breaks down here in that it's actually easier to learn how to fish here. Replying to this with an elaborate explanation of when MVC applies would be missing the point. If it is the best-factored organization, then go for it. But it is the best solution fairly rarely, where the best may be MMVC, or MVCC, or MVC+tree, or, frankly, endless variations on the theme. There's so many valid variations of such diversity that viewing everything through the lens of MVC just isn't that helpful.

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.