What is the best class structure for simple php framework ?

I am trying to create simple php framework .But i am not sure about class structure for example which classes should extend to which classes .Firsly i am know that some basic classes such as Router , View classes have to access some basic data such as requested url or requested ccontroller and action so how can i import basic data to these classes .If my question is not clear please explain your own experiances and ideas about frameworks.or if you know please talk about known framewoks such as zend , cakephp or symfony

From stackoverflow

• There is no best class structure. Depends on what you are trying to do. Do you mean purest MVC design? Most testable? Most easy to understand?

  Oguz : most improveable with basic features like routing , template , layout , auth , Mvc , controller plugin .Not for big projects for self use like blog , cms scripts

• There is a simple rule of thumb:

  • Either you have a need that the standard frameworks can not fulfill
  • or you should use a good standard framework that does what you need.

  In the first case the restriction will be the driving aspect in your design.

  There are no general design rule for class structures in frameworks. But try to keep this in mind, if you decide to write your own one:

  • Minimize dependencies between modules
  • Always try to give default values
  • Try to minimize the overhead
  • Talk a lot with peers about it to find flaws early.
  Oguz : yes i dont want to make lots of unnecessary relations between classes. i think i can seperate classes to 2 group.First one basic clasess such as router class or view class . these classes can not access to others' data .and second one is group which uses other classes such as front controller . for example front controller can access others' data and they can call others methods. for example when dispatch method of front controller is called front controller calls necessary methods of other classes such as route method of router class or render class od view class

• If you've never worked in someone else's framework you will have no idea what ideas work for you and what don't. If you've only ever worked with dis-organised spaghetti code, then you will have some idea of what makes sense for you. If you've made substantial re-organisation to dis-organised spaghetti code in more than one unrelated project, you should have a good idea of how you think in building a framework. :-)

  If you don't have a firm idea of how you want to write a framework, but you want to write one, I think you need to start with nothing and build it organically. However, you should have some idea how you want it to look like, even if it's something as silly as where you want the include files to live. In other words, all you need is a starting point. Then it's a matter of re-factoring ugliness as you encounter it. Before long, you will have a database handler, a dispatch mechanism, perhaps a data access layer, just maybe even a templating system!

  Responding to @MrFox, though, you should be aware of dangerous dependancies. Obviously a data access layer will depend on a database handler; so what you don't want is for your database handler to depend on your data access layer. In fact, you don't want them to have intimate knowledge of each other, either. It should be a reasonably "black-box" interface.

  Also, a number of frameworks try to build "one" object heirarchy. This means they think an Action is-a Model is-a Database Handler. I personally have problems with this mis-applied abstraction, so this is a heads-up to not be afraid to spurn this idea if it doesn't work for you, either. As @Tyndall said, there's no one, single "right" way to do it.