I'm new to ASP.NET Core, and fairly new to web development in general. This leaves me a bit unfamiliar with web concepts, and best practices, hence this question:
I am working on a program where some models will be stored in a database. The models have a variety of data, much of which may be needed by any particular user. The model could be seen as:
Class P holds one Class U, one or more class B, zero or more class S, zero or more class N and maybe something else. In a desktop environment handling the same thing, I would load Class P such that all the members of P are available and accessible via P. In the web environment, there could be multiple users, and each will have zero or more P associated with them. When the user first logs in, they will see the set of P that are associated with them, but more importantly, they will see a name describing P, which is made up of the U, B, S, N, and other elements that are members of P.
It would be entirely possible for the user upon login to get the set of P that they have, then when they want to see/edit one of the P that they have, they could submit the ID for that P, and that P would be loaded up for them, but while stateless, this seems horribly inefficient. Every time they go to a certain page, the server would be acting like they had never been there before, and get all the P for them from the database.
What I'd prefer to do is to have a PM class that holds all the P objects for each user, and have that PM class persist for as long as that user is still working with the site. I could also have a UM class (User Manager) that would be essentially a dictionary of PM by User. This may be a bad idea, though, because that object could persist on the server for the life of the running application. It would be efficient from a memory standpoint, as there would be no need to load the PM for the user if it was already in the dictionary, but it would be sitting there in memory even when the site was not being used by anybody (the total number of users is likely less than 100, and they would likely use the site for brief bursts roughly once per year).
If I were to persist that UM dictionary object, it looks like I could use the Cache, but am I right in thinking that would be bad form?
If I just persist the PM class, that could exist for as long as the user kept coming back to the site. It looks like SessionState would be appropriate for this, with the understanding that the SessionState could be dispensed with by the server, so I would have to write code to make sure that the PM stored in the SessionState existed, and reload the PM if it had gone away.
Does that sound right, and if not, what should I be doing?
I am working on a program where some models will be stored in a database. The models have a variety of data, much of which may be needed by any particular user. The model could be seen as:
Class P holds one Class U, one or more class B, zero or more class S, zero or more class N and maybe something else. In a desktop environment handling the same thing, I would load Class P such that all the members of P are available and accessible via P. In the web environment, there could be multiple users, and each will have zero or more P associated with them. When the user first logs in, they will see the set of P that are associated with them, but more importantly, they will see a name describing P, which is made up of the U, B, S, N, and other elements that are members of P.
It would be entirely possible for the user upon login to get the set of P that they have, then when they want to see/edit one of the P that they have, they could submit the ID for that P, and that P would be loaded up for them, but while stateless, this seems horribly inefficient. Every time they go to a certain page, the server would be acting like they had never been there before, and get all the P for them from the database.
What I'd prefer to do is to have a PM class that holds all the P objects for each user, and have that PM class persist for as long as that user is still working with the site. I could also have a UM class (User Manager) that would be essentially a dictionary of PM by User. This may be a bad idea, though, because that object could persist on the server for the life of the running application. It would be efficient from a memory standpoint, as there would be no need to load the PM for the user if it was already in the dictionary, but it would be sitting there in memory even when the site was not being used by anybody (the total number of users is likely less than 100, and they would likely use the site for brief bursts roughly once per year).
If I were to persist that UM dictionary object, it looks like I could use the Cache, but am I right in thinking that would be bad form?
If I just persist the PM class, that could exist for as long as the user kept coming back to the site. It looks like SessionState would be appropriate for this, with the understanding that the SessionState could be dispensed with by the server, so I would have to write code to make sure that the PM stored in the SessionState existed, and reload the PM if it had gone away.
Does that sound right, and if not, what should I be doing?