1

I have created news website in MVC. I have search functionality on it.

When Index Action of Search Controller is called, it fetches records from database, it returns Search View. This Search View has AJAX Pager for paging, when Next or Previous button of Pager is clicked, AJAX request is made to Paging Action of Search Controller.

Now I don't want again to make call to my Database. I want to use results which were fetched during Index action of Search Controller.

For now I have used Session[""] object.

I want to know what is better to used for state management in this scenario.

Results fetched from database can be around 1000-5000, ArticleName, ArticleShortDescription (~200 characters)

AK47
  • 3,707
  • 3
  • 17
  • 36

3 Answers3

4

ViewBag or ViewData are only persistent in the current request. As such, they are not usable. TempData persists until the next request, but this could be anything, so there's no guarantee it persists long enough for you to make your Ajax call (or subsequent ajax calls).

Realistically, Session is your only decent option in this case, though it's still not optimal. You'll be storing a lot of information, which may not even be requested by the client. Even then, cleaning it up after it's no longer needed might prove hard as well.

Your best bet would be to make calls to the database which take paging into account, so you only ever return a subset of the data each request, rather than just pulling out all the data.

Kippie
  • 3,760
  • 3
  • 23
  • 38
  • Thanks for response, but I want to avoid making another call to database. Bringing only records of 1 page from database will prevent me from applying paging cause , records of only 1 page will be there, so no meaning of applying paging. – AK47 Oct 09 '14 at 08:32
  • Well, in that case you'd either have to use `Session` for user-specific data, or the `Application Cache` for global/public data, as mentioned by @fordio – Kippie Oct 09 '14 at 08:34
2

You should not use any of those. Session are created per user, if you are storing 1000 - 5000 articles for each user using your search, you are going to have a bad time. ViewData are fundamentally Session object with a nice wrappers, so it's also bad for your use case.

Let's say you decide to use HttpRuntime.Cache instead, so that you are not putting all the result on a per-user basis, then you have to worry about how long to store the objects in cache.

The logical approach would be to query the database with pagination

To prevent hitting your database so frequently, then you should cache the paged result with the search term + page number + page size (optional) as your cache key and store your result objects as the cache value, ideally with the cache expiration set. (You wouldn't want to serve stale search results till your cache gets evicted right?)

Lee Gary
  • 2,357
  • 2
  • 22
  • 38
  • When you say "query the database with pagination", how I can know how many records have matched my criteria? – AK47 Oct 09 '14 at 08:39
  • I know this approach, but what is good ? Either to bring One extra column (for only one value) or Caching at .Net side? – AK47 Oct 09 '14 at 08:44
  • You can nest your result from database to look something like this: `{ count: 2403, { your_result_object: { ... } }`, if you know what i mean.. the idea of caching is good, but memory is limited and there's a big difference between application state, session, cache & view state. You might want to find out more of the difference between each of them – Lee Gary Oct 09 '14 at 08:47
  • actually , I didn't got how to nest from SQL Result to {count:...}, can you please explain. – AK47 Oct 09 '14 at 08:49
  • 1
    i suggest you create a new question for that, as we are going off topic – Lee Gary Oct 09 '14 at 08:50
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/62731/discussion-between-ak47-and-lee-gary). – AK47 Oct 09 '14 at 08:53
1

I avoid using session state as it affects how your application scales in a load balanced environment. You have to ensure a user always has requests served from the same server because that is where session state is stored (unless you put it in the database, but that defeats the point in your situation).

I would try to use application caching. It does mean, if the user clicks Next or Prev and that request is served from another server, you'll have to go to the database again - but personally I would prefer to take that hit.

Have a look at this page, in particular scroll down to the Application Caching section.

Hope this helps.

Fordio
  • 3,410
  • 2
  • 14
  • 18