Come gestire le convenzioni di denominazione lato server e lato client che si scontrano? [chiuso]

Question

Come gestire le convenzioni di denominazione lato server e lato client che si scontrano? [chiuso]

#1 da (2 voti)

3

Ho un progetto che usa la convenzione di denominazione underscore per il database MySQL e gli script PHP, ma usa camelCase per l'applicazione javascript (uno scenario comune sono sicuro).

Tuttavia, una volta che gli oggetti codificati JSON vengono inviati dal lato server al lato client, la convenzione di denominazione javascript viene inquinata con oggetti che hanno proprietà che utilizzano la convenzione di denominazione di sottolineatura!

La mancata corrispondenza diventa evidente, ad esempio, quando una proprietà dell'oggetto JSON viene confrontata direttamente con una variabile locale, ad es.

function matchCustomerByName(customer, firstName, lastName){
  if (customer.first_name === firstName && customer.last_name === lastName) {
     ...
  }
}

Forse è solo per me, ma non mi piace la mancata corrispondenza dello stile di denominazione sopra. La mia domanda è: sono metodi standard / preferiti / accettati per risolvere il problema? È anche un problema?

Sono tentato di usare camelCase per l'intero progetto (MySQL, PHP e javascript). La funzione precedente dovrebbe quindi leggere:

function matchCustomerByName(customer, firstName, lastName){
  if (customer.firstName === firstName && customer.lastName === lastName) {
     ...
  }
}

Tuttavia, l'utilizzo di camelCase per il database MySQL sembra andare contro la pratica comune.

Forse potrei convertire tra le due convenzioni di denominazione nella fase PHP? C'è un modo semplice (a prova di errore) per farlo?

javascript naming mysql json

posta David 19.02.2015 - 01:31

fonte

1 risposta

Leggi altre domande sui tag javascript naming mysql json

Protezione delle chiamate di servizio Agile: QA senza risorsa di test dedicata

score 2 · Answer 1

Dovresti dare per scontato che gli oggetti di dati lato server utilizzino le proprie convenzioni e che il lato client ne abbia il proprio. Durante il recupero / la pubblicazione di dati, è possibile impostare un adattatore modello per gestire il passaggio tra i due. Facendolo a questo livello, ciascuna parte usa le proprie convenzioni che hanno senso nei contesti di ognuno.

Dopo aver recuperato i tuoi dati da un ajax get, o qualsiasi altra cosa, puoi passarli a una funzione dell'adattatore in questo modo:

function adaptCustomerFromGET(json) {
  return {
    firstName: json.first_name,
    lastName: json.last_name,
    ...
  };
}

function adaptCustomerForPOST(model) {
  return {
    first_name: model.firstName,
    last_name: model.lastName,
    ...
  };
}

Certo, è un altro posto da aggiornare quando il tuo modello cambia, ma è incredibilmente comune fare questo genere di cose, dal momento che qualsiasi API lato server a cui ti stai collegando potrebbe avere delle convenzioni molto diverse da quelle di cui avresti bisogno lato client, inclusa la struttura dei dati stessi; potresti ottenere una lista dal server che preferisci per costruire una mappa per lavoro lato client.