Come devono essere gestite le dipendenze attraverso un'applicazione modulare?

Question

Come devono essere gestite le dipendenze attraverso un'applicazione modulare?

#1 da (2 voti)

1

Diciamo che abbiamo una struttura come questa:

Application
    -- Modules
        --Module1
            -- Controller
            -- PublicHelper 

        --Module2
           -- Controller
           -- PublicHelper

In cui il Public Helper di un modulo può fornire funzioni di supporto.

In quasi ogni helper di moduli, l'helper deve accedere ai metodi di supporto pubblico di un altro modulo.

Diciamo per esempio, in un'applicazione PHP:

Module1 fornisce funzionalità per creare una vendita e come parte di

class Module1PublicHelper extends AbstractModuleHelper {

    public function createSale($customerId, $param, $param)
    {
         $userPublicHelper = // grab an instance of the user public helper
         $currentUser = $userPublicHelper->getCurrentUser();
    }
}

class Module2PublicHelper extends AbstractModuleHelper {

    public function getCurrentUser()
    {
         //do something
         return $user;
    }
}

In questa situazione, il metodo deve ottenere un'istanza, nuova o qualsiasi altra cosa del helper pubblico dell'utente.

Dato che tutte le classi di Public Helper del modulo sono istanziate con un set minimo di parametri del costruttore, ad es. EntityManager, quale sarebbe il modo migliore per ottenere una copia di esso?

Ovviamente, non possiamo davvero inserire la classe helper pubblica dell'utente nella classe contenente createSale

Una soluzione sarebbe utilizzare un localizzatore di servizi o un registro, tuttavia, testare l'applicazione non è esattamente facile.

dependency-injection php service-locator

posta bear 03.01.2014 - 14:55

fonte

1 risposta

Leggi altre domande sui tag dependency-injection php service-locator

Unit test codice DAO che utilizza SQLite quando il database dell'applicazione è Oracle Quale schema di progettazione corrisponde a questo problema il più vicino?

score 2 · Answer 1

Nella maggior parte dei casi, questo potrebbe essere solo due strati dello stesso modulo. La differenza tra livelli e moduli è che quando i livelli sono uno sopra l'altro, gli strati superiori possono chiedere informazioni dal livello inferiore.

Se hai davvero due moduli, Module1 può avere la sua versione ridotta dell'Utente che aiuta a tenere traccia dell'identità dell'Utente o di qualsiasi altra informazione di cui il Modulo1 potrebbe avere bisogno. Questo sarà difficile se hai un'applicazione basata sui dati.

Avere Module1 dipende dal Module2 è una cattiva progettazione.

Ora lascia che provi a spiegare ulteriormente con il tuo esempio.

Hai un metodo createSale. Lo scopo di questo metodo è creare una vendita. Quello che vorrei fare in questo caso è dare per scontato che il $ customerId che viene inviato al metodo sia corretto da qualsiasi collaboratore che lo abbia chiamato. Ecco perché è necessario separare completamente il livello del modello dal livello applicazione.

Considera la seguente struttura.

Application
    -- Modules
        --Module1
            -- Controller
            -- PublicHelper 

        --Module2
           -- Controller
           -- PublicHelper
Model
    -- Sales
        -- SalesManager
        -- Sale
    -- Users
        -- UserManager
        -- User

Ora con il seguente Module1Controller, spero che tu possa capire il setup.

class Module1Controller {
    public function createSalesAction() {
        $userId = $this->getPost('user-id');

        // UserManager is injected to application level
        $user = $this->userManager->getUser($userId);

        // SalesManager is injected to application level
        $this->salesManager->createSale($user->getId(), $param1, $param2);
    }

    public function giveCredit() {
        $userId = $this->getPost('user-id');
        $credit = $this->getPost('credit');

        $this->salesManager->setCredit($userId, $credit);
    }
}

Quindi un Sales Manager di esempio potrebbe aiutare

class SalesManager {
    public function setCredit($userId, $credit) {
        $credit = new Credit($userId, $credit);
        $this->creditRepo->save($credit);
    }

    public function createSale($userId, $amount, $param2) {
        if (!$this->hasCredit($userId, $amount)) {
            throw new CustomerDontHaveCredit($userId, $amount);
        }

        $sale = new Sale($userId, $amount, $param1);
        $this->salesRepo->save($sale);
    }

    private function hasCredit($userId, $amount) {
        // get the credit
        // get sales if need and check if he has credit

        return true;
    }
}

Il modulo di vendita è completamente ignaro del modulo Utente e viceversa. Inoltre, lo sviluppo effettivo del modulo Vendite e utenti può essere completamente separato dall'applicazione reale. Il che significa che puoi simulare SalesManager e UserManager nell'app per testare.