Capa de Servicios de Aplicaciones - cómo escribir interfaces de métodos API

Question

¿Cómo se diseñan sus interfaces de capa de servicios?

estoy programando una aplicación web de gran tamaño (en PHP) y estamos usando MVC, y la programación de los controladores delgadas, por ejemplo, (Pseudo código siguiente)

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)?

por ejemplo. esto -

public function savePerson(array $input) {

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

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

Gracias.

Paul

Answer 1

Si usted va a seguir el espíritu de su método savePerson MVC no debe aceptar la entrada bruta. No debe ser acoplado directamente con el formato de los datos procedentes de la interfaz de usuario. En su lugar, debe aceptar la entrada se define en los términos de su dominio de servicio, como un objeto "persona". (Esto podría ser sólo un arreglo asociativo como Cobby sugirió). Sería el trabajo del método de acción del controlador para asignar la entrada bruta al formato requerido por el servicio.

El beneficio de este paso de traducción adicional es que aísla su servicio (modelo) en el interfaz de usuario. Si implementa una interfaz de usuario diferente, que no es necesario cambiar la interfaz de servicio. Sólo tiene que escribir nuevos controladores (y puntos de vista, por supuesto).

Mientras que su ejemplo como savePerson($title, $firstName, $lastName...) es la idea correcta, por lo general es una mala señal cuando se tiene métodos con más de 2 o 3 argumentos. Usted debe ser capaz de argumentos relacionados con el grupo en una especie de objeto de nivel superior.

Answer 2

Mi 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 capacidad de mantenimiento es mejor si sus servicios excepto matrices como argumentos, de esa manera si se agrega otro campo de un formulario, sólo tienen que actualizar la forma y el servicio, el controlador puede permanecer intacta y todavía trabajo.

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 suponer que la matriz asociativa será válida, además de la definición del método obtendrá ridículamente largo con el nombre parámetros.

Answer 3

Yo separaría a cabo todos los campos de entrada y proporcionar una interfaz de "duro" en servicio por ejemplo.

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

Su más limpio y no hay supuestos necesarios.