SQL Server State for large asp.net application and any advantages of writing own Custom Store Provider

问题

Background

We have a large asp.net application and uses a lot of sessions like datasets, datatables etc. We want to support web farms for this application, so we want to save the session state in sql server. I am successfully storing all the required data into the sql sever and getting all the data fine as well. Our supported database is SQL Server 2005-Sql Server 2008. We have to store datatables and datasets in sessions, even we know it is going to be bit expensive.

Question

1. I want to know from other developers is there any advantage of using Custom Store Provider to store data. (any help in debugging or error finding or future proofing etc.)
2. Or i just change the web config and make all the classes serializable to make it work.
3. Any custom way to make all the related classes serializable using c# code.
4. Any better way to intervene the process used by .net to store data in sql server (default process on changing web config)and make it better, by changing one or more classes.

Thanks,

回答1:

I would go with marking your business objects as [Serializable]. I think it should be a lot leaner than storing datatables/datasets.

The best way to make your classes serializable is to simply decorate them with [Serializable] I don't think you need anything else besides that.

If you use a load balancer with sticky sessions, I would actually go with LocalStateServer as it should perform faster than SqlServer

回答2:

I think you can go for your point 2.

there is no magic/automated way to change all your classes to be serializable, either you use the attribute way or the interface way but in some classes you could need some fixes or changes depending on what are the property types.

apart from that everything should work smoothly once everything is Serializable and yes, you touch the web.config and all should work.

if some of those objects are non user specific but can be shared among users, a possible alternative could be appFabric, if you configure a cache cluster (which could consist in multiple machines), you can then save objects in that cache, but as I said before this depends on your application, are those objects absolutely user specific so MUST be in the session and not in a shared cache? have a look at this answer: AppFabric vs System.Runtime.Caching

来源：https://stackoverflow.com/questions/7904617/sql-server-state-for-large-asp-net-application-and-any-advantages-of-writing-own