Download the PHP package azjezz/sweet without Composer

Sweet

Sweet, a strict typed hack service container and locator !

Installation

This package can be install with Composer.

Usage

Creating a container is a matter of creating a ServiceContainer instance:

Defining Services

A service is an object that does something as part of a larger system. Examples of services: a database connection, a templating engine, or a mailer. Almost any global object can be a service.

Services are defined by factories that return an instance of an object:

Notice that the factory has access to the current container instance, allowing references to other services.

You can also create a factory from a function using the Sweet\factory() helper.

As objects are only created when you get them, the order of the definitions does not matter.

Using the defined services is also very easy:

Shared Services

Each time you get a service, Sweet returns a new instance of it. If you want the same instance to be returned for all calls, set the shared argument to true or use the ->share() proxy.

Now each call to $container->get(Session::class); will return the same instance of the session.

Defining Parameters

Defining a parameter allows to ease the configuration of your container from the outside and to store global values:

You can now easily change the cookie name by overriding the SessionCookieName parameter instead of redefining the service definition.

Service Providers

Service providers give the benefit of organising your container definitions along with an increase in performance for larger applications as definitions registered within a service provider are lazily registered at the point where a service is retrieved.

To build a service provider it is as simple as implementing the service provider interface and defining what you would like to register.

To register this service provider with the container simply pass an instance of your provider to the register method.

The register method is not invoked until one of the aliases in the $provides container is requested by the service container, therefore, when we want to retrieve one of the items provided by the service provider, it will not actually be registered until it is needed, this improves performance for larger applications as your dependency map grows.

Definitions

Definitions are how ServiceContainer describes your dependency map internally. Each definition contains information on how to build your service.

Generally, ServiceContainer will handle everything that is required to build a definition for you. When you invoke add, a Definition is built and returned meaning any further interaction is actually with the Definition, not ServiceContainer.

You can also extend a definition if needed.

Note: you can't call extend() for services that are registered via a service provider.

Creating definitions manually and passing them to the container is also possible.

We can tell a definition to only resolve once and return the same instance every time it is resolved.

In some cases you may want to modify a service definition after it has been defined. You can use the inflect method to define additional code to be run on your service just after it is created:

Service Locators

Some Services need access to serveral other services. The traditional solution in those cases was to inject the entire service container to get the services really needed. However, this is not recommended because it gives services too broad access to the rest of the application and it hides the actual dependencies of the services.

Service locators are a design pattern that "encapsulate the processes involved in obtaining a service [...] using a central registry known as the service locator". This pattern is often discouraged, but it's useful in these cases and it's way better than injecting the entire service container.

Consider a RouteDispatcher class that maps routes and their handlers. This class dispatches only one route handler at a time, so it's useless to instantiate all of them.

First, define a service locator service with a newtype and add all the request handler to it.

Then, inject the service locator into the service definition for the route dispatcher:

The injected service locator is an instance of Sweet\ServiceLocator. This class implements the Sweet\ServiceContainerInterface, which includes the has() and get() methods to check and get services from the locator:

Security Vulnerabilities

If you discover a security vulnerability within Sweet, please send an e-mail to Saif Eddin Gmati via [email protected].

License

The Sweet Project is open-sourced software licensed under the MIT license.