Il modo in cui comprendo le lingue specifiche di Fluent Domain Sono in grado di utilizzare il concatenamento di metodi per avere una conversazione con il codice. Ad esempio, se il requisito aziendale è chiamare il database per "Ottenere tutti i clienti con account InActive", potrei usare:
Customers().WithInActiveAccount()
I clienti hanno milioni di righe. Portare tutti i clienti in memoria non è efficiente quando ho bisogno solo di un sottoinsieme di clienti (e forse nemmeno dei limiti di memoria dati possibili). Sospetto che gli ORM risolvano questo problema trattando il codice come dati, caricando lentamente e creando una query completa basata sull'intera espressione. Quindi la query finale potrebbe essere
SELECT * CUSTOMERS WHERE InActive = true
IME, quando si tratta di tabelle altamente normalizzate, ORM produce query DB inefficienti. Rolling ancora un altro ORM personalizzato per risolvere un problema simile sembra una marcia della morte in attesa di accadere. E le stored procedure scritte da un professionista DB saranno efficienti.
In questo semplice caso posso semplicemente cambiare i clienti in un oggetto:
Customers.WithInactiveAccount()
Che cosa succede se devo fare qualcosa di più complesso?
Customers.WithInactiveAccount().BornAfter(October 1, 1990)
Come faccio a creare query in modo efficiente mentre costruisco espressioni più avanzate potenzialmente disegnate in altre entità? Questa è una domanda, sono sicuro che ogni ORM si chiede proprio nelle prime fasi di sviluppo. Devo limitarmi a "domande stupide" per mantenere le prestazioni? Se questa è una tecnica che esiste?
Questi sono i tipi di domande che mi vengono a trovare da sviluppatori come me che hanno sperimentato problemi di prestazioni a livello di scheda con gli ORM nel mondo dei big data.
Quindi, quando si tratta di questi tipi di database normalizzati, una DSL fluente è un'opzione pratica? (Suppongo che un DSL fluente per l'accesso ai DB richieda un ORM sottostante per funzionare)