• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 196
  • Last Modified:

Defining Site Variables

I have an application where on the first page the user selects a Town, the information they view is then based on that town.

What is the best way to store this variable and pass it between pages.

For example the variables gets passed in the query string for SEO.

Will it use to much resource if everytime the page loads I query the database on this variable.

E.g Select XY and Z where town = QueryString otherwise

Otherwise if I was to for example have

Message.Text = Convert.ToString(Request.QueryString("TownName")) this could then be manipulated and display the wront information.

Then I have the problem of if I have 6 user controls on the page to I need to do a query on each one or can I somehow make the results available to everything on that page.

I hope this makes sense as I am quite new to aspx

Thanks in Advance

Dave
0
tclgb
Asked:
tclgb
2 Solutions
 
softplusCommented:
Some ideas:
- Yes, use the QuerySting interface -- this is about the only way you can get parameters through an external link
- You could use Session-Variables, but maybe the user wants to look at two different towns, in two browser windows that share the same session?
- Why are you afraid of having the user modify you querystring? If he can choose the town, he might just as well modify it in the URL (should be no problem). If the town does not exist, then you'll throw an error message anyway, correct?
- Instead of names, you could use IDs
- If you are afraid of the user changing the query, you can add a hash or checksum to the query, i.e. http://server/where/where/site?id=12&something=this&that=there&check=2778 -- if the user changes anything in the query the checksum will not match + you can give him an error -- or just redirect him to the last valid page he viewed.
- If you want to get the town name based on the Id, you could cache the data in your site, i.e. add a collection/hashtable/array containg the Ids you've looked up and their names.

Does that help so far? :)
0
 
SilentBob42Commented:
I would pass around the id of the Town record using QueryString. Even if every page on your site would query the database with a query like:

SELECT Name
FROM Town
WHERE Id = [my_id_from_querystring]

It does mean some overhead of course, but keep in mind that these kind of queries are very easy for a RDBMS to solve. If you define your database keys, that is.

For protection of this variable see softplus' comment. Personally, I agree, I dont think you need protection from the user changing this, using session state or a checksum.
0
 
ovalsquareCommented:
Softplus' answer covers all the bases...other than of course, you could put the town into a cookie, then you don't have to hit the database everytime or server-side caching.

And regarding SilentBob42's answer, I'm sure he wasn't suggesting you hit your database directly like how he set it up as that would expose to sql-injection attacks - the easiest way to deal with that is with parameters or stored procedures (which need to use parameters).

Let me know if you need more information on any of this.

Ted
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
b1xml2Commented:
First of all the issue is the lifetime of the data and the global scope of the data.

Firstly, I find the use of Session to store non-global (per user) information as a serious breach. Simply because when a user presses control+N they may open new window/tab (Firefox) which re-uses the same Session and then you are in lal la land. Session should be used to store data that is global and which would not have any side effects or unexpected consequences.

Next, Since your question is not just about performance but about how to pass the data downstream from the Page to the UserControls. Remember point #1 when we discuss the solutions:

VS.NET
======
1. Implement an interface in your page.
2. Have your UserControls access the Page via the Interface implemented at the parent page:

[VB.NET]
Public Class MyPage
      Inherits System.Web.UI.Page
      Implements IMyPage
      
      
      Private Sub Page_Load(ByVal sender As Object,ByVal e As EventArgs) Handles MyBase.Load
            If Not Page.IsPostBack Then
                  Dim connection As New SqlConnection(..)
                  Dim adapter As New SqlDataAdapter("select * from table1",connection)
                  adapter.Fill(PageDataSet)
            End If
      End Sub
      
      Private ReadOnly Property() PageDataSet As DataSet
            Get
                  If ViewState("PageDataSet") Is Nothing Then
                        ViewState("PageDataSet") = New DataSet
                  End If
            End Get
      End Property
      
      'provides a copy of the original dataset stored/persisted
      Private ReadOnly Property() PageDataSetCopy() As DataSet Implements IMyPage.PageDataCopy
            Get
                  Return PageDataSet.Copy()
            End Get
      End Property
      
End Class

Public Interface IMyPage
      ReadOnly Property PageDataCopy() As DataSet
End Interface

