Sono cresciuto in una parte dello sviluppo web in cui la creazione di siti Web è per la maggior parte sinonimo di Wordpress, FTP, Joomla e codice procedurale, invece di cose come TDD, test A / B, Doctrine e modelli di progettazione. Non avendo viaggiato molto in quest'area, mi piacerebbe sapere quando la mappatura relazionale degli oggetti e gli strumenti ORM sono necessari per creare e gestire un sito. Puoi fornire alcuni esempi generici (ma reali) di quando dovrebbe essere usato?
necessario? Mai.
Gli ORM sono uno strato di astrazione sul database. Sono intesi come traduttori tra grafici di oggetti e tabelle / relazioni di database. In questa capacità semplificano l'accesso semplice ai dati e con un modello / database di oggetti di grandi dimensioni possono risparmiare molto tempo altrimenti impiegato per scrivere il codice boilerplate per l'accesso ai dati (ottenendo un record per ID, cancellandolo per ID, aggiornando e inserendo un record). / p>
Utile? Quasi sempre, per i punti sopra riportati.
Non ci sono regole, in quanto tali, ma gli ORM vengono utilizzati al meglio per le operazioni di base del DB (Inserisci, Aggiorna, Elimina, Seleziona). Quando hai bisogno di qualcosa di più complesso, è meglio utilizzare l'API standard per la tua piattaforma.
Gli strumenti ORM devono essere utilizzati per CRUD, che l'80% di codice che è così noioso da scrivere ancora e ancora, che vuoi sbattere la testa contro il muro.
Sentiti libero di usare più metodi "vecchia scuola" come Stored Procedures per il restante 20% (ad es. operazioni che richiedono l'ottimizzazione delle prestazioni).
Per un semplice esempio di come gli ORM possono essere utilizzati efficacemente per creare una classe di repository organizzata ed efficace per il recupero e l'aggiornamento dello stile CRUD dei dati del database, vedere qui:
Gli ORM servono due gol utili;
La maggior parte degli ORM è uno strumento di tipo 80-20, in cui è possibile semplificare in modo significativo circa l'80% del lavoro di persistenza, rispetto all'utilizzo diretto di SQL. Per le applicazioni semplici, l'80% è davvero al 100%, dal momento che la piattaforma può spesso orientare le decisioni di progettazione.
Le applicazioni più grandi e complesse avranno sempre problemi che non potrebbero essere stati anticipati da nessuno strumento. La differenza tra gli ORM buoni e cattivi si manifesta in netto sollievo quando ciò accade.
Un buon ORM si disinteresserà degli sviluppatori quando devono emettere un codice SQL personalizzato per ottenere i propri dati, o persino fornire semplici meccanismi di estensione o introspezione per crescere nell'uso necessario. I poveri si intromettono in questo genere di cose; richiedere agli sviluppatori di eseguire questi lavori personalizzati su un livello inferiore.
Ottenere il massimo dalle funzionalità di mappatura delle classi degli ORM richiede spesso una profonda comprensione da parte degli sviluppatori di ORM del ruolo degli oggetti delle applicazioni. Gli oggetti del modello svolgono un ruolo molto diverso dallo stato persistente che avvolgono.
In particolare, le righe e le colonne in un database rappresentano l'insieme di fatti ritenuti veri, ma i metodi e i grafici di ereditarietà dei modelli sono le regole e le formule su cui l'applicazione opera.
Quando un ORM fonde le due idee, ostacoleranno gli sviluppatori in un numero di modi idiomatici. Non ci sarà modo di operare su relazioni che non fanno parte di una tabella (ovvi controesempi sono le righe restituite da un select contenente joins o group by clauses). Un'altra ripartizione è che presuppongono che ogni tabella debba avere una chiave primaria; o che la chiave primaria deve essere un numero intero o una singola colonna. Un modo più sottile in cui gli ORM possono rovinarlo è fornire funzionalità di oggetti, come le proprietà many-to-many, che in qualche modo richiedono una connessione al database per funzionare correttamente (la relazione dell'entità non è correlata alla persistenza).
Se la tua applicazione utilizza un database relazionale, il tuo codice conterrà molto SQL (o LINQ se stai usando .NET).
L'idea è di semplificare l'interazione tra il codice dell'applicazione e il database creando il livello di accesso ai dati e oggetti business in modo rapido e senza codifica, ma consente allo sviluppatore di estendere la logica aggiungendo speciali regole aziendali (se presenti).
Gli strumenti di mappatura relazionale degli oggetti sono molti. Non tutti gli strumenti sono uguali. Alcuni sono semplici, mentre altri sono abbastanza complessi per essere un intero framework.
Si basano su database già costruiti (tabelle) e leggono le definizioni della tabella dal database, quindi:
0: crea classi che rappresentano oggetti (di solito 1 a 1), tali classi contengono metodi per leggere, scrivere, aggiornare e cancellare dati dal database. Alcuni supportano LINQ (.Net) e alcuni hanno il proprio linguaggio di interrogazione degli oggetti.
1 - Gestisce automaticamente la generazione della chiave primaria e le relazioni tra tabelle
2: in grado di leggere e restituire automaticamente i dati relativi a una tabella con una chiamata al metodo
3: consente di cambiare il database senza codifica
4-Prenditi cura del buffering dei dati per migliorare le prestazioni
5-Genera l'SQL necessario per ottenere e inserire automaticamente i dati nel database
6: alcuni generano automaticamente i servizi Web (ad esempio Oxygen)
7-Alcuni possono generare automaticamente il codice di controllo
8-Alcuni possono creare stored procedure
9-Alcuni forniscono il supporto per l'autorizzazione
10: alcuni supportano automaticamente l'architettura a più livelli
11-Alcuni supportano .NET Entity Framework
Quindi, se hai bisogno di uno dei servizi di cui sopra nel tuo progetto, l'ORM potrebbe essere per te.
Potrebbe essere qualcosa per te decidere se vuoi utilizzare ORM o Entity Framework se sei un utente .NET.