4 ms·

To clarify, an example of a non-MVC compiler would be something that expects to read a list of files from argv and expects to write to stdout. An example of a

To clarify, an example of a non-MVC compiler would be something that expects to read a list of files from argv and expects to write to stdout. An example of a MVC compiler would be something that abstracts the act of compiling bytes into bytes from how it obtains those bytes or puts them out. I think gcc works like the former and clang like the latter? I'm not familiar with either. An example I am familiar with is the TypeScript transpiler - a "Compiler" class with a pluggable "Host" interface. There is one implementation of that host for each environment it can run in (in-memory, node.js, cscript.exe) that knows how to read files and write output. The compiler class would call host.writeFile(filename, contents) and it's up to the host whether to write that to a file, or a textarea in a web page, or pipe the string to another transpiler, or whatever. It's up to the view to decide whether to colorize output or not, whether to show an underline that the user can click to jump to the error or not, etc. Basically the view is independent of the model, and provides functionality local only to its interaction context that the model shouldn't need to care about. As a bonus it's pluggable and thus easy to write new views.

jerf 11y ago
If your model fits everything, it fits nothing. If you've stretched until compilers are "MVC", you haven't got MVC anymore. Something has to be meaningfully a good design that is not MVC for MVC to exist as a distinct solution. MVC is not simply "things should be abstracted from each other". That just, well, abstraction. (Or, better, indirected: http://zedshaw.com/archive/indirection-is-not-abstraction/ http://zedshaw.com/archive/indirection-is-not-abstraction/ ) I've been anti-MVC (unless you are in the rare situations where it really works) for a while, and this is precisely why. It clouds people's thought. It convinces people they're doing "design" when they are often just complexifying things by rote application of badly misunderstood ideas.
- Arnavion 11y ago
  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.
- derefr 11y ago
  MVC itself isn't a tool of craft; it's an ontology for talking about code. That is, there's no system that is or is not MVC; MVC is a guide for mentally modelling a system. It's a way to distinguish parts of a continuous whole by drawing imaginary lines, like between having a "brain" vs. a "mind", or between having a "state" vs. a "government", or between various species of plant or animal. They're tools to use to cluster the various actions of messy systems into well-known, recognizable clumps, and assign labels to those clumps, so that when you talk about your system's "controller" and your friend talks about their system's "controller", you both can understand each-other. Ontological modelling is the pure kind of abstraction—not the kind you reify by implementing it. There's no "MVC design pattern"; all systems can be broken down into MVC. You're never not implementing the "MVC design pattern." The reason people get confused is that there are design patterns that people implement which make an explicit distinction that looks like MVC. This has nothing to do with MVC; you haven't "implemented MVC" by creating a system where all your model classes are Model classes, and all your views are Views. You've maybe made it easier to reason about your system in MVC terms, but that doesn't get you anything unless "reasoning about your system in MVC terms" is something you need to do a lot, because e.g. you and your coworkers split your responsibilities that way. Now, what you may have done instead, when you think you've "implemented MVC", is implemented something like Hexagonal Architecture[1]: an actual design pattern—an idea that some-but-not-all codebases are an instance of—involving effectively inverting your "app" into an "engine" of business logic that relies on dependency-injection of engine-specified "pluggable" interfaces for its IO (both the out-to-the-world kind, and the in-to-its-databases and third-party-services kind.) If your MVC app's "core" business-logic part is a library with direct unit tests on it and so forth, and this part is useless on its own; and if you've got another part that treats the core as a dependency, and turns it into a web service or whatever else—then you've got Hexagonal Architecture. You've also, coincidentally, got some quite-elegantly-delineated MVC boundaries: your model and your view can't share logic, since there's a component boundary between them and neither one can assume anything about the other. But that's just an analytic property of the code; you didn't "do MVC" or even "do MVC right." You just did Hexagonal Architecture, which happens to make it easy to reason about your codebase in MVC terms. [1] http://fideloper.com/hexagonal-architecture http://fideloper.com/hexagonal-architecture

jerf 11y ago

If your model fits everything, it fits nothing. If you've stretched until compilers are "MVC", you haven't got MVC anymore. Something has to be meaningfully a good design that is not MVC for MVC to exist as a distinct solution. MVC is not simply "things should be abstracted from each other". That just, well, abstraction. (Or, better, indirected: http://zedshaw.com/archive/indirection-is-not-abstraction/ http://zedshaw.com/archive/indirection-is-not-abstraction/ ) I've been anti-MVC (unless you are in the rare situations where it really works) for a while, and this is precisely why. It clouds people's thought. It convinces people they're doing "design" when they are often just complexifying things by rote application of badly misunderstood ideas.

Arnavion 11y ago
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.
derefr 11y ago
MVC itself isn't a tool of craft; it's an ontology for talking about code. That is, there's no system that is or is not MVC; MVC is a guide for mentally modelling a system. It's a way to distinguish parts of a continuous whole by drawing imaginary lines, like between having a "brain" vs. a "mind", or between having a "state" vs. a "government", or between various species of plant or animal. They're tools to use to cluster the various actions of messy systems into well-known, recognizable clumps, and assign labels to those clumps, so that when you talk about your system's "controller" and your friend talks about their system's "controller", you both can understand each-other. Ontological modelling is the pure kind of abstraction—not the kind you reify by implementing it. There's no "MVC design pattern"; all systems can be broken down into MVC. You're never not implementing the "MVC design pattern." The reason people get confused is that there are design patterns that people implement which make an explicit distinction that looks like MVC. This has nothing to do with MVC; you haven't "implemented MVC" by creating a system where all your model classes are Model classes, and all your views are Views. You've maybe made it easier to reason about your system in MVC terms, but that doesn't get you anything unless "reasoning about your system in MVC terms" is something you need to do a lot, because e.g. you and your coworkers split your responsibilities that way. Now, what you may have done instead, when you think you've "implemented MVC", is implemented something like Hexagonal Architecture[1]: an actual design pattern—an idea that some-but-not-all codebases are an instance of—involving effectively inverting your "app" into an "engine" of business logic that relies on dependency-injection of engine-specified "pluggable" interfaces for its IO (both the out-to-the-world kind, and the in-to-its-databases and third-party-services kind.) If your MVC app's "core" business-logic part is a library with direct unit tests on it and so forth, and this part is useless on its own; and if you've got another part that treats the core as a dependency, and turns it into a web service or whatever else—then you've got Hexagonal Architecture. You've also, coincidentally, got some quite-elegantly-delineated MVC boundaries: your model and your view can't share logic, since there's a component boundary between them and neither one can assume anything about the other. But that's just an analytic property of the code; you didn't "do MVC" or even "do MVC right." You just did Hexagonal Architecture, which happens to make it easy to reason about your codebase in MVC terms. [1] http://fideloper.com/hexagonal-architecture http://fideloper.com/hexagonal-architecture