È buona pratica caricare i modelli come servizio come faccio quando utilizzo il framework Symfony?

1

Solitamente su Symnfony framework utilizzo il contenitore di iniezione di depiction fornito e su Controller I carica i modelli come servizio. Per essere più in dettaglio su un progetto corrente sto avendo il seguente services.yml :

# Learn more about services, parameters and containers at
# http://symfony.com/doc/current/book/service_container.html
parameters:
#    parameter_name: value

services:
#    service_name:
#        class: AppBundle\Directory\ClassName
#        arguments: ["@another_service_name", "plain_value", "%parameter_name%"]

##################### Crud Managers ##########################
  pet_manager:
    class: AppBundle\Managers\CRUD\PetManager
    arguments: ["@doctrine.orm.entity_manager"]

  person_manager:
    class: AppBundle\Managers\CRUD\PersonManager
    arguments: ["@doctrine.orm.entity_manager","@pet_manager"]

############################ Models ###########################

  person_model:
    class: AppBundle\Models\PersonModel
    arguments: ["@person_manager"]

Che sul mio modello ho la Business Logic di base e uso i gestori per recuperare i dati da db o per eseguire azioni di terze parti come interfacciare una API di terze parti, gestire filesystem ecc. Tutti i manager vengono iniettati nel Modelli tramite Iniezione di Decisione.

In Symfony sul mio controller uso:

$personModel = $this->get('person_model');

Per caricare il modello.

Ma questa è considerata una buona pratica-approccio-architettura per poter essere applicata in altri framework o applicazioni php vanilla? Quali avvertenze possono avere?

    
posta Dimitrios Desyllas 12.02.2017 - 11:20
fonte

2 risposte

1

Un paio di cose.

Cerca di evitare suffissi generici come Manager o Modello. In realtà non indicano a cosa serve la classe. E infatti, @ Richard87 pensa che PersonModel sia un'entità di una singola persona quando chiaramente non lo è.

Il fatto che gli oggetti del tuo manager dipendano da altri gestori non verrà ridimensionato. Si può facilmente finire con tre, quattro, cinque gestori ciascuno a seconda l'uno dall'altro. Cerca invece di pensare in termini di modelli di domini in cui ogni "manager" è più o meno autonomo. Pertanto, se il dominio coinvolge persone con animali domestici, imposta un gestore per gestire entrambe le entità.

Evitare di iniettare il gestore di entità quando possibile. Invece iniettare repository come quello limita almeno parzialmente l'ambito di ciascuna classe. Infatti, invece di un gestore potresti essere in grado di aggiungere la tua logica direttamente alla classe del repository.

Infine, se vuoi raggiungere un certo livello di indipendenza dal framework (e forse anche test migliori), allora considera di definire le azioni del tuo controller come servizi (i documenti ti dicono come). In questo modo si elimina la necessità del modello di localizzazione del servizio e della necessità di un codice specifico del framework come $ this- > get (). Le tue azioni vengono semplicemente iniettate con tutto ciò di cui hanno bisogno per svolgere il loro lavoro.

    
risposta data 17.02.2017 - 20:46
fonte
1

No, non è una buona pratica.

Prima di tutto, gli oggetti dominio non dovrebbero sapere nulla sulla persistenza ...

In secondo luogo, lo stato dell'oggetto sarà in uno stato non valido se si carica l'oggetto da un database (il costruttore non verrà chiamato e il repository non verrà iniettato).

    
risposta data 17.02.2017 - 09:08
fonte

Leggi altre domande sui tag