What are good ways to store large number of objects, that will be modified/searched, persistently?

Question

so I'm writing some sort of banking software in C# for the sake of learning. I have different classes like

class Client {
    int userID;
    string firstName;
    string lastName;
    string description;
    DateTime birthdate;
    string type;
    ....
}

class Account {
    int accountID;
    int userID;
    string type;
    DateTime runtime;
    DateTime opened;
    string description;
    ....
}

Now I want to show all the different data in a graphical interface (WinForms), DataGridView is the right option here I think, and build forms so that the user can add new Clients and Accounts aswell as modify or delete them.

My problem is that I'm unsure how I should save my objects and their data, so it's still available after exiting and relaunching the program, without losing the ability to work with the data on an object-basis (like modify data with setter methods). It would be nice if it can be shipped easily without setting up a whole lot of stuff, so I can send my application to someone for code reviewing. Kinda like you can setup a local database in Visual Studio

Maybe I have just confused myself and I'm thinking in the wrong direction, just let me know. Thanks for your help.

Database is a good option for storage, but better than thinking about database is think about using a Data Access Layer. — Reza Aghaei, May 19 '16 at 16:51

score 3 · Answer 1 · edited May 23 '17 at 12:08

3

Sqlite is a good option for a database within a desktop application. The whole database is a single file on the hard drive, and the database engine is running inside your application, so you don't have to install any software to run.

In this question you can find the available .net libraries for sqlite.

edited May 23 '17 at 12:08

Community

1
1

answered May 19 '16 at 13:15

filhit

2,084
1
21
34

Reza Aghaei · Answer 2 · 2016-05-19T17:11:30.593

3

Database is a good option for storage, but better than thinking about database is think about using a Data Access Layer.

If you use a Data Access Layer and put codes related to data in the layer, then if you changed the technology of data store, your application will not change and all changes will be made in Data Access Layer.

You can simply have an implementation of Data Access Layer which work with SQL Server, Oracle, Sqlite or even Xml files. But your application will not be dependent to implementation.

As a side note for implementation of Data Access Layer, a good choice is SQL Express or SQL Local DB and using Entity Framework to map objects to database tables and performing CRUD operations.

You will find Repository, Unit of Work, Dependency Injection concepts useful. In general, you should use interfaces for data access and provide an implementation using for example EF, and then inject the implementation in your application.

edited May 19 '16 at 17:11

answered May 19 '16 at 16:50

Reza Aghaei

120,393
18
203
398

Good point! I'm currently having a look at the Entity Framework and so far it looks promising. Can you recommend some good "tutorial" or guildelines for creating a data access layer? – 0x1234 May 19 '16 at 17:00
There are a lot of good resources about Entity Framework. For example you can take a look at [Implementing the Repository and Unit of Work Patterns](http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application), the implementation id done for ASP.Net but is completely applicable in Windows Form also. – Reza Aghaei May 19 '16 at 17:06
Also as another good resource take a look at [Entity Framework Databinding with WinForms](https://msdn.microsoft.com/en-us/data/jj682076.aspx) – Reza Aghaei May 19 '16 at 17:09
Also take a look at [Entity Framework (EF) Documentation](https://msdn.microsoft.com/en-us/data/ee712907) page and you will find topics at the page useful. – Reza Aghaei May 19 '16 at 17:16
This is what taught me the Repository pattern with EF...great video! https://www.youtube.com/watch?v=rtXpYpZdOzM – Matthew Layton May 19 '16 at 20:27
Good job :) Also read the article of ASP.NET site about Repository and Unit of Work pattern using EF which I shared in comments. – Reza Aghaei May 19 '16 at 20:29
Thanks a bunch! Is it possible to display two types of objects, which have the same base class (in my case it's `Staff.cs` and `Client.cs`, which are derived from the abstract class `User.cs`) in a datagridview? I don't know if this a good approach, but to me it seems it would be annoying if you had to switch between two datagridviews or select between the classes via combobox all the time. – 0x1234 May 20 '16 at 17:24
You are welcome :) Yes, it's possible and it's not a bad approach, but you should consider: **-** Show a shared subset of fields in the grid. **-** If you have a toolbar, you should show suitable buttons on toolbar based on selected row type. **-** Also when showing data in grid, you may find [this post](http://stackoverflow.com/questions/36756694/adding-derived-classes-to-a-binding-source-of-a-datagridview) helpful. – Reza Aghaei May 20 '16 at 19:10

Matthew Layton · Accepted Answer · 2016-05-19T13:34:05.643

Entity Framework is a better option, in my opinion. It provides a fully featured persistence layer for Windows applications

https://msdn.microsoft.com/en-gb/data/ef.aspx

Side Note

EF is currently at version 6.1+ at the moment, so it's a mature product, and Microsoft's recommendation for creating persistence layers in new Windows applications. Entity Framework Core (which will supercede 6.1+) is RC2 at the moment, so before long, EF will be available for use with Linux and MAC systems too.

How To Install

Right click on your project, click "Manage NuGet Packages..." and then type "Entity Framework" into the search bar. Install it, and hey-presto, your app is (almost) ready for use with an Entity Framework persistence layer.

Example Code

public class Client {
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Description { get; set; }
    public DateTime Birthday { get; set; }
    public string Type { get; set; }
    ...
}

public class Account {
    public int Id { get; set; }
    public Client Client { get; set; }
    public string Type { get; set; }
    public DateTime RunTime { get; set; }
    public DateTime Opened { get; set; }
    public string Description { get; set; }
    ...
}

public class ApplicationDbContext : DbContext
{
    public ApplicationDbContext() : base("name=DefaultConnection")
    {
    }

    public DbSet<Account> Accounts { get; set; }
    public DbSet<Client> Clients { get; set; }
}

score 1 · Answer 4 · answered May 19 '16 at 13:30

Choices that come to mind:

1) Use serialization (XMl, Binary, Protobuf, JSON, etc.) and serialize your classes into files and then deserialize them when you need them. Advantage is that it's extremely easy to use, doesn't require third party software and is built-in to the language or a third party DLL (i.e. no other installation will be required). Disadvantage: it's file based, so you won't have many of the other benefits databases give you.

2) Use RDBMS or NoSQL databases. They're cumbersome to setup (and may be impossible in certain circumstances or undesired since your client will have to install various things other than your core application) and may be an overkill but obviously it's a lot more flexible than a file bases solution.

Since you're learning and doing this for fun, I suggest looking at both :).

What are good ways to store large number of objects, that will be modified/searched, persistently?

4 Answers4