Perché dovresti utilizzare un motore di report, se la tua applicazione è modellata su ORM

Question

Perché dovresti utilizzare un motore di report, se la tua applicazione è modellata su ORM

#1 da (1 voti)

2

Ad esempio, usi qualche framework MVC per la tua applicazione web e per la maggior parte del tempo stai pensando in modo molto orientato agli oggetti, ed è per questo che hai scelto di utilizzare un framework ORM in primo luogo.

Tuttavia, quando si tratta di report. Ad esempio, hai deciso di utilizzare strutture di reporting come BIRT. BIRT non conosce la mappatura relazionale dell'oggetto, conosce le tue tabelle e le query SQL non elaborate. Improvvisamente ti toglie tutta l'astrazione che hai messo in atto. Niente di male in questo, ma sembra piuttosto disconnesso (e nel 2005).

Quindi la domanda è: perché dovresti usare qualsiasi struttura di reporting quando puoi semplicemente usare qualsiasi schema di template (HTML5) là fuori per rendere il tuo report. Supponendo che non ti servano le funzionalità di esportazione multiformato di un framework di reporting.

Note: le prestazioni non sono un problema ... affatto

orm reporting

posta 40Plot 11.08.2015 - 13:30

fonte

1 risposta

Leggi altre domande sui tag orm reporting

Regex backtracking su pattern semplice Xamarin / Mono Conformità LGPL

score 1 · Accepted Answer

Lavorare con un framework si basa su trade-off: si perdono alcune capacità o flessibilità in un'area per ottenere un vantaggio che conta per voi. Ad esempio:

Gli strumenti di reporting possono offrire funzionalità di esportazione diverse immediatamente: puoi esportare qualsiasi rapporto in formato PDF o XLS o CSV o HTML o ...
Gli strumenti di reporting potrebbero offrire la pianificazione e la possibilità di eseguire automaticamente i rapporti in un determinato momento
Gli strumenti di reporting potrebbero offrire funzionalità di formattazione avanzate come l'ordinamento o il template
Gli strumenti di segnalazione potrebbero consentire di interrogare sistemi diversi e unire i dati attraverso questi sistemi, utilizzando tecnologie diverse (SQL vs XML vs JSON vs ...)

Non è che questo non possa essere fatto in un'applicazione di reporting HTML roll-on-own, è solo che questo richiede tempo e fatica. Dovresti chiederti se vuoi spendere tempo e fatica scrivendo i tuoi report quando ci sono framework che possono prendersene cura per te. Proprio come dovresti chiederti se vuoi dedicare tempo e fatica a scrivere SQL e mappare il tuo dominio al database o utilizzare un ORM.

C'è anche il fatto che c'è una grande differenza tra il tuo modello di oggetti e il modello di rapporto. Un modello a oggetti è molto diverso da un modello di report e il modo in cui scrivi il tuo modello a oggetti non necessariamente si adatta molto bene ai rapporti. A meno che non si progetta in modo specifico il modello di oggetto per gestire i report, è probabile che un report in cima a questo modello abbia problemi di SELECT N + 1. Le segnalazioni avvantaggiano molto dalle query che utilizzano JOINS e simili.

Infine, per le applicazioni di grosse dimensioni denormalizzazione di dati e cose come il data warehousing significa che si sta lavorando con una struttura di database che è stata progettata e ottimizzata per la segnalazione comunque. Non ha molto senso introdurre un modello in più perché SQL è molto bravo a leggere da questo tipo di archiviazione dei dati.