Need guidance regarding the correct flow of my PHP MVC Framework [closed]

开发者_运维百科 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

I'm creating a PHP web application framework (MVC). I'd rather not use external libraries or components (as I want this to be purely my work for now)

Can you tell me some tips/guidance for what each of my files should be responsible for doing? Such as, what should be handled by the Framework script and what should be handled by an Application script used in the framework?

I keep changing where different code is written (as I think to myself... "Should this be handled by the framework or by each application?"), which is making it more confusing as I go along.

I've read a bunch (20...50...100 even!) of tutorials regarding MVC, frameworks etc, but there's not many that explain the ideal 'flow' of a framework..

Currently I have it working like this:

• Main Index (index.php)
  • Defines constants (DS = DIRECTORY_SEPARATOR, PS = PATH_SEPARATOR, etc)
  • Sets include paths (ROOT . '/classes', ROOT . '/includes', etc)
  • Loads Framework configuration file (config.php)
  • Sets up framework class autoloader (__autoloader())
  • Sets up some sort of Core object (Core::init($config)?)
  • Loads Application index.php file (app/index.php)
• Configuration (config.php)
  • Defines config array ($config)
  • Configures config array ($config['debug'] = 0... or something like that..)
• Application Index (app/index.php)
  • Defines constants (APP_CONTROLLERS, APP_MODELS, etc)
  • Sets include paths (APP_PATH . '/classes', APP_PATH . '/includes', etc)
  • Loads Application configuration file (app/config.php)
• Application Configuration (app/config.php)
  • Defines config array ($app_config)
  • Configures config array (Same sorta stuff as the other config, but for App)

Now.... do I seem to be heading in the right direction? And what sort of things should the Framework's Main Index script be doing rather than the App Index? Should the Main index just initiate some stuff and pass off most of the work to the App Index, which will set up routers etc to route URLs to controllers, etc...? Or should the Framework be creating routers and initiating controllers, and the App would just set controller paths and some rules, etc..?

I understand what Controllers do, and models/views etc (I'll cross those bridges when i come to them later on), but for now I just want to get the basic things flowing correctly from the right places so things later on will work well.

At the moment, my head's about to explode! haha

This may have even been a really dumb question, but I just think I need some straight-forward guidance to help me clear things up before I get everything totally out of whack! Any advice would be appreciated.

Thanks =)

---

I really dislike when people just point you to existing frameworks and state that you shouldn't reinvent the wheel.

MVC, like other patterns, are just guidelines, there is no fixed way to achieve the result. It's a theory which can be implemented in a number of ways in order to achieve the desired result.

Really, the analogy of a wheel is flawed and it's like saying to a car maker not to make a new car because the car already exists.

Some wheels are made of wood while others are made of metal, none of the popular PHP MVC frameworks follows the same structure or functionality, they too are very different.

You can have a thousand different frameworks, all following the MVC pattern, more or less, yet not two are identical.

One framework is overly complicated and takes forever to understand how it works, another enforces a very specific work flow upon you which allows for very little room for freedom, yet another is too simplistic and lacking even basic functionality.

There is very good reason to develop your own framework as that is what it is, ie. your framework for your projects. Nobody understands your code better than yourself (hopefully), and if you build a nice framework that makes you develop projects easily and effectively, then by all means do reinvent the wheel again!

John Squibb has a nice tutorial on one way to build a simple MVC framework. http://johnsquibb.com/tutorials/mvc-framework-in-1-hour-part-one

Oh, and yes another thing, don't be lured into the common novice construction in which a single entry point is made obligatory, forcing you to rely on Apache mod_rewrite or similar approaches. MVC can be build with a single entry point or with several.

Rather than building a framework you can also just develop a nice library which you can reuse in all your projects.

---

You should put together a few applications in a popular MVC framework or two before creating your own. That way you will have a better idea of how things should flow.

Remember you are reinventing the wheel... poorly. But it sure is fun eh ? ;)

---

There is a great tutorial on writing your own mvc framework, however as Byron said, you will be re-inventing the wheel. I think that it is worth having a go at writing your own first though as its a great learning experience and unlike a big mvc framework(symfony or zend) you will know what every part of the code does. This tutorial is the one I used to learn about mvc before moving onto using Symfony, it helped me alot with understanding how symfony works. After Anant Garg's tutorial I moved onto the Jobeet Symfony tutorial which really helps explain symfony 1.4.

Hope this helps

Luke

---

One thing to remember is that MVC is just a pattern, and therefore is not meant to be 100% strict but rather a guidance for implementation that can be tweaked to fit your specific needs. So as others have suggested, try with what you have and you'll see what works for you and what doesn't.