title: Simple model layer for a small website with tiny logic
body: <p>I have struggled with an MVC concept for a long time in php since I'm not a php developer. I refactored my site several times but it still looks like a cannon pointed in a mosquito. I've read many articles, posts and answears about MVC but it still makes me confused.</p>
  
  <p>Let's have a simple website with articles and comments system. Everything is stored directly in a database (information about articles, paths, comments etc.). Mostly based on <a href="https://stackoverflow.com/questions/5863870/how-should-a-model-be-structured-in-mvc">this</a> I developed my own app using MVC. Here is how it works:</p>
  
  <ol>
  <li>Controller retrieves data from the database about an article and related comments</li>
  <li>It creates required model's objects (current article and comments)</li>
  <li>... and then passes necessary data to the View</li>
  <li>View presents those data by applying particular templates for provided objects</li>
  </ol>
  
  <p>Everything works like a charm but... </p>
  
  <ul>
  <li>my model's objects don't need any external logic so my domain objects are bordered to getter/setter classes -I'm wondering: do I need domain objects? It's pointless to store separated objects only for getting them from DB and displaying on a website after a while, isn't it?</li>
  <li>controller holds a DB connection passed to services and mappers for creating a model's object -but queries stored in mappers can be merged into services functionality</li>
  </ul>
  
  <p>In conclusion, I wonder if it's not a better approach to replace three-part model with a single manager (per object) which will retrieve all necessary data from the database and will pass them in any way and form (i.e. associative array) to the View. </p>
  
  <p>Please do note, that I'm describing a simple case (1:1:1) with tiny logic, where most data retrieved from database are only for a presentation purpose. </p>