ORM è un problema specifico alla programmazione orientata agli oggetti?

Question

Object-Relational Mapping ORM è un problema che deve essere risolto in tutte le applicazioni che viene implementata in un oggetto orientato linguaggio di programmazione e utilizzano un database relazionale.

Ma non è il problema lo stesso se si utilizza le strutture di mappare i database relazionali in C? E tuple / record in un linguaggio di programmazione funzionale? O mi sto perdendo qualcosa dal momento che non ho scritto un'applicazione di database in C o in un linguaggio funzionale.

Answer 1

Beh, sì e no .

Cosa si fa riferimento è noto come il Object-Relational impedenza disadattamento , che è il problema di trasferire i dati tra un modello Object-Oriented e un modello entità-relazione . La difficoltà è dovuta ai intrinsecamente diversi modi di strutturare e memorizzare le informazioni nei due modelli, dove OO è gerarchica, mentre ER è tabellare .

Object-Relational Mapping è una tecnica che i tentativi di risolvere l'impedenza relazionale a oggetti disadattamento problema.

L'oggetto-relazionale disadattamento di impedenza termine è specifico per il orientata agli oggetti e < a href = "http://en.wikipedia.org/wiki/Entity-relationship_model" rel = "noreferrer"> modelli entità-relazione . Tuttavia la parola " impedenza " resistenza mezzi o difficoltà, per cui il termine " disadattamento di impedenza " potrebbero essere utilizzati per esprimere il problema generale di mappatura tra due modelli di dati incompatibili / tipo sistemi.

Answer 2

Aneddoticamente, almeno, questa "disadattamento di impedenza" sembra essere peculiare a situazioni in cui si voglia spingono relazioni in un linguaggio oggetto.

In C API più di database tendono ad esporre i set di risultati come array multidimensionali, piuttosto che come strutture. Di conseguenza, uno è sufficiente accedere ai dati nello stesso formato come esiste nella tabella (s) nel database - è irrilevante che ora esiste come una copia locale dei dati, piuttosto che "nel database"

La maggior parte delle librerie di RDBMS funzionali espongono righe del database come tipi di record, che corrispondono ad un livello ragionevolmente profondo per righe del database quasi perfettamente. Non c'è un "disadattamento di impedenza" in questa situazione.

Il Wikipedia articolo sull'argomento sembra speculare ad alcune delle ragioni per le quali il paradigma oggetto è particolarmente suscettibile a questa discrepanza.

La mia convinzione è che dipende essenzialmente dal fatto che si sta sempre costruendo una rappresentazione secondaria dei dati (cioè sovrapposizione "oggetti"). Nella maggior parte imperativa o (non-oggetto) linguaggi funzionali, si è meno propensi a costruire una grande rappresentazione secondaria tale, semanticamente irrilevante dei dati. Se uno sta per costruire una rappresentazione secondaria in quel mondo, è più probabile che sia un astrazione di qualche tipo. Ciò corrisponde a un (infondate) convinzione di fondo della miniera che il paradigma OOP è fondamentalmente il martello proverbiale che rende ogni aspetto problema come un chiodo.

Answer 3

I principali problemi in ORM non sono per gestire le funzioni semplici, come la mappatura la colonna "x" al campo struct "x". Questo può essere fatto da diversi trucchi (macro, codice di generazione, di riflessione, e così via).

Il problema è come gestire OOP caratteristiche come eredità, composizione, riferimenti, oggetto unicità, interfacce, ecc ereditarietà è una cagna in questo senso, fin dalla sua attuazione naif come diverse tabelle non è ottimale.

Answer 4

Hai 2 mismatch di impedenza.

1. Registra su oggetti.
2. Il tuo linguaggio di query SQL.

Mentre la prima non corrispondente impedenza potrebbe non funzionare per tutte le lingue non-OOP il secondo è appearant in tutte le lingue e potrebbe essere risolto utilizzando DSL come si vede qui