<story><title>MVC Isn’t MVC</title><url>https://collindonnell.com/mvc-isnt-mvc</url></story><parent_chain><item><author>LudwigNagasena</author><text>&amp;gt; Model updates View, View sees User, User uses Controller, Controller manipulates Model.&lt;p&gt;&amp;gt; This makes a lot of sense to me, and I think I understand it pretty well.&lt;p&gt;It looks simple at first glance, but it actually makes zero sense under closer inspection.&lt;p&gt;Let’s take a simple example. A table of users. You take a table from the database and put it into an html tag table. Wait, who is “you”? The model? Do you want your model to know about html? The view? Do you want your view to know how to connect to a db? The glue code for them? If so, then it is  the model-view-controller-glue, not model-view-controller.&lt;p&gt;This is why what the author calls Apple-MVC is far more common. It is just hexagonal architecture. You take different components that take care of their own area of concern and glue them together to fit specific needs of your app. That glue code is called “controller” in that case. It is intuitive and simple; and thousands of junior developers probably reinvent that type of architecture every day.</text></item></parent_chain><comment><author>throw310822</author><text>&amp;gt; You take a table from the database and put it into an html tag table.&lt;p&gt;&amp;gt; Do you want your view to know how to connect to a db?&lt;p&gt;I think this is where there&amp;#x27;s a misunderstanding: you think of your model as &amp;quot;a database&amp;quot;. A database is not a model, a database is just a storage layer. A model is an object that provides an api with high-level business operations and views on data.&lt;p&gt;At that point, your view needs only to receive from the model the pre-digested data it provides and translate it into html. Similarly, the controller only needs to translate user input in terms of high-level operations on the model, without ever having to interface with a database.</text></comment>
<story><title>MVC Isn’t MVC</title><url>https://collindonnell.com/mvc-isnt-mvc</url></story><parent_chain><item><author>LudwigNagasena</author><text>&amp;gt; Model updates View, View sees User, User uses Controller, Controller manipulates Model.&lt;p&gt;&amp;gt; This makes a lot of sense to me, and I think I understand it pretty well.&lt;p&gt;It looks simple at first glance, but it actually makes zero sense under closer inspection.&lt;p&gt;Let’s take a simple example. A table of users. You take a table from the database and put it into an html tag table. Wait, who is “you”? The model? Do you want your model to know about html? The view? Do you want your view to know how to connect to a db? The glue code for them? If so, then it is  the model-view-controller-glue, not model-view-controller.&lt;p&gt;This is why what the author calls Apple-MVC is far more common. It is just hexagonal architecture. You take different components that take care of their own area of concern and glue them together to fit specific needs of your app. That glue code is called “controller” in that case. It is intuitive and simple; and thousands of junior developers probably reinvent that type of architecture every day.</text></item></parent_chain><comment><author>fardo</author><text>The way I typically think of it is&lt;p&gt;• Model is “whatever you need to store persistently, how you represent that data, how should the data be structured and stored when it’s at rest (eg in a database, nosql environment, or big data query system), how you are expected to query that data when you need it, mediates common CRUD data query operations on the store, and broadly handles giving back the results of any stored data query. Intent of the model is to be a black box the controller can talk to whenever it needs something from “storage”. If you did it right, you can change the entire underlying data store and endpoint, and as long as the API for the model is preserved, the controllers don’t even notice.&lt;p&gt;• Controllers mediate “turning prepared or cached model data queries into something to give back to the user” and “listening for the user wanting to do something and responding appropriately by fetching needed model data or server resources”. Handles moving between pages, incoming API calls, last mile data filtration (where last mile is based on milliseconds to do it, &amp;gt;25ish or so and it probably belongs on the model) and cleanup if any is needed, and is first line of contact (and defense) for anything a user’s triggered.&lt;p&gt;• Views are whatever the user can visibly interact with and see, and provide buttons, links and interactibles which hook into controller calls to change things or give back data&lt;p&gt;I’ve found the above model typically has good separation of concerns, usually avoids most fights of “does this belong on the model or controller”, and you can usually cleanly parallelize work between multiple people on a small team if you use ~~waterfall~~ scrum to agree on a data model for each endpoint and needed functions before starting.</text></comment>