Application Service Layer - cómo escribir interfaces de método API

Question

¿Cómo diseñan las interfaces de capa de servicio?

Estoy programando una aplicación web grande (en PHP) y estamos utilizando MVC, y programamos controladores delgados, p. Ej. (Pseudo código sigue)

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

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

    ... etc 
} 

En caso savePerson en el servicio toma un argumento de toda la estructura de entrada de $ o contexto (en PHP, una matriz asociativa)?

E.g. esto -

public function savePerson(array $input) { 

o debería uno separar todos los campos de entrada y proporcionar una interfaz "dura", p.

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

Thanks.

Paul

Answer 1

Si va a seguir el espíritu de MVC, su método savePerson no debe aceptar la entrada sin procesar. No debe estar directamente relacionado con el formato de los datos que provienen de la interfaz de usuario. En su lugar, debe aceptar la entrada definida en los términos de su dominio de servicio, como un objeto "persona". (Esto podría ser simplemente una matriz asociativa como sugirió Cobby). El trabajo del método de acción del controlador sería asignar la entrada sin procesar al formato requerido por el servicio.

El beneficio de este paso de traducción adicional es que aísla su servicio (modelo) de la interfaz de usuario. Si implementa una interfaz de usuario diferente, no necesita cambiar la interfaz de servicio. Solo necesita escribir nuevos controladores (y vistas, por supuesto).

Si bien su ejemplo como savePerson($title, $firstName, $lastName...) es la idea correcta, generalmente es una mala señal cuando tiene métodos con más de 2 o 3 argumentos. Debería poder agrupar argumentos relacionados en algún tipo de objeto de nivel superior.

Answer 2

Mis aplicaciones MVC están estructurados de la siguiente manera: Controlador -> Servicio -> ORM/otra biblioteca

Para responder a su pregunta, por lo general en su controlador que va a obtener los datos del formulario como una matriz , es decir, $ form-> getValues ​​() o algo similar. En términos de mantenibilidad, es mejor si sus Servicios excepto matrices como argumentos, de esa manera si agrega otro campo a un formulario, solo tiene que actualizar el formulario y el servicio, su controlador puede permanecer intacto y seguir funcionando.

Así que creo que ir con su primer ejemplo:

public function savePerson($personArray); 

Por otra parte, no debe necesitar una interfaz de "duro" debido a que su biblioteca de formularios se hará cargo de la validación/filtración/higienización por lo que podemos asumir que la matriz asociativa será válida, además la definición del método será ridículamente larga con los parámetros nombrados.

Answer 3

Yo separaría todos los campos de entrada y proporcionaría una interfaz "dura" en el servicio, p.

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

Su limpiador y no se necesitan suposiciones.