Hi everyone,

I finally purchased the newer version, 2.0 of LLBLGen, which I love. I have a few questions.

I'm building an asp.net app that currently works kind of like this.

User can log in and create items such as a recipe, he can then edit the recipe which has multiple food items,

so recipe (one to many) on foods

My problem is I store the collections of food and the recipe entity in session, so they can edit the obect to they're blue in the face, until they hit save, I then read in all my entities and collections from the session and save them to the database.

I was wondering if there is a better way to do this, since the only way I've ever built an asp.net app is putting objects into session as I zip from page to page editing the data in session. I don't think this will be a problem until I get about 500 users on the server editing their recipes, then memory will be eaten alive. Can someone please help a fellow coder out? Thanks!

does a user have to: 1. travel from page to page to complete the process, or 2. are all the process steps contained within 1 page?

I see 5 options for this situation. 2 of which i wouldn't consider a good choice 1. viewstate. requires scenario 2. you don't have to maintain server state. if a user aborts the process you don't have to "clean up" after them.
timeouts aren't an issue. This does create a large page size

1. session. this really isn't an issue if your data is small. you will need to manage what goes into session. and how to remove unwanted data.

2. cache. not a good option for either scenario as cache is shared across all users

3. application. not a good option for either scenario as application is shared across all users

4. database create tables to temporaily store data. persist data to these "temp" tables. when "save" is clicked transfer data from these tables to "real" tables. this would also require you to "clean up" abondonded instances.

jmeckley wrote:

does a user have to: 1. travel from page to page to complete the process, or 2. are all the process steps contained within 1 page?

I see 5 options for this situation. 2 of which i wouldn't consider a good choice 1. viewstate. requires scenario 2. you don't have to maintain server state. if a user aborts the process you don't have to "clean up" after them.
timeouts aren't an issue. This does create a large page size

1. session. this really isn't an issue if your data is small. you will need to manage what goes into session. and how to remove unwanted data.

2. cache. not a good option for either scenario as cache is shared across all users

3. application. not a good option for either scenario as application is shared across all users

4. database create tables to temporaily store data. persist data to these "temp" tables. when "save" is clicked transfer data from these tables to "real" tables. this would also require you to "clean up" abondonded instances.

Thanks!

This is helpful, the data I'm pushing around isn't that large but will be used by a large number of users. The data is manipulated in many pages not just one. I think I will stick with the current way I'm doing it in sessions as you suggested in your second option. Thanks again for your help!

Hi,

you may also have a look at Units of work to keep the user changes until he saves. They're serializable so you can even persist them accross sessions.

One thing to note with UOW, they do not serialize clean objects (the object must be dirty). This is by design to optimize the graph.

if you want to display all data (changed and un-changed) store the graph in session. then when the user commits, pass dirty objects into the UOW and commit.

Well, I guess clean objects can be fetched directly from the dbase so they don't need additional persistence.

If you want to get down to it, you can still use session variables and have less of an impact on memory. Youre going to use less memory if you only put primitive types into memory. Primitive types (i.e. string, int, bool, etc.) consume less memory and serialize faster than reference types (XXXEntity, XXXEntityCollection).

You just need to write a class that will pull session variables and put them into entity and entity collection objects before the values are comitted to the DB.

If you are interested in learning more about session, here is a decent article. http://msdn.microsoft.com/msdnmag/issues/05/09/SessionState/default.aspx#S5

The good part is the section that talks about optimizing serialization.