Miglior soluzione per programmazione orientata ad oggetti con XML

[hypertextPro]

Buona sera a tutti, premetto che non mi trovo davanti ad una problematica vera e propria ma mi piacerebbe poter scambiare opinioni con qualcuno che parla la mia stessa lingua.

La mia questione è questa:

Considerando la OOP, le tabelle temporanee e i file XML. Secondo me la miglior soluzione per un programmazione sicura ed efficiente sarebbe quella di utilizzare un file XML (ovviamente legato all'utente, alla sessione e a tutto quello che voglio) come livello intermedio tra il livello operativo e il livello dati.

La mia idee sarebbe, ad esempio, quella di utilizzare un file XML per registrare le azioni o le operazioni di un determinato utente. Successivamente, dopo aver analizzato i dati estratti dall'XML, passarli direttamente al livello dati.

Cosa ne pensate? Secondo voi potrebbe essere un buon metodo?

[Santino83_02]

Se non contestualizzi la cosa oltra al "NO" non vado. La persistenza dei dati/azioni dell'utente è affidata allo strato di persistenza, e nella totalità praticamente dei casi questo è un database: salvare prima la persistenza su filesystem e poi nel db è una cosa inutile, lenta, e concettualmente errata, a meno di esigenze particolari

[hypertextPro]

Non guadagno nulla in termini di sicurezza?

[Santino83_02]

non guadagni nulla in nessun campo, anzi peggiori ovunque la situazione...lascia perdere questa idea

[hypertextPro]

Mi farebbe anche piacere capire, secondo te, il perchè.
Come ho anticipato è solo una discussione aperta per il solo scopo di confronto. Se ti limiti a dirmi non guadagni nulla in nessun campo non capisco bene il perchè di questo tuo ragionamento.

[Santino83_02]

Allora ricapitoliamo:

L'utente fà un'azione sulla tua applicazione che presuppone una persistenza di dati a quanto dici, giusto? La tua riflessione è: "invece di usare la persistenza per mappare i miei oggetti in relative righe/documenti di persistenza, preferisco salvare la rappresentazione di questi oggetti in XML su filesystem e successivamente avere un sistema che prende questi xml, se li parsa, ricrea oggetti, e salva i dati di questi oggetti nel database". Dal punto di vista della sicurezza, cambia poco o niente, perchè a meno che tu non salvi gli xml in una cartella pubblica, un attaccante dovrebbe aver accesso al filesystem del server per leggere i dati che salvi. Certo, se i dati fossero direttamente in un database, l'attaccante dovrebbe bucarti anche o solo il database per leggerli.. insomma, non mi sembra il punto centrale della questione.

Per la procedura in se, invece, non vedo alcun senso pratico o logico: non esistono problemi di affidabilità nell'operazione standard, di sicurezza, di pattern OO che possa portare all'idea di cui sopra. Se dividi l'applicazione in layer, da quello di presentazione a quello più in basso di persistenza, arriverà al fatto che le tue classi di dominio saranno utilizzate dalla persistenza per persistere lo stato di dominio in un determinato istante, senza dover uscire fuori dal "linguaggio di programmazione". Senza poi stare a parlare di quanto sia più complicato scrivere e leggere su file che su database (se utilizzi il file come un "database"), tale passaggio in più rende solo l'applicazione più lenta e a rischio di errori. Anche architetturalmente complichi la cosa:

mentre tradizionalmente te prendi l'oggetto e lo mandi all'entity manager per farlo persistere su db, nel caso dell'xml te prendi l'oggetto e lo serializzi in un file xml. A questo punto, devi schedulare (o hai un demone che gira ogni tot secondo) un job che vada a leggersi tutti gli xml generati in un lasso di tempo, leggerli uno per uno, convertire il dato serializzato in oggetto, chiamare l'entity manager e fargli persistere tale oggetto. L'handling di questi scenari, soprattutto in php, non è proprio banale e può incorrere a tutta una serie di problemi (timeout, troppi dati da elaborare tutti insieme, code di processamento dei dati, etc) che non hai nel caso tradizionale.

Quindi ripeto: se non c'è un motivo più che valido e obbligatorio per fare il passaggio intermedio, introdurre il passaggio intermedio porta solo a problemi, lungaggini, duplicazioni.

Questo se ho ben capito lo scenario che hai descritto te