Databases are easy to set up, and all of the major databases are either free or have a free version available. Therefore I would use an actual database in the demo environment. Advantages:

• Complete consistency with production environment (or at least very close).
• No need to write special handling for the different interface.
• Easy to generate sample data (some tables could be taken directly from production. If there is sensitive data in your production database, you could write a simple routine to anonymise it–replace with fake names and addresses, for example.)

If the size of your demo environment is not a big deal, I would even access the database via a local web server if that helps the environment stay similar to production. There are prebuilt packages (such as XAMPP, which includes Apache, MySQL, and other tools) that make this sort of thing easy. Setting up some extra programs is easy, while making changes to your original program is hard. Therefore, minimize the latter whenever possible.

If duplicating a production-like environment is too heavyweight for your demo purposes, you could use a lightweight database (such as SQLite), and still have an interface that is fairly similar.

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

The standard for seperating businesslogic from databaseaccess is to use the repository pattern .

Your app can have

• one implementation to access the real data for production and
• a 2nd implementation that reads the data from demo implementation and ignores the saveToDatabase calls.

I’m unsure what do you want to do here. Create a showcase of your application (1)? Test it in staging/development environment (2)? Unit test it (3)?

1. If you want to have a demo version of your application (for example in order to show to a potential customer what she gets, without actually letting the person to have an access to all the features and without polluting the production database), just duplicate the database. In most cases, the simple 1 to 1 duplication will work; if not, you may enhance the demo database with security restrictions which would make it impossible to change what should be changed only in production (for example the password of the demo user).

2. If your goal is to have a staging environment, the same technique of database duplication would be used. Here, you don’t change anything: you have to have an exact duplicate of the database schema. The development environment will be based on a copy of a database too, given that there, the database may contain developer-specific changes.

3. Finally, if you’re asking about unit testing, then mocking is generally used to make it easy to test the classes in a database-agnostic and data-agnostic way. Here, effectively, the database (and the data access layer in general) would be substituted with a mock which will provide specific answers to specific requests, like:

   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();
       }
   }