Skip to content

Namespaces

Greg Bowler edited this page Jul 4, 2023 · 8 revisions

Encapsulation is an important concept in object-oriented programming, and it's just as important when it comes to managing session data in PHP. Essentially, encapsulation is about bundling related data together and hiding it from the rest of the system, unless explicitly required.

Session namespaces provide this level of data encapsulation within your PHP sessions. When you use a session namespace, you're storing related session data together in a distinct area within the session. For instance, you might create an 'auth' namespace to hold data related to the current user, or a 'ui' namespace to store information specific to the current user interface settings. By doing this, it is easier to manage data, it's more intuitive to know where specific data is stored, and most importantly, each namespaced area of the session can be passed to individual areas of the system, meaning one area of the application code can't accidentally read/write another area's session.

Without session namespaces, data from these different system areas could easily get mixed up or even overwrite each other. This is where namespaces become extremely handy. By creating a unique session namespace for each area of your system, you can ensure that each one has its own dedicated storage space within the session. This prevents data collision and leakage, providing more robust and reliable session management.

Using dots to separate namespaces

Any object or scalar value can be stored to the Session object via a string key. The key can contain dots, which is a shorthand method of storing data to a namespace.

For example, storing two data using the strings user.name and user.colour will automatically create a SessionStore called user with two keys, name and colour. In the following example, we set these two values to the session, and then pass an example UserHandler object the session store.

function example(Session $session, UserHandler $userHandler):void {
	$session->set("user.name", "Cody");
	$session->set("user.colour", "orange");

// The data can be read in the same way - `$session->get("user.name")`

	$userHandler->handleUserData($session->getStore("user"));
}

The UserHandler can do whatever it wants with the data stored in the user session namespace, but it will never be able to read/write to other areas of the session.

SessionStore usage

SessionStore objects can help you isolate session storage between different areas or components of your system. This isolation can be particularly helpful when you're developing a complex PHP application with multiple modules or subsystems, each needing to maintain its own session data.

Data can be read and written to a SessionStore, which will automatically save the changes to the appropriate namespace within the PHP session. The application code reading/writing to a SessionStore does not need to know where how the data is being persisted.

If an object of the application requires session usage, it's common to pass a SessionStore into the constructor. If there is no SessionStore under the provided key yet, one can automatically be created for you by passing true as an optional second parameter to the getStore function.

function example(Session $session):void {
	$userRepo = new UserRepository($session->getStore("auth", true));
}

Our example UserRepository class can be implemented like this:

class UserRepository {
	public function __construct(private SessionStore $session) {}

	public function setUsername(string $username):void {
		$this->session->set("username", $username);
	}

	public function getUsername():?string {
		return $this->session->getString("username");
	}
}

The UserRepository can read and write any data to any key or sub-namespace of the provided SessionStore without worrying about clashing with any data stored by other areas of the system - it's completely encapsulated.


In the next section, learn about how the session cookie works.

Clone this wiki locally