When I build a simple website, e.g. a contact book where I can add, delete and update contacts, I create an index.php file where a user, if he's not logged in, is requested to enter a password and if he enters the right password, he's assigned a session and can do certain things with the contacts.

I have two files:

  1. The first (contacts.php) is for the HTML code to be shown. Above the HTML code I include the second file and create the class.
  2. The second (contacts_class.php) contains all methods for adding, deleting and updating.

I think that's ok, but when it comes to implement a big project, how should I do it? Do I have to create folders for every page and put files in them (like above, HTML and class), and how should I do it? What is a good and neat architecture for building large projects that every other programmer would understand perfectly?

migrated from stackoverflow.com May 29 '11 at 15:42

This question came from our site for professional and enthusiast programmers.

10 Answers 10


You raised a very interesting and fundamental question. The question concerning the large scale project architecture and the folder structure organization (which is secondary to the architecture).

Today the most common approach to building the CMS framework architecture is the use of MVC pattern. There are some good articles about building your own MVC frameworks, one of them is Build an MVC Framework with PHP.

MVC stands for Model, View, Controller. You may call these approaches whatever you like - MVC, HMVC, MVP. The essence is to isolate the individual components of your system. The "Controller" retrieves the data from the "Model" and sends them to "View", which renders the final HTML. You have already implemented the "V" in your contacts.php and "MC" in your contacts_class.php. So you have isolated the view from the model and controller. Now you can easily change your "View" leaving other parts intact.

I am not suggesting you to blindly follow the MVC, MVP or whatever else "MV" pattern. It is the matter of appropriateness, efficacy and taste.

The common dynamic website application may include such components like:

  • The entry point, say index.php
  • The helper libraries / classes
  • The request router
  • The modules, components or controllers
  • The template engine or maybe single views

The real web application may include any other components like event handlers, event dispatchers and hooks, but these are in fact nuances. Well, let me present it the way I want to present it:

The operation routine diagram

The common framework operation routine as follows:

  1. The browser request is sent directly to the entry point executable / script (index.php).
  2. The entry point script loads the helper libraries, classes and performs some further initialization of our programming environment.
  3. The URL is passed to the request router instance. This step can be the part of step 2.
  4. The request router parses the URL and dispatches the operation to a particular component, module or controller.
  5. The component (or controller) processes the routed request and sends the data to the view to be rendered.

The corresponding project folder structure is shown in the diagram.

I would suggest you to investigate how the other frameworks are implemented. The recommended CMS / frameworks to begin with are CodeIgniter, OpenCart, Joomla 1.5 and Tango CMS.

  • 3
    What did you use to make that image? Great Answer! – Mark Tomlin Apr 29 '11 at 2:37
  • 3
    Thank you for the positive evaluation of my answer! I really appreciate it! This answer is entirely the result of analysis of various open source web application frameworks, which I conducted earlier for myself. For those who interested in how the image was created and the software being used, the image was created using Inkscape 0.48 and GIMP 2.6.10. No problem with that. Just use two layers: one for the rectangles with text, one for the shadows (the blurred black rectangles). I guess you understand the rest? – ezpresso Apr 29 '11 at 18:42
  • One question, why would you separate the 'contacts' controllers into 3 files. Wouldn't it just be cleaner to combine them into one contacts.php. All you have to do is pass in an action parameter from the router. The same can be said for the 'contacts' views unless your view mixes templating and logic into one file for each action. I don't do much dev in PHP (I work mostly in Python) but I hope that not all frameworks use this approach. Otherwise +1 for a great writeup. – Evan Plaice Aug 16 '12 at 19:56

To get an idea of what questions to ask and what solutions are available I recommend the Patterns of Enterprise Application Architecture book by Martin Fowler. You can get an idea of what's in the book by reading his web site

Please be aware that the book is already pretty old (in IT land) but many principles are still valid or you should learn them to learn from. (Did that make sense?)

(Software) Architecture is a very broad subject, do not expect a silver bullet but always more questions and more doubt until time and money run out and you have to stick with the best solution so far.


First of all, take a look to well developed project. Wordpress is a very neat example of code structure: it is simple to understand but offers a lot of "plug". So wordpress is easy to estend via "plug in".

Second, a very easy way to check your architecture is trying to write unit test. For instance if class "Card Deck" has a "shuffle()" method, you must be able to create a Card Deck of predefined size (i.e. 5 cards 1,2,3,4,5), call shuffle and verify in an easy way the result(i.d. 1,4,2,5,3)

