Ciao,
credo che naighes intendesse consigliarti di aggiungere un livello di astrazione tra l'applicazione client e il caricamento dei dati.
Effettivamente, in questo momento immagino che il client abbia una dipendenza da System.Xml se in uno dei metodi hai del codice tipo questo:
var xmldoc = new System.Xml.XmlDocument();
xmldoc.Load("file.xml");
Se è questo il caso, la classe XmlDocument è stata
cablata all'interno del metodo per vostra scelta, come dicevi in un precedente post:
laurar181 ha scritto:
Da studi effettuati non c'è un database che va bene per tutti e quindi abbiamo optato per questa soluzione.
Alla luce dei problemi riscontrati con l'xml, forse dovreste riconsiderare questa scelta e
disaccoppiare la logica di funzionamento del client dal metodo di persistenza, come suggeriva naighes.
Quindi, anziché lavorare direttamente con XmlDocument, potresti adoperare un'interfaccia molto semplice:
public interface IDataRepository{
IEnumerable<TuoTipo> GetData();
void SaveData(List<TuoTipo> data);
}
e poi scrivere delle implementazioni concrete per permettere all'applicazione di lavorare con varie tecnologie. Potresti quindi creare un SqliteDataRepository, XmlDataRepository, SqlCeRepository, e così via.
Riconosci le differenze tecnologiche che esistono tra le varie piattaforme e supportale nella tua applicazione affinché l'utente possa sperimentare il meglio che il suo dispositivo gli può offrire.
Ti assicuro che gli utenti apprezzeranno la conoscenza che avete maturato sulla sua piattaforma.
Invece, preferire l'XML (o altro sistema) perché è l'unico denominatore comune, vi semplificherà di certo lo sviluppo ma il tempo che risparmiate voi lo pagheranno poco per volta i tanti utenti che utilizzeranno l'applicazione.
Quindi, tornando in tema, usare un'interfaccia ti consente di astrarre il meccanismo di persistenza così che l'applicazione non saprà mai (ma neanche deve importargli) se sta lavorando con Sqlite, SqlCE o semplice XML.
Un livello di astrazione aggiunge complessità, è vero, ma esistono strumenti come uno
IoC container che azzerano - quasi - la difficoltà di sviluppo che ne deriva. In pratica funziona così:
- Il metodo della tua applicazione client NON userà più la parola chiave new per creare una nuova istanza, ma chiederà al container di dargli un'istanza di IDataRepository
- Il container, automaticamente, crea l'istanza di un tipo concreto che implementa IDataRepository e gliela fornisce. Ma quale tipo concreto va ad istanziare? SqliteDataRepository o SqlCeDataRepository o altro? Questo dipende da come hai configurato il container. Quando dovrai creare il package di installazione per Android, andrai nel file di configurazione della tua applicazione e imposterai che l'istanza da restituire per IDataRepository è SqliteDataRepository. Quando crei il package per Windows Phone la rimapperai su SqlCeDataRepository, e così via. Così, senza dover mettere mano al tuo codice ma solo apportando piccole modifiche al file di configurazione potrai "ottimizzare" l'applicazione per il dispositivo su cui vai ad installarla.
- Quando hai messo in piedi un sistema del genere ti si aprirà un mondo: gli scogli che prima ti ostacolavano lo sviluppo ora diventeranno discese da percorrere ben volentieri per offrire un software di miglior qualità all'utente
Questo è un po' di pseudo-codice per farti vedere come cambierebbe il metodo che si occupa di caricare i dati:
var repo = Container.Get<IDataRepository>();
var lista = repo.GetData();
foreach (var elemento in lista){
...
}
Ovviamente il metodo .GetData puoi personalizzartelo come vuoi, ad esempio per fargli supportare la ricerca e l'ordinamento.
ciao
Modificato da BrightSoul il 28 dicembre 2011 11.17 -
