4 ms·

Separation of concerns is neither complexity or misunderstood. It's just good design.

jerf 11y ago
MVC !=== separation of concerns. Separation of concerns is something else. If "MVC is just exactly the same as separation of concerns", then, again, we don't need "MVC" as a concept. We already have "separation of concerns". Again, this is why I find the term loathsome as it is actually used. Not only do people not think about it, they, like, actively won't think about it. Anyone who actually tries to nail down "what exactly is MVC" will find themselves coming up empty. It is an undefined term, and should be discarded for pretty much everybody who isn't writing a CAD/CAM app, not used as some sort of vague template for "all good design". You've progressively shrunk the goalposts in every post in this series until you can't help but hit MVC. That's not useful.
- overgard 11y ago
  To your example, I work on a CAD app that runs on web and even we don't use MVC. :-) (Similar concepts, sure, but no buzzwords or worry about being MVVM or whatever)
- Arnavion 11y ago
  >If "MVC is just exactly the same as separation of concerns", then, again, we don't need "MVC" as a concept. We already have "separation of concerns". MVC is an example of separation of concerns, specifically applied to separating the computation of data from the input and output of that data. I don't see how this is such a difficult thing to understand. (Edit: Heck, even Wikipedia calls it "a software architectural pattern mostly for implementing user interfaces (but not only for user interfaces). It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user." Emphasis mine.) >Again, this is why I find the term loathsome as it is actually used. From this and sibling post I seem to detect some hostility against the term due to there being articles about "you're doing MVC wrong." You can find those a dime a dozen on any topic. Don't misdirect your anger. >Anyone who actually tries to nail down "what exactly is MVC" will find themselves coming up empty. See above, as well as my previous posts in this thread. >You've progressively shrunk the goalposts in every post in this series until you can't help but hit MVC. That's not useful. On the contrary, I've been consistent from the very first post what MVC is and how it applies to software. You're the one here insisting that it's something magic that needs to be different from what I've been saying it is.

jerf 11y ago

MVC !=== separation of concerns. Separation of concerns is something else. If "MVC is just exactly the same as separation of concerns", then, again, we don't need "MVC" as a concept. We already have "separation of concerns". Again, this is why I find the term loathsome as it is actually used. Not only do people not think about it, they, like, actively won't think about it. Anyone who actually tries to nail down "what exactly is MVC" will find themselves coming up empty. It is an undefined term, and should be discarded for pretty much everybody who isn't writing a CAD/CAM app, not used as some sort of vague template for "all good design". You've progressively shrunk the goalposts in every post in this series until you can't help but hit MVC. That's not useful.

overgard 11y ago
To your example, I work on a CAD app that runs on web and even we don't use MVC. :-) (Similar concepts, sure, but no buzzwords or worry about being MVVM or whatever)
Arnavion 11y ago
>If "MVC is just exactly the same as separation of concerns", then, again, we don't need "MVC" as a concept. We already have "separation of concerns". MVC is an example of separation of concerns, specifically applied to separating the computation of data from the input and output of that data. I don't see how this is such a difficult thing to understand. (Edit: Heck, even Wikipedia calls it "a software architectural pattern mostly for implementing user interfaces (but not only for user interfaces). It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user." Emphasis mine.) >Again, this is why I find the term loathsome as it is actually used. From this and sibling post I seem to detect some hostility against the term due to there being articles about "you're doing MVC wrong." You can find those a dime a dozen on any topic. Don't misdirect your anger. >Anyone who actually tries to nail down "what exactly is MVC" will find themselves coming up empty. See above, as well as my previous posts in this thread. >You've progressively shrunk the goalposts in every post in this series until you can't help but hit MVC. That's not useful. On the contrary, I've been consistent from the very first post what MVC is and how it applies to software. You're the one here insisting that it's something magic that needs to be different from what I've been saying it is.