You must be able to do it without instantiaing the entire project classes, and the test must be very clean to read.

If you cannot do it, you must add layers between classes, restructure them, until you get an easy way to do it.

Then reitarate this step for all the core classes of your project.

Last but not least: a good architecure could be "lazy" on not-so-core classes (it is a matter of economy: very well designed things cost too much in real world).


A good architecture for large-scale projects is MVC (Model View Controller): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Whether other programmers would understand it is a different matter entirely, however. MVC can get complex and is sometimes overkill for small projects. One of the benefits of it is that it scales easily.

  • That's a pattern, not an architecture. – halfdan Apr 19 '11 at 19:19
  • I'd argue that they are one in the same in this case. How would you differentiate the two? Also, read the very first line of the Wikipedia page I posted. – Chris Laplante Apr 19 '11 at 19:20
  • 1
    From my experience, MVC is not complex and is very useful in small projects too. I agree however, that it is a pattern and not a whole architecture. – Danny Varod Apr 19 '11 at 19:28
  • MVC is a pattern, not architecture per se, but it can be considered as part of the architecture. And it's not that complicated after all. – driushkin Apr 23 '11 at 18:19

If I understand your question correctly, you are talking about project folder structure and not essentially an architecture. If my understanding is correct, read on; else edit your question or put a comment and I will edit my answer accordingly.

While designing an application, after answering some basic questions like (what? and to whom?), we need to Identify the components and classify them based on functionality \ responsibilities. There are two major ways that I know. You can classify components based on, use cases they handle (like login, search etc) or classify based on Resources ( Objects.. ). The first way is called Activity oriented and the second is called Resource Oriented. Traditionally most applications classify components based on Activities (since designers found it, easy while transferring from problem domain to solution domain).But I digress.

Once the component classification are identified, then we need to identify classification based on Tiers. A typical web application will have View Tier, Model Tier and Controller Tier (MVC). Of course there could be more complex applications too. (most real world applications are more complex that being this straightforward).

After Identifying these two taxonomies, I will create top level folders Identifying each Tiers. (UI, Controller, Services, Utils etc). Under each high level folders, I will create child folders based on Functionality or Resources (Project --/EditProject --/SearchProject etc). Ideally functional classification will be multilevel.

  • I have not gone deeper in to the differences between Resource Oriented and Activity Oriented Designing. Besides digressing, I was not very sure on the question. But personally when it comes to clarity of design (how easily a new developer can understand underlying components and design), Resource Oriented Architecture is better. By just looking in to the folder hierarchy, a developer could understand the entire participating resources and sub resources and operation on each resources are also uniform. – doc_180 Apr 19 '11 at 19:29

There are good architectures and bad architectures, however there are no silver bullets. An architecture must be suited to the current and highly possible future requirements.

A good guideline would be, make sure each part of the application could be changed with minimal effect on the other parts and that each part has automated full coverage unit and integration tests.


Architecture is about making sure you can continue developing in the long term. For larger applications, this includes making trade-offs between making things independent so multiple people can work simultaneously and avoiding duplication (DRY) so the project can stay agile. PHP projects tend to focus on the make things independent and have a large amount of duplication.

To get a good feeling for the other extreme position, take a look at Seaside


If you don't know how to structure a large project you should borrow the design/architecture of others by using one of several good PHP Frameworks. I would recommend CakePHP, CodeIgniter, or Symfony. All of these implement a Model, View, Controller, MVC patten that works well in web development, they are all fairly lightweight and easy to learn.

Once you get to know one of these frameworks you might be in a position to architect your own structure for your particular project, but if your just starting out I'd stand on the work of others vs reinventing the wheel.


MVC is the most commonly used architecture, which is proven to solve most of the problems. A good architecture will have the following features (and more, orcourse)

  1. It can be unit tested
  2. Separation of concerns
  3. Multiple peoples will be able to work on it without any collision.
  4. It can be extended without much problem
  5. It can be scalable. When it comes to big projects scalability will be a major concern. Checkout Kohana framework, which is well written and can be scaled very well

before you write any production code take 2 weeks (nights :) and read this book. It will change your mind for a long time about programming architecture, pratices and packiging.

Agile Principles, Patterns and Practices C# by Prentice Hall

Examples are in C# but they are easy to read it is not about how to write correct code syntax it is about how to think as a programmer.

I promise you will save it on your most accesible place on your pc and you will be amazed that you've been programming without having knowing it. It will shift your thinking.

Not the answer you're looking for? Browse other questions tagged or ask your own question.