Crea database demo offline Database sostitutivo [chiuso]

I database sono facili da configurare e tutti i principali database sono gratuiti o hanno una versione gratuita disponibile. Quindi userei un vero database nell'ambiente demo. Vantaggi:

• Completa coerenza con l'ambiente di produzione (o almeno molto vicino).
• Non è necessario scrivere una gestione speciale per la diversa interfaccia.
• Facile da generare dati di esempio (alcune tabelle possono essere prelevate direttamente dalla produzione Se nel database di produzione sono presenti dati sensibili, è possibile scrivere una semplice routine per renderla anonima, ad esempio sostituendo nomi e indirizzi falsi).

Se la dimensione del tuo ambiente demo non è un grosso problema, accedo anche al database tramite un server web locale se questo aiuta l'ambiente a rimanere simile alla produzione. Esistono pacchetti precompilati (come XAMPP , che include Apache, MySQL e altri strumenti) che rendono questo tipo di cosa facile Impostare alcuni programmi extra è facile, mentre apportare modifiche al programma originale è difficile. Pertanto, minimizza quest'ultimo quando possibile.

Se la duplicazione di un ambiente simile alla produzione è troppo pesante per i tuoi scopi dimostrativi, potresti usare un database leggero (come SQLite) e avere comunque un'interfaccia abbastanza simile.

I wanted to know if there is already a standard way of obtaining the same result.

Lo standard per la separazione di businesslogic da databaseaccess consiste nell'utilizzare il modello di repository .

La tua app può avere

• una implementazione per accedere ai dati reali per la produzione e
• una seconda implementazione che legge i dati dall'implementazione demo e ignora le chiamate saveToDatabase.

Non sono sicuro di cosa vuoi fare qui. Crea una vetrina della tua applicazione (1)? Provalo in ambiente di staging / sviluppo (2)? Unit test it (3)?

1. Se vuoi avere una versione demo della tua applicazione (ad esempio per mostrare a un potenziale cliente ciò che ottiene, senza in realtà lasciare che la persona abbia accesso a tutte le funzionalità e senza inquinare la produzione database), solo duplica il database . Nella maggior parte dei casi, la semplice duplicazione da 1 a 1 funzionerà; in caso contrario, è possibile migliorare il database demo con restrizioni di sicurezza che renderebbero impossibile modificare ciò che dovrebbe essere modificato solo nella produzione (ad esempio la password dell'utente demo).

2. Se il tuo obiettivo è avere un ambiente di staging, verrebbe utilizzata la stessa tecnica di duplicazione del database . Qui, non cambi nulla: tu hai per avere un duplicato esatto dello schema del database. Anche l'ambiente di sviluppo sarà basato su una copia di un database, dato che lì il database può contenere modifiche specifiche per lo sviluppatore.

3. Infine, se stai chiedendo dei test unitari, in genere viene utilizzato mocking per semplificare il test delle classi in modo indipendente da database e agganciato ai dati. Qui, efficacemente, il database (e il livello di accesso ai dati in generale) verrebbe sostituito da una simulazione che fornirà risposte specifiche a richieste specifiche, come:

   class SampleCustomerMock
   {
       Customer FindCustomerById(int id)
       {
           // Just return a sample customer, without taking in account the 'id'.
           return new Customer("John", "Miller", 36, Gender.Male);
       }
   }
   
   class MissingCustomerMock
   {
       Customer FindCustomerById(int id)
       {
           throw new RecordNotFound();
       }
   }