Dove dovrebbe avvenire la formattazione della data in un pattern MVC?

Question

Dove dovrebbe avvenire la formattazione della data in un pattern MVC?

#1 da (10 voti)
#2 da (6 voti)
#3 da (4 voti)
#4 da (2 voti)
#5 da (0 voti)

6

Supponiamo che tu voglia mostrare un elenco utenti, su un'applicazione web che deve gestire formati di data personalizzati (a seconda della lingua dell'interfaccia selezionata corrente).

Sono possibili diverse posizioni per l'applicazione del formato data. Quale useresti e perché?

Al modello, ad esempio facendo un DATE_FORMAT(user.birthdate, '%d/%m/%Y') per i campi data (supponiamo di avere un DB MySQL).

A livello di controller, ad esempio (supponiamo di utilizzare PHP):

$users = UserModel::getUsers();
// loops through results before display to format dates.
// in the $users structure, we have to know which fields are dates or not
$users = MagicFunctionFormattingDates($users);

$view = new View('someTemplate');
$view->assign('users', $users);

A livello di vista, ad esempio (supponiamo di utilizzare un linguaggio modello come Smarty):

{foreach key=keyitem item=row from=$users}
  <tr>
  {foreach key=keyfield item=field from=$row.fields}
     {* Here $field should be an Object or associative array
        holding its 'type' (is it a date or something else) *}
     <td>{MagicFunctionForFormatting field=$field}</td>
  {/foreach}
  </tr>
{/endforeach}

Una domanda simile e correlata vale per le date di registrazione (ad esempio su un modulo di registrazione utente). Dove dovrebbe avvenire la conversione della data:

Nel controller che elabora e convalida il modulo, prima di chiamare il modello?
Nel modello?

design web-development data-structures web-applications mvc

posta Frosty Z 22.12.2011 - 13:05

fonte

5 risposte

10

Dipende solo da te.

Lo considererei un dettaglio di visualizzazione. Se dovessi sostituire il front-end con un servizio web, vorresti "visualizzarlo" in un modo completamente diverso. E così l'ho messo in evidenza. Personalmente.

risposta data 22.12.2011 - 13:11

fonte

4

La regola generale che vuoi convertire da / a tipi di data il più vicino possibile all'utente - questo è vero per tutti i valori ma soprattutto per le date.

Le date che sono memorizzate come tipo di data appropriato non sono ambigue (o il più vicino possibile) non appena si passa a una stringa si hanno tutti i tipi di opportunità per cui le cose vanno male. Quindi, a meno che tu non abbia una buona ragione per fare diversamente (quale di volta in volta fa), devi convertire in entrambe le direzioni nella UX o il più vicino possibile.

Se questi erano numeri che probabilmente non ti chiederebbero e tuttavia è essenzialmente la stessa cosa.

risposta data 22.12.2011 - 15:07

fonte

2

Mi piace gestire la presentazione della data (vista) e la codifica (invio) al visualizzatore. Lo converto immediatamente nel formato desiderato per la data di back-end e rimango con quel formato nel back-end.

Un avvertimento: ogni sistema di back-end "buono" che ho sviluppato è stato integrato con altri sistemi, rendendo necessaria una certa quantità di conversione della data nel back-end. Solitamente rimando il problema a se / quando questi sistemi aggiuntivi ne hanno bisogno, e rispondo al piano che ho indicato sopra.

risposta data 23.12.2011 - 01:22

fonte

0

Several locations for applying the date format seem possible. Which one would you use, and why?

La vista, perché la formattazione del testo è correlata alla vista.

A similar and related question goes for submitting dates (e.g. on a user registration form). Where should the date conversion take place?

Il modello, tramite un metodo setter appropriato.

risposta data 23.12.2011 - 05:01

fonte

Leggi altre domande sui tag design web-development data-structures web-applications mvc

Come dovrei iniziare a refactoring la mia applicazione C ++ per lo più procedurale? Qual è il modo migliore per accedere a più proprietà figlio?

score 6 · Accepted Answer

Suggerirei due cose:

Il modello è dove avviene l'I / O del database. In tal caso, si desidera che tutto quello che entra e che esce dal database sia un modulo predefinito. Questa è la tua forma "neutra", l'interfaccia definita per tutto il resto che deve essere sempre coerente.
Dopo aver ottenuto 1 clear, puoi fare le trasformazioni da qualche altra parte. In quale altro posto dipende il tuo progetto.

TUTTAVIA ... nel pensare un po 'di più, supponiamo che il formato della data cambi. Supponiamo, inoltre, di consentire che il formato della data sia presentato in base alle preferenze dell'utente.

In questo caso sembrerebbe avere 2 scelte:

Modello: l'interfaccia è nel formato preferito dagli utenti. OR
Modello: l'interfaccia è sempre il formato neutro, nel qual caso VIEW dovrebbe probabilmente essere il punto in cui ti converti / dal modo in cui l'utente può vederlo.

Andando con l'opzione 2, ciò significa che il controller può sempre funzionare anche con il formato neutro, il che significa che le funzioni di codifica / operazioni in esso potrebbero essere più facili e / o meno inclini a cambiare o rielaborare.

Tuttavia, tutto dipende da ciò che stai cercando di ottenere.

La mia opinione finale su tutto questo: mantieni una forma neutrale il più a lungo possibile e poi converti il / la modulo preferito dall'utente il più tardi possibile. (E questo probabilmente significa che View è dove dovrebbero avvenire le tue trasformazioni).