MVC/HMVC and Object Oriented programming - model-view-controller

Question

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 to 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

Answer 1

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.

Answer 2

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.