Livello del servizio dell'applicazione: come scrivere le interfacce del metodo API

Question

In che modo le persone progettano le interfacce del livello di servizio?

Sto programmando una grande applicazione web (in PHP) e stiamo utilizzando MVC e programmando controller sottili, ad es.(segue lo pseudocodice)

public savePersonAction() {
    $input = filter($_GET);
    ... input validation ...

    $result = $this->_service->savePerson( ? );

    ... etc
}

SavePerson nel servizio dovrebbe accettare un argomento dell'intera struttura o contesto $input (in PHP, un array associativo)?

Per esempio.Questo -

public function savePerson(array $input) {

o si dovrebbero separare tutti i campi di input e fornire un'interfaccia "hard", ad es.

public function savePerson($title, $firstName, $lastName, $dateOfBirth, ... etc.. for many more) {

Grazie.

Paolo

Answer 1

Se avete intenzione di seguire lo spirito tuo metodo savePerson MVC non dovrebbe accettare l'ingresso crudo. Non deve essere direttamente accoppiato con il formato dei dati provenienti dall'interfaccia utente. Invece dovrebbe accettare input definito nei termini del vostro dominio di servizio, come un oggetto "persona". (Questo potrebbe essere solo un array associativo come Cobby suggerito). Sarebbe compito del metodo di azione del controller per mappare l'ingresso prima al formato richiesto dal servizio.

Il vantaggio di questa fase di traduzione in più è che isola il servizio (modello) dall'interfaccia utente. Se si implementa un'interfaccia utente diversa, non è necessario cambiare l'interfaccia del servizio. Hai solo bisogno di scrivere nuovi controllori (e punti di vista, ovviamente).

Mentre il vostro esempio come savePerson($title, $firstName, $lastName...) è l'idea giusta, di solito è un brutto segno quando si hanno i metodi con più di 2 o 3 argomenti. Si dovrebbe essere in grado di argomenti correlati di gruppo in una sorta di oggetto di livello superiore.

Answer 2

Le mie applicazioni MVC sono strutturate in questo modo:Controller -> Servizio -> ORM/altra libreria

Per rispondere alla tua domanda, in genere nel tuo controller riceverai i dati del modulo come un array, ad es.$form->getValues() o qualcosa di simile.In termini di manutenibilità è meglio se i tuoi servizi eccetto gli array come argomenti, in questo modo se aggiungi un altro campo a un modulo, devi solo aggiornare il modulo e il servizio, il tuo controller può rimanere intatto e continuare a funzionare.

Quindi penso di seguire il tuo primo esempio:

public function savePerson($personArray);

Inoltre, non dovresti aver bisogno di un'interfaccia "difficile" perché la libreria dei moduli si occuperà della convalida/filtraggio/sanificazione, quindi possiamo presumere che l'array associativo sarà valido, inoltre la definizione del metodo diventerà ridicolmente lunga con parametri denominati.

Answer 3

Vorrei separare tutti i campi di input e di fornire un'interfaccia "duro" in servizio per es.

public function savePerson($title, $firstName, $lastName, $dateOfBirth) {...}

La sua più pulita e non ci sono assunzioni necessarie.