My question here this, for the purpose of convenience and ease of maintenance, is it worth to follow ORM pattern and ignore the performance trade off?
Dipende, principalmente dalle seguenti cose:
-
la tua applicazione soffre di problemi di prestazioni misurabili?
-
il tuo ORM fornisce ulteriori funzioni di ottimizzazione?
-
utilizzi l'ORM solo per evitare la necessità di scrivere SQL manualmente o lo usi per disaccoppiare l'applicazione dal fornitore DB specifico (ed è il dialetto SQL)?
Nel caso in cui la risposta a "1." è "no", smetti di pensarci sopra e resta fedele al tuo ORM. L'ottimizzazione "just in case" porta alla sovrastruttura ed è nota come "ottimizzazione prematura".
Se la risposta a "1" è sì, "2" dovrebbe valere sempre la pena di essere controllato, assicurati di aver compreso bene le capacità del tuo ORM e provato ciò che è possibile. Prova googling per "ottimizzazione delle prestazioni" e otterrai un sacco di risultati per ogni ORM popolare.
Se "2" non aiuta, e l'accoppiamento con uno specifico dialetto SQL non è un grosso problema per te, almeno non in alcune aree del codice limitate, quindi vai avanti e scrivi le tue query manualmente dove ti aiuta raggiungere i requisiti di prestazione.
Per essere onesti, la tecnologia ORM è ancora oggetto di dibattiti controversi se è davvero utile o se è un modello anti. Troverai molti articoli nel Web o post su Stackoverflow (come questo bambino di 9 anni ) discutendo i vantaggi e gli svantaggi degli ORM rispetto alla "programmazione nativa di SQL". Molti degli argomenti contro gli ORM sono basati sulle osservazioni che hai già fatto, che è spesso più facile ottimizzare le query manualmente che configurare un ORM per produrre query ottimizzate.