locked
Best place to store across Layers RRS feed

  • Question

  • Hi,

    In a layered ASP.NET application, with Entity/Collection, DAL, BLL, Service Facade, UI, I would like to know what is the best place to store information. This information could be either a primitive type such as a string, or a complex type such as Collection.

    We use Oracle 10g as DB and two servers for Load balancing.

    I'm unable to come to conclusion on giving a generic solution on when to use what, among the four options below:

    1. Sessions:
    FYI, we use Out-of-proc mode to store Session objects in the DB.

    2. Cache:
    We have two servers for load balancing and storing in Cache would mean replication of data.

    3. Profile:
    Again the same case as Profile objects need to be stored in DB. Also, I'm not sure how far these are supported for Oracle, as I couldn't find built in implementation for the same.

    4. ViewState:
    This could not be used across pages, and again these I guess are not reliable for large collection objects, as they may get corrupted.

    Please let me know which would be the best option to use.

    Thanks.

    Monday, February 27, 2006 7:00 AM

Answers

  • Arnon gives some good advice in choosing the best tool for the job.

    I might go one step further and make such things declarable by providing a generic storage contract. You could then allow for runtime configuring of such things, this could be invaluable as I am quite sure you will find real world use cases that differ greatly from your white board cases. By providing this abstract contract for persisting data you would also allow for future transparent expansion to other methodologies such as the whiz bang magical shared cache with no network overhead :D.

    as for

    "You can use cache for data that is immutable or changes in very low frequency"

    I would think this data would actually have to be immutable given your situation; if the data changes you could end up with a situation of trying to keep the servers in synch. Depending on the level of sophistication you are trying to achieve, this can be quite difficult.

     

    If scalability is your overall goal... I have in the past created a system for this which was quite successful but it is also a good amount of work. It was essentially an extension of the cache concept that automatically replicated to all nodes. If you are interested in this I can explain further the implementational details but I warn you it is a good deal of work. http://www.eggheadcafe.com/articles/20030420.asp includes a simple example of this methodology, but you can go alot further with it.

    Let me check some legalese on the code I had written, I may be able to post it; if not sounds like I have some "re-implementing" to do as this would make a nice little article :D

    Cheers,

    Greg

    Tuesday, February 28, 2006 7:51 AM

All replies

  • I don't think there is a generic solution that fits all circumstances for example:

    • You can use cache for data that is immutable or changes in very low frequency
    • You can use profiles for data that should be kept per user and cross sessions
    • You can use session object for things that are per user and should last, well.. , for the session
    • You can use ViewState for few flags etc. that are needed for a certain page (remember that they round-trip to the client and back)

    You may want//need to choose more than one solution according to you needs

    Arnon

     

    Monday, February 27, 2006 8:39 AM
  • Arnon gives some good advice in choosing the best tool for the job.

    I might go one step further and make such things declarable by providing a generic storage contract. You could then allow for runtime configuring of such things, this could be invaluable as I am quite sure you will find real world use cases that differ greatly from your white board cases. By providing this abstract contract for persisting data you would also allow for future transparent expansion to other methodologies such as the whiz bang magical shared cache with no network overhead :D.

    as for

    "You can use cache for data that is immutable or changes in very low frequency"

    I would think this data would actually have to be immutable given your situation; if the data changes you could end up with a situation of trying to keep the servers in synch. Depending on the level of sophistication you are trying to achieve, this can be quite difficult.

     

    If scalability is your overall goal... I have in the past created a system for this which was quite successful but it is also a good amount of work. It was essentially an extension of the cache concept that automatically replicated to all nodes. If you are interested in this I can explain further the implementational details but I warn you it is a good deal of work. http://www.eggheadcafe.com/articles/20030420.asp includes a simple example of this methodology, but you can go alot further with it.

    Let me check some legalese on the code I had written, I may be able to post it; if not sounds like I have some "re-implementing" to do as this would make a nice little article :D

    Cheers,

    Greg

    Tuesday, February 28, 2006 7:51 AM
  •  Greg Young wrote:

    as for

    "You can use cache for data that is immutable or changes in very low frequency"

    I would think this data would actually have to be immutable given your situation; if the data changes you could end up with a situation of trying to keep the servers in synch. Depending on the level of sophistication you are trying to achieve, this can be quite difficult.

     

    Immutable data is always better - since it, well, er, doesn't change. Data that changes complicates matters a lot - However there are certain cases where data is quasi-immutable for example data that changes in a timely manner and thus can be synchronized (e.g. something that changes once a day/month - like price updates) data that changes in an orderly manner and can be pushed to the caches in synchronized manner (e.g. adding an item to a product catalog)

    Arnon

     

    Tuesday, February 28, 2006 9:52 PM
  • Arnon: see the link included, it is a simplified method to do just this.

    Cheers,

    Greg

    Tuesday, February 28, 2006 10:10 PM
  • As others have mentioned, there is no ideal pattern that works in all scenarios. Each storage mechanism you've mentioned has it's advantages and disadvantages, and it is likely the best design will use more than one of those mechanisms. Lots of factors come into play - the data that's being stored, how much of it , how static it is, the physical deployment model of the application, etc....

    I'd reccomend taking a look at "Real World ASP.NET Best Practices" (ISBN: 1590591003) by Farhan Muhamad and Matt Milner. It's an excellent examination of some of the tradeoffs involved. It's a pretty quick read and includes comparative perf. analysis for different techniques it discusses. The book is a few years old, but still relevant

    Regards,

    DotnetScott

    Wednesday, March 1, 2006 3:46 PM