Configuration Repository for Multiuser Application (Best Approach).
I am seeking some design guidance, so I don't wonder down the wrong road or reinvent the wheel.
I'm working on an application (using Visual Studio 2015 - C#) where multiple users will be able to log in to their user account and receive individualized training.
Each user will be presented with a list of lessons choices - lets assume Lesson 1 - Lesson 10. They'll have the ability to choose which lessons they need to take in order to learn how to build a "Widget."
So, User1 checks off lessons (1, 3, 4, 6, 8, 9 and 10). User2 checks off lessons (2, 4, 6 and 8) and User3 chooses to take all the lessons, because he has no prior knowledge of who Widgets are built. -- They then all begin to take their training, but stop at some point prior to completion (they will resume training at a later date).
So, my question is - what is the best way to preserve the choices of:
1). Which lessons they've chosen to take,
2). Their progress.
3). Their scores on any quizzes.
What I want to do is have a mechanism, where, when User2 logs back in she knows she had selected lessons (2, 4, 6 and 8) AND that she had only completed lesson 2 and is halfway through lesson 4, with 6 and 8 remaining.
I assume I can put their choices and progress back into the SQL Lite databases, where their User data (name, ID and Password, etc.) resides, but is there a better configuration approach for such a situation?
Also, if I use the SQL approach (or for that matter any approach), what vehicle would you use to keep the User's profile in memory, while the user is logged into the application? Or would you make a call-back to the SQL Lite DB to get the data each time you need something?
Again, your experience and design guidance is what I'm seeking - and as always, your advice is highly regarded.
Best Regards,
Fulano
I'm working on an application (using Visual Studio 2015 - C#) where multiple users will be able to log in to their user account and receive individualized training.
Each user will be presented with a list of lessons choices - lets assume Lesson 1 - Lesson 10. They'll have the ability to choose which lessons they need to take in order to learn how to build a "Widget."
So, User1 checks off lessons (1, 3, 4, 6, 8, 9 and 10). User2 checks off lessons (2, 4, 6 and 8) and User3 chooses to take all the lessons, because he has no prior knowledge of who Widgets are built. -- They then all begin to take their training, but stop at some point prior to completion (they will resume training at a later date).
So, my question is - what is the best way to preserve the choices of:
1). Which lessons they've chosen to take,
2). Their progress.
3). Their scores on any quizzes.
What I want to do is have a mechanism, where, when User2 logs back in she knows she had selected lessons (2, 4, 6 and 8) AND that she had only completed lesson 2 and is halfway through lesson 4, with 6 and 8 remaining.
I assume I can put their choices and progress back into the SQL Lite databases, where their User data (name, ID and Password, etc.) resides, but is there a better configuration approach for such a situation?
Also, if I use the SQL approach (or for that matter any approach), what vehicle would you use to keep the User's profile in memory, while the user is logged into the application? Or would you make a call-back to the SQL Lite DB to get the data each time you need something?
Again, your experience and design guidance is what I'm seeking - and as always, your advice is highly regarded.
Best Regards,
Fulano
David Johnson, CD
you can save and load settings from the users appdata folder
ASKER
Hi David, do you have a simple example of that approach?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
David, I had left this question open in hopes that I might get other suggestions. Although your suggestion is a good one, I was hoping there would be others....it doesn't seem there were, so I'll close it and grant you the points.
Thanks,
Fulano
Thanks,
Fulano
ASKER
Thanks