Following reading Thomas Owens response (many thanks to him) on Is it reasonable to build applications (not games) using a component-entity-system architecture? and his explanation on what is ECS compared to others architecture design patterns.
I am using Angular5 and Unity a lot. I am asking myself what is the difference between ECS and MVC, they seem similar to me but also different, I have a hard time wrapping my head around.
So, MVC is an architectural style/pattern that's centered around GUIs/presentation, and it's about (a) controlling the coupling (interdependencies) between the presentation logic (stuff related to the UI) from the business/domain logic (the main thing your application does), and (b) in some variations, also about controlling what's going on within the presentation layer itself (where you might pull the data & behavior out of the GUI into a separate class that represents an abstraction of the view).
It doesn't really prescribe anything about how to structure the rest of the application, or more specifically the domain logic, the core of your application - which in the context of MVC just falls under the term "Model".
There are defined, specific components here (View, Controller/Presenter, Model), and there are expectations on which component should depend on which other (essentially, the Model shouldn't depend on anything, and the View and the Controller can depend on each other to varying degrees, depending on the variation of the pattern (and sometimes, there may be specific mechanisms that are used, like data binding, or support for update notifications based on following a naming-convention, etc.)
Note: There's also "Web MVC" (server side) that borrows some of the same ideas, but also does something different, but I'm mentioning it just so you know that there are these different things that are called the same, if you do any further research.
ECS, on the other hand, is about structuring a complex system with many intricate relationships between various entities and subsystems (relationships that may span several subsystems that are supposed to be conceptually separate), and the expectation that the requirements (and thus the specifics of the code) may change often (and wildly) during development. That's really the problem it's trying to solve. Again, there are some conceptual parts defined, as well as the directions of the dependencies. The idea is that these subsystems (in case of game dev, stuff like the renderer, or the physics system) shouldn't depend on various entities that they need to manipulate (because this leads to having to change these subsystems whenever something changes about the entities). Instead, the dependency is inverted by having both the (sub)Systems and the Entities depend on an abstraction that is represented by the various Components. In the data-oriented variant, the Components themselves are really just data bags, and hold no behavior - but you can read about the details in the (really amazing) post you linked to in your question. The bottom line is, in this approach, a (sub)System is something that provides some service to other code, by taking in a (sub)System-specific Component (it then might do some processing on the component, maybe change some data, or it might use it as some sort of a configuration that specifies what should be done, or both); Entities are objects that hold a collection of such components.
As a final note: if you were to use these patterns together, then, within MVC, you'd most likely use the ECS approach within the "Model" component (the domain logic).
Asking the difference between Entity-Component-System and Model-View-Controller is like asking about the difference between a hammer and a saw. They are both tools in your toolbox, but used for different things.
With ECS and MVC, they are both software design patterns, but solve different problems.
Everything else about them is completely and utterly different.
