Search code examples
c#.netdatabasegraph

Need suggestions on a C# desktop application architecture


I am making an application. This application would perhaps require (or not require) a database.

I have a finite number of categories, like Apples, Bananas, Oranges etc etc.

Each of these categories have sub-categories. like 1kg, 2 kg, 3 kg etc etc

Each of these su-categories have a sub-sub-category of market, like town 1, town 2, village 1, village 2.

Each of these sub-sub-categories have a sub-sub-sub-category, say 1 dollar, 2 dollar, 3 dollar.

Say if I use a few comboboxes, in the first I choose Bananas, in the second I chose 2 Kg, in the third I chose first villages then towns, the application should know that the fourth category is 2 dollars for villages and 3 dollars for town and plot me a graph where on x ahis it plots villages and towns and on Y axis it plots price for bananas 2kg.

Question is how do I do it? Do I need a multilayered database or is there a simpler way of doing it?

Just started working on it. Need some pointers.


Solution

  • Do I need a multilayered database or is there a simpler way of doing it?

    Start by figuring out your object model. Fruits, towns, prices etc, and how these relate to each other. Sketching on paper, writing UML diagrams or just creating classes might be useful.

    Once you have an idea of your types you can start figuring out how to store the data. The simplest option is usually to just serialize your objects to a file using Json or similar, and read the file when starting your program. See for example how to: json

    A database has some advantages:

    1. You can efficiently query the database without loading everything into memory
    2. It can be more reliable in case of power failure etc
    3. It can allow for concurrent usage
    4. scales to very large amounts of data

    etc, etc. But using a database adds complexity, and if you do not need the advantages its probably a good approach to stick with a simpler solution until such a time you actually need a real database. A good rule of thumb is "do not build it until you are sure you will need it". There are also many types of databases, each with separate advantages and disadvantages, and creating a good database design is a somewhat complex topic, that is out of scope for this question.