Skip to main content

Codeigniter service

Què és un Service a CI4?

Tècnicament, un Service a CodeIgniter 4 és simplement un mètode dins de la classe App\Config\Services (que hereta de CodeIgniter\Config\BaseService).

Actua com un Contenidor de Dependències (Service Locator). La seva responsabilitat és:

  1. Saber com construir una classe complexa (llegir config, passar paràmetres al constructor).

  2. Decidir quan construir-la (lazy loading).

  3. Decidir quantes vegades construir-la (Singleton vs Factory).

El problema "Sense Services" (L'Antipatró)

Imagina que al teu Model fas això directament:

PHP 
// ALERTA: Mala pràctica dins d'un Model
protected function generateSnowflake() {
    // 1. Estem "cremant" (hardcoding) la configuració aquí
    $datacenterId = 1; 
    $workerId = 1;

    // 2. Creem una instància NOVA cada vegada que cridem la funció
    $snowflake = new \Godruoyi\Snowflake\Snowflake($datacenterId, $workerId);

    return $snowflake->id();
}

Per què això és perillós per a Snowflake?

  • Pèrdua d'Estat (State): L'algorisme Snowflake necessita recordar l'últim mil·lisegon utilitzat i la seqüència actual (0-4095) per evitar col·lisions si es generen dos IDs al mateix moment.

  • Si fas new Snowflake(...) cada vegada, la nova instància no sap que l'anterior ja ha generat un ID en aquest mil·lisegon. La seqüència es reinicia. Resultat: Col·lisió d'IDs.

La solució: El Service (Singleton)

Quan definim el mètode a Config/Services.php i fem servir getSharedInstance, estem garantint que només existeixi una instància de la classe en tota l'execució de l'script.

PHP 
// A Config/Services.php
public static function snowflake($getShared = true)
{
    // Si $getShared és true (per defecte), retorna la instància JA creada anteriorment.
    if ($getShared) {
        return static::getSharedInstance('snowflake');
    }

    // Aquesta part només s'executa UNA vegada per petició
    return new Snowflake(env('DC_ID'), env('WORKER_ID'));
}

Els avantatges 


A. Gestió de l'Estat (Singleton Pattern)

Com hem vist amb Snowflake, necessitem que l'objecte "visqui" durant tota la petició per mantenir comptadors interns.

  • Sense Service: 10 inserts = 10 objectes nous = Risc de col·lisió.

  • Amb Service: 10 inserts = 1 objecte reutilitzat = Seguretat total.

B. Desacoblament i Configuració Centralitzada

El Model no ha de saber que l'ID del Datacenter ve d'una variable d'entorn anomenada SNOWFLAKE_DATACENTER_ID. El Model només vol un ID. Si demà canvies la llibreria de Snowflake per una altra, o canvies la forma de llegir la config, només toques el fitxer Services.php. Els teus 50 models que fan servir IDs no s'han de modificar.

 

Diagrama

Pots incloure un diagrama mental com aquest:

  1. Request arriba.

  2. Controller crida Model.

  3. Model demana: "Necessito el servei snowflake".

  4. Config\Services mira: "Ja tinc una instància creada a la memòria?"

    • Sí: La retorna (Molt ràpid).

    • No: Llegeix el .env, fa el new, guarda la instància i la retorna.

  5. Model usa l'objecte sense saber d'on ha sortit ni com s'ha configurat.


Back to top