[User Control]
Public Class MyUserControl
      Inherits System.Web.UI.UserControl
      
      Private ReadOnly Property PageInterface() As IMyPage
            Get
                  Return Me.Page
            End Get
      End Property
      
End Class

You can access the data via the PageInterface as in Me.PageInterface.PageDataCopy

That's one...where the client here the UserControls always have access to the "results", the DataSet. You will notice that the DataSet is stored in ViewState, this can be changed to Session

Strengths
======
1. Good for usage when need data to be persisted across postback.
2. Strongly typed objects (not the same as strongly typed datasets)
3. Particularly good for passing through fixed values from the Page to the User Controls like for instance QueryStrings. This way, the User Control does not need to know the key of the QueryString
4. Ease of implementation

Weaknesses
========
1. Data has to be copied when the User Control accesses the interface so that the master data is untouchable and unchangeable by the User Controis.
2. There is no notification process between the page and the user controls when the results have just been retrieved.
3. Since there is no notification, the interface approach is predicated on the data being persisted/stored and the user controls retrieve the data at their own urging/prompting. If you do not want to store the data in ViewState or anywhere else for that matter but just want to pass the data after it has been retrieved, this interface solution is not suitable.
0
 
b1xml2Commented:
[VB.NET]
Public Class MyPage
      Inherits System.Web.UI.Page
            
      Public Event ResultsRetrieved As ResultsRetrievedEventHandler
      
      Private Sub Page_Load(ByVal sender As Object,ByVal e As EventArgs) Handles MyBase.Load
            AddHandlers()
      End Sub
      
      'getting the User Controls to subscribe to the custom event
      'so that when we load and bind the data
      'we can also notify the user controls
      'and pass along the data
      Private Sub AddHandlers()
            AddHandler Me.ResultsRetrieved, UserControl1.Results
            AddHandler Me.ResultsRetrieved, UserControl2.Results
      End Sub
      
      Private Sub LoadAndBindData()
            Dim connection As New SqlConnection(..)
            Dim adapter As New SqlDataAdapter("select * from table1",connection)
            Dim data As New DataSet
            adapter.Fill(data)
            'bind data to datagrid
            DataGrid1.DataSource = data
            DataGrid1.DataBind()
            'now provide notifications
            RaiseEvent ResultsRetrieved(Me,New ResultsRetrievedEventArgs(data.Copy()))
      End Sub
      
      
      
      
      'provides a copy of the original dataset stored/persisted
      Private ReadOnly Property() PageDataSetCopy() As DataSet Implements IMyPage.PageDataCopy
            Get
                  Return PageDataSet.Copy()
            End Get
      End Property
      
End Class

Public Delegate Sub ResultsRetrievedEventHandler(ByVal sender As Object, ByVal args As ResultsRetrievedEventArgs)

Public Class ResultsRetrievedEventArgs
      Inherits EventArgs
      
      Public ReadOnly PageDataSet As DataSet
      
      Public Sub New (ByVal value As DataSet)
            PageDataSet = value
      End Sub
      
End Class

UserControl
=========
Public Class MyUserControl
      Inherits System.Web.UI.UserControl
      
      Public Sub Results(ByVal sender As Object,ByVal args As ResultsRetrievedEventArgs)
            Dim ds As DataSet = args.PageDataSet
            'we get the data here
            'and then do something
      End Sub
      
End Class







0
 
b1xml2Commented:
1. so if you want to query the database and pass the data along the way to the user controls, you should use custom events if you are unsure exactly when the data will be retrieved.
2. if the data is retrieved once, at the beginning of the page and needs to be made available to the user controls, you can use the interface approach(since the data will need to persisted)

As for performance, the question is about lifetime and scope. If the data is referenced data and likely to be less volatile or non-volatile, you can store the data in the cache object (not session, not viewstate, and certainly not application)

0
 
cluster1Commented:
hi
 could please tell me how u deploy your webapplication  to webserver(that is how you ar e running your your web application as website)
plz help me to sort out my problem
thanx
waitng for your reply
0

Featured Post

Prep for the ITIL® Foundation Certification Exam

December’s Course of the Month is now available! Enroll to learn ITIL® Foundation best practices for delivering IT services effectively and efficiently.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now