ORM in qualsiasi momento diventa un "requisito" per l'API RESTful?

Question

ORM in qualsiasi momento diventa un "requisito" per l'API RESTful?

#1 da (9 voti)

3

Ho iniziato a creare un'API RESTful nel framework Slim di PHP. Il framework mi ha affascinato per il suo design leggero e le caratteristiche di routing. Sto usando PostgreSQL per il database.

Tuttavia, il set di dati è piuttosto grande - ci sarebbero circa 20 tipi di risorse, con molte associazioni e set annidati. Finora, ho implementato i miei metodi personalizzati ORM su classi di risorse, come "seleziona dal database per chiave primaria". Slim non fornisce alcuna funzionalità ORM. Mi chiedo se la scala dell'API sia sufficientemente ampia da raccomandare l'uso di un framework con supporto ORM integrato o integrazione con un ORM come Doctrine o Propel.

Sono al punto in cui dovrei usare un ORM per aiutare a mitigare la complessità delle modifiche alle tabelle del database, ai nomi degli attributi, ecc.?

Sono anche aperto all'utilizzo di altre tecnologie - sembra che Django di Python sia considerato come un framework per la costruzione di API RESTful.

api-design php rest orm

posta Rob 01.02.2015 - 00:11

fonte

1 risposta

Leggi altre domande sui tag api-design php rest orm

Perché CI stabilisce che dovremmo essere in grado di eseguire il rollback su qualsiasi versione di un software? Stima del tempo di esecuzione dell'algoritmo

score 9 · Accepted Answer

Un ORM non è un requisito per qualsiasi progetto di qualsiasi scala. Più spesso, i piccoli progetti iniziano con un ORM, quindi lo abbandonano durante il ridimensionamento.

Se le modifiche al database diventano troppo complesse:

Chiediti perché il database cambia troppo spesso.

Ho dovuto lavorare su progetti in cui il database è stato modificato almeno una volta al giorno, solo perché il progetto è stato pensato male, i requisiti non sono stati raccolti correttamente e il database originariamente creato da una persona che non sapeva nulla dei database in generale. Un incubo inutile.
Se hai riscontrato che le modifiche sono dovute alla complessa e volatile struttura dei dati che si estende costantemente, prendi in considerazione l'utilizzo di database non relazionali. Un modello di documento (come quello usato in MongoDB) può corrispondere meglio alle tue esigenze.
Se non ci sono molti cambiamenti, ma sei semplicemente sopraffatto dalle dimensioni dello schema, prendi in considerazione la possibilità di dividere il tuo servizio in più di un proprietario di una parte di un database.

Limitando ogni servizio a utilizzare solo una parte di un database (e chiamando altri servizi per accedere ad altri dati), è possibile rendere molto semplice la gestione delle modifiche: l'ambito di ciascuna modifica sarebbe limitato a un servizio interessato di essere sparsi sulla base del codice.