So che le trappole tecniche della scrittura di un ORM sono piuttosto conosciute al giorno d'oggi, ma quali sono alcuni fattori non tecnici (ad esempio, Scope) che rendono difficile la scrittura di un buon ORM?
Ho già letto i motivi tecnici per cui gli ORM sono così difficili da scrivere da questo post StackOverflow: link
Penso che il sfasamento dell'impedenza relazionale dell'oggetto sia il grosso problema. OO non è relazionale. Ad esempio, dove la teoria relazionale descrive l'ereditarietà. Anche più piccoli (ma grandi problemi) come se il linguaggio di programmazione non supportasse i tipi nullable. Come si fa a mapparlo su una colonna nullable nel database?
Il tempo e l'ambito sono fattori tecnici in quanto sono ortogonali alle risorse tempo / spazio e alla portata dell'output (scope) utilizzati da un particolare processo (in questo caso, scrivere un pezzo di software.)
Un motivo non tecnico potrebbe determinare i requisiti, l'elicitazione dei requisiti, la negoziazione dei clienti e così via. Sarebbe difficile misurare l'effetto di tali ragioni (o impedimenti) non tecnici allo sviluppo di qualcosa che è chiaramente inteso per l'utilizzo da parte dello staff tecnico.
Il più grande ostacolo alla creazione di un buon O / RM sta provando a costruire un O / RM. Crea la soluzione più semplice che risolva il problema in questione. Quindi, quando identificherai i problemi che la tua soluzione non affronta, espandi. Se decidi di creare un O / RM, l'ambito di questo problema ti impedirà di far funzionare anche una soluzione semplice.
Leggi altre domande sui tag architecture orm