¿Debo acceder a POST-Parameters en el modelo o pasar como argumentos de método desde el controlador?

Question

Tengo que procesar unos 20 parámetros de POST, y no estoy seguro de dónde hacerlo.

Podría definir cada uno como un argumento del método en el modelo, y pasarlos desde el controlador cuando se llame al método. Esto daría como resultado un gran trabajo y haría que la llamada a la función sea menos legible, debido a la cantidad de argumentos.

O podría llamar al método en el modelo y acceder directamente a los parámetros.

Pasar los parámetros como argumentos me daría más control sobre a qué parámetros accede la función, y la documentación sería más fácil de entender. Pero si se agregaran nuevos parámetros más adelante, tendrían que agregarse al final de la llamada al método, para no interrumpir todas las llamadas existentes. Imagino que esto sería bastante confuso si sucede algunas veces, ya que los argumentos no se pueden agrupar de manera lógica.

Si accedo al parámetro en el modelo, no se deben pasar parámetros del controlador al modelo, haciendo que el método llame a terser. Pero no tengo control sobre los parámetros a los que se accede, ya que pueden agregarse o eliminarse fácilmente y sin restricciones. Esto requeriría una mayor disciplina de los otros desarrolladores, y no me gusta depender de eso, porque tarde o temprano alguien está obligado a "simplemente (agregar | cambiar | corregir) esto muy rápido".

No estoy seguro de qué camino tomar. Tiendo a hacerlo todo solo en el modelo, ya que es más rápido de escribir, parece más fácil de mantener (sin caos argumental) y conceptualmente se ajusta mejor a mi visión de un modelo. Por otro lado, no estoy seguro de si mi visión de un modelo es correcta, y si terminará en un caos si dependo de los otros desarrolladores para actualizar siempre la documentación después de cada cambio.

Entonces, ¿qué debo hacer?

Answer 1

Bueno, ¿por qué no puedes simplemente aceptar una matriz (asociativa) como parámetro en ese método del modelo y luego pasarle la matriz $ _POST completa? Al menos en mi opinión, no rompería la encapsulación.

EDIT: Y si no te gusta el uso de matrices asociativas para eso, también puede utilizar los llamados "objetos Plain Old" (objetos que sólo se utilizan para transportar datos, como estructuras en C). Por ejemplo, si esto implicaba guardar un formulario de registro presentado:

class UserData 
{ 
    protected $name; 
    protected $username; 
    protected $password; 

    public function getName() { /* <...> */ } 
    public function setName() { /* <...> */ } 
    /* other accessors go here */ 
} 

class UserController extends Controller 
{ 
    public function register() 
    { 
     $userData = UserData::create() 
      ->setName($_POST['name']) 
      ->setUsername($_POST['username']) 
      ->setPassword($_POST['password']); 
     Users::add($userData); 
    } 
} 

Esto permitirá utilizar tipos de datos estrictos en Usuarios :: agregar y también hacen que el proceso de documentación más fácil.

Answer 2

Respondí a similar question hace un tiempo. Imho debes pasarlos, p. como ya se propuso como una matriz asociativa (y hacer todos los controles de seguridad antes). De esa manera, puedes reusar fácilmente tus clases.

Answer 3

Controlador. Porque los datos de solicitud y la manipulación del modelo no son lo mismo. Por lo tanto, se requerirá poner la lógica basada en datos de solicitud en el modelo para todas las demás solicitudes posibles, y eso es malo

Answer 4

He tenido problemas con este mismo problema, y ​​la solución que se me ocurrió es flexible, mantiene mi código reutilizable y es tolerante a los cambios en el front-end: me gusta usar setters. Por supuesto, tener un regulador para cada valor individual es un dolor, por lo que los datos de agrupación de formas lógicas ayuda:

 
$user = new User(); 
$user->setName($_POST['lastName'],$_POST['firstName']); 
$user->setAddress($_POST['address1'],$_POST['address2'],$_POST['city'],$_POST['state'],$_POST['zip']); 

Usted consigue el punto.Una vez guardado en las variables del objeto, puede usar estos valores en todos los métodos de su objeto.

Hacer que sus modelos dependan de superglobales es tan inflexible. También hace que las pruebas unitarias sean un dolor.

Answer 5

Aquí es lo que hago ...

//Object Oriented POST Replacement 
    if ($_SERVER['REQUEST_METHOD'] == 'POST') 
    { 
     $_POST = json_decode(file_get_contents('php://input')); 
    } 

que estoy escribiendo sobre todo las API que transfieren información a través de JSON con el Content-Type: application/json. Sin embargo, esto funcionará (y es mejor en mi opinión) no importa cómo se esté rellenando $_POST.

Lo que sea que estés haciendo, sugiero convertir el $_POST superglobal en un objeto. En sus modelos, acepte un solo objeto como argumento y obtenga propiedades o subpropiedades.

A partir de ahí, simplemente establezca sus métodos de controlador para llamar a los métodos de modelo con su objeto orientado a objetos $_POST superglobal como el único argumento.