MVC/HMVC and Object Oriented programming

I've been reading and learning about Object-Oriented programming (Head First Object-Oriented Analysis and Design and Code Complete: A Practical Handbook of Software Construction – thanks to suggestions found on StackOverflow). I've also been learning how to use a couple PHP MVC frameworks (specifically Codeigniter and Kohana).

Some of the principals of Object-Oriented that I've read about are handled differently by the MVC frameworks. I think I've managed t开发者_高级运维o understand the differences and why the decisions were made (complete and easy to use solution), but I wanted to test my assumptions...so if you'll humour me...please comment or correct.

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.

Assumption #2:

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 & POST requests), the response (models or instances) and output (views or templates).

Assumption #3:

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.

Assumption #4:

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.

Assumption #5:

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).

UPDATE:

Sorry, I may have used the terms controller and model a little loosely...maybe that speaks to the tight coupling. The source of my confusion stems from the database class syntax.

With a model, shouldn't it be:

$user = new User($id);
$data['name'] = $user->getName();
$data['title'] = $user->getTitle();
return $data

Instead of:

$query = $this->db->get_where('user', array('id' => $id), 1, 0);
$row = $query->row_array(); 
$data['name'] = $row['name'];
$data['title'] = $row['title'];
return $data

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.

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).

Assumption #2:

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 & POST requests), the response (models or instances) and output (views or templates).

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).

Assumption #3:

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.

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).

Assumption #4:

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.

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.

Assumption #5:

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).

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.

UPDATE: Just wanted to answer/comment on my confused question.

Kohana provides a Modules folder that addresses my earlier concerns.

For example, if you were to setup a domain, with a subdomain, using Plesk, the folder structure would be the following.

httpdocs
subdomains
+--management
   +--httpdocs

If you want to share code between the domain and subdomain, using Kohana's modules, you could setup your file system like this:

modules
system
httpdocs
+--application
+--index.php
subdomains
+--management
   +--httpdocs
      +--application
      +--index.php

Where httpdocs/index.php and subdomains/management/httpdocs/index.php has the following:

$application = 'application';
$modules = '/root/pathto/modules';
$system = '/root/pathto/system';

Any objects that are used in both the domain and the subdomain can be placed in the modules folder to be used by the application.

Hope that helps.