1.3. Building our PHP framework

There are many different ways to construct a framework. Some people prefer very complex frameworks, while others prefer very simple ones. In our articles, we’re going to quickly build a framework that is easy to use and easy to understand.

Our articles will help you develop your own framework, different from the one we’re building for an online store. You’ll be able to easily add other parts to the framework to create something bigger. The main goal of this article series is to teach you how to build your own framework for any CMS.

Design Patterns

Various design patterns are used in framework development. A pattern is a best-practice solution to common programming problems. Among these, we’ll use the following:

• Model-View-Controller (MVC)
• Registry
• Singleton

Model-View-Controller (MVC)

MVC is the foundation of our framework and provides a solution for separating the user interface from the application logic. The View (user interface) interacts with the Model (data layer) via the Controller, which contains the necessary business logic to manage the data.

For example, when a user clicks "Add to cart" in the View, the Controller handles the request, interacts with the Cart model, and adds the item to the cart. The Cart model typically returns updated data to the Controller, which then displays the new cart contents in the View.

We will use our own framework and be able to expand its capabilities based on MVC. As mentioned earlier, data is represented in models, and the data itself is stored in a database. The models and the database tables have the same structure (model fields match table columns). So, we can extend our MVC diagram. We also see the final output handled by the View and displayed in the browser, so let’s add that to the diagram too.

Registry

The Registry provides a way to store a collection of framework objects. The need for a Registry arises due to the abstraction introduced by the MVC pattern. Every Controller and Model (e.g., product, cart, page) needs to perform common tasks, such as:

• Database queries
• User authentication checks
• Passing data to Views (template management)
• Sending emails, such as order confirmations
• File system operations like uploading product images

Most systems and frameworks implement these functions in objects, and we’ll create such objects too. The Registry stores these objects in one place. It can be accessed from anywhere within the framework and provides access to its stored objects. Here is a rough diagram of our Registry:

The framework interacts with the Registry directly when needed and provides access to the rest of the system. Inside the Registry, objects can also interact with each other. For example, the template manager might be connected to the file manager, and the email sender might rely on email templates.

Singleton

It’s hard to find a perfect Russian translation for “singleton,” so we’ll use “Singleton class,” though it’s often left in English in documentation.

Singleton is one of the simplest design patterns to understand. Its main purpose is to ensure that only one instance of a class exists. This is typically used when only one object of a class is needed and it must be accessible from anywhere in the application—that is, global access.

The Singleton pattern is used when a class has a single responsibility, like managing a database connection that other objects will share.

General Structure

The next step in developing our framework is planning its structure. We need to create a structure for:

• Models
• Views (so we can integrate theme-switching capability; each theme in its own folder)
• Controllers (so we can store them in separate folders and add new functionality easily)
• Admin Controllers (since we’re building a CMS, we need to allow moderators/admins to manage content)
• The Registry
• Registry objects
• Uploaded files
• Third-party libraries
• Miscellaneous code

Considering the structure of the framework, our directory tree should look like this (we’ll use English names as is customary in PHP):

• Models
• Views
  • View A
  • Templates
  • Images
  • JavaScript
• Controllers
  • Controller A
    • ControllerA
    • ControllerAAdmin
• Registry
  • Objects
  • Database objects
• Assets
• Uploads
  • To be expanded when we add products and images to our framework!
• Libraries
• Miscellaneous