Sposare aggregati definiti dal consumatore (ad es. Conteggi SQL) con oggetti modello "puri"?

Question

Qual è la migliore pratica per introdurre dati personalizzati (tipicamente volatili) nelle classi del modello di entità? Questo può sembrare una cattiva pratica prima, ma sembra essere uno scenario abbastanza comune. Nella nostra recente applicazione Web abbiamo sviluppato un modello adeguato e nella maggior parte dei casi stiamo bene caricando le entità del modello. Ma ci sono casi in cui non possiamo permetterci di caricare un'intera gerarchia di entità; dobbiamo caricare, per esempio, i risultati di un paio di SQL COUNT o eventualmente di alcune informazioni aggiuntive a fianco (o incorporate all'interno) delle entità del modello. Quindi sostanzialmente, i requisiti e le condizioni sono:

1. È un'applicazione web in cui il 99.9999999999% di tutte le operazioni sono operazioni di lettura.

2. Non hanno bisogno di elaborare o fare complicate logiche aziendali. Dobbiamo solo trasferire rapidamente i dati in HTML.

3. In diversi casi critici per le prestazioni, dobbiamo caricare i risultati degli aggregati SQL che non si adattano a nessuna proprietà del modello.

4. Abbiamo bisogno di un modo estensibile per introdurre nuovi dati personalizzati, se necessario.

Come risolvi normalmente questo problema senza lavorare troppo sul tuo ORM (ad esempio i dati grezzi da db)? Sono sicuro che questo è stato discusso molte volte, ma non riesco a capire una buona query di Google per trovare qualcosa di utile.

Modifica : poiché in seguito ho capito che la domanda non era molto ben formata, ho deciso di riformularla e iniziare un nuovo .

Answer 1

Se stai semplicemente ottenendo dati relazionali da e verso un browser, con un comportamento scarso o nullo nel mezzo, sembra che tu stia cercando di risolvere un problema relazionale con un paradigma OO.

Potrei essere propenso a rinunciare del tutto all'approccio orientato agli oggetti.

Il mio team ha recentemente riscritto un'applicazione chiedendo " Qual è la cosa più semplice che può funzionare? " e " Qual è la lingua più vicina al problema? " ;. La nostra nuova app, in sostituzione di una OO, è risultata essere 10 volte più piccola, più veloce e più economica.

Abbiamo usato SQL, stored procedure, librerie XML sul server DB, XSLT (per ottenere l'HTML) e javascript.

Answer 2

Il purista OOP come me andrebbe al modello Decoratore. http://en.wikipedia.org/wiki/Decorator_pattern

Ma il fatto è che alcune persone potrebbero non aver bisogno della flessibilità che offre. Inoltre, la creazione di nuove classi per ogni operazione distinta può sembrare eccessiva, ma fornisce un buon controllo del tipo di compilazione.

Answer 3

La migliore pratica a mio avviso è che l'applicazione utilizza i dati utilizzando il modello Modello di dominio . Il modello di dominio può offrire metodi di logica aziendale per eseguire il tipo di query che ha senso e sono pertinenti alle esigenze dell'applicazione.

Questi possono recuperare " live " risultati che mappano direttamente alle righe del database e possono quindi essere modificati e "salvati".

Ma in aggiunta, il modello di dominio può fornire metodi che recuperano risultati di sola lettura che sono troppo complessi per essere facilmente salvati nel database. Ciò include il tuo esempio di risultati di query aggregati raggruppati e include anche set di risultati di query uniti, espressioni come colonne, ecc.

Il modello del modello di dominio offre un modo per separare la progettazione OO di un'applicazione dalla progettazione del database fisico.