views:

98

answers:

3
<?
class Launcher {
    function launch() {
        new Controller();
    }
}

class Controller {
    function __construct () {
      if(!is_object($this->Model)) $this->Model = new Model();
      if(!is_object($this->View)) $this->View = new View();
    }
}
class Model {
    function __construct () {
      if(!is_object($this->Controller)) $this->Controller = new Controller();
      if(!is_object($this->View)) $this->View = new View();
    }
}
class View {
    function __construct () {
      if(!is_object($this->Controller)) $this->Controller = new Controller();
      if(!is_object($this->Model)) $this->Model = new Model();
    }
}

$launcher = new Launcher;
$launcher->launch();
?>

PHP says "Fatal error: Maximum function nesting level of '100' reached, aborting! in C:\xampp\htdocs\frameworks\myframe\test3.php on line 10".

How to solve this problem?

+5  A: 

The model is not supposed to access anything else. Though you can tailor MVC to your needs to a certain extent, having them all access each other is not how you do it.

See the direct associations in the diagram on the MVC wiki page:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Oh, and you should probably read the rest of the page, too.

Chris
Is there a way to have them all access each other?
Delirium tremens
Don't create them all in the constructor.
Chris
Don't define infinitely recursive data structures in a language that is not explicitly designed to support it.
Paul McMillan
+2  A: 

Why should your models be able to access views or controllers? The whole idea of a model is that it abstractly represents some real-life thing or action, without actually doing anything related to, say, HTML presentation.

Why should your views have any more access than the models? The views are only concerned with showing what it looks like, or what action it should take when a particular request is made by a user. It has no business with why it looks the way it does or how the actions take place.

All of that interaction is the purview of the controller layer.

You can approach the problem by working on the models only. Interact with them by writing detailed unit tests, that verify they have sane behavior with a compact API.

Next you can build up a bit of your controller layer, with stub views that show little more than object ID's or whatever.

Add views for each kind of interaction you need for your application, and modify the controller to tie the new views to the models.

TokenMacGuy
A: 
walkytalky