Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Assumption #1: Thinking about the right abstraction for a web application, the directory containing the library of classes should be located outside of the directory containing the presentation files. This organization adheres to the DRY ("Don't Repeat Yourself") principal allowing for multiple presentation folders (www.domain.com, management.domain.com, api.domain.com, etc.) to work with the same objects.</p> </blockquote> <p>This is correct in the sense that libraries are not used for presentation (i.e. not views). They are modules that will be used across multiple controllers. Usually they should not use persistent data since they are not models but in some cases do (codeigniter sessions for example). </p> <blockquote> <p>Assumption #2:</p> <p>If all your classes are located outside of your presentation folders, then the models in your MVC implementation just use instances of those classes. If that's true, then the MVC framework is just a presentation class (the controller) that helps to manage the input (GET &amp; POST requests), the response (models or instances) and output (views or templates).</p> </blockquote> <p>This is a little confusing to me. You are correct the the controller is just used for orchestration of GET and POST request but becareful about calling then the "presentation class". the controller is responsible for the orchestration of models (persistent data) and views (presentation of data).</p> <blockquote> <p>Assumption #3:</p> <p>If the MVC framework is just a presentation class, then the database class that the controller instance initializes breaks the abstraction of the controller class. A model (of the controller instance) shouldn't have a ("has a") database, it should have a thing (user, product) from the library of classes and that thing should have a database.</p> </blockquote> <p>This is very confusing and I don't really understand what you're saying here. MVC is a just a "presentation class", a model doesnt have a "database", the framework may hold a connection to a database and models are abstractions of the database (object like user, product).</p> <blockquote> <p>Assumption #4:</p> <p>Furthermore, if the MVC framework is just a presentation class, the database class that the controller instance initializes is too tightly coupled with the controller class. Changing from one method of storage to another requires re-factoring of all the models.</p> </blockquote> <p>The controller doesn't initialize the database, the framework usually handles controllers only access the abstraction of the database (models). If the database system is replaced by anything only the implementation of the models interface is re-factored.</p> <blockquote> <p>Assumption #5:</p> <p>With a HMVC framework, the issues with the controller containing the database is worse, because your models are more module (more models, more re-factoring).</p> </blockquote> <p>HMVC doesn't necessarily mean more models. Using HMVC allows for portable modules from a project that can be access across multiple controllers. Often you will see Libraries doing this in non HMVC frameworks ie Library that doesn't some db/templating. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload