Link to home
Start Free TrialLog in
Avatar of riceman0
riceman0

asked on

ASP.NET globals?? (general architecture help)


Hi, I am brand new to ASP.NET, and even web development.  I am trying to write an application that allows the user to manipulate a server database, and I've been following the walkthroughs and have had moderate, although hard-fought, success.  I am using VB ASP.NET.

Now that I am successfully reading and writing data using SQL connection, DataGrid, etc (using the walkthroughs)., my instinct (being a normal windows developer) is to write a mydatabase class to encapsulate the work that needs to be done to initialize, terminate, query for or update my specific tables, etc; and to have my various pages call to this class when it needs to use the data (I'll have 5-10 pages on my site that need to look up or update a variety of data in a variety of ways).

Is this the right approach?  Is it even possible to have an app-wide global object (my proposed DB class) that is always there?  I see how I can create a class (project->Add class), but I actually don't see how to reference it from the codebehinds of any (much less all) of my pages.

Anyway, any thoughts on how to architect a database-interactive VB ASP.NET site would be helpful.  I'll spread the points around to any useful answers.  Thanks a lot!
SOLUTION
Avatar of margant
margant

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Avatar of Kevin Cross
Kevin Cross
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Took too long typing...nice post margant
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks mrichmon that is a good example of what I was referring too with static class.  This is the same concept as in Java.  This makes class a singleton (only one instance) and so only one will ever be created no matter how many calls.  

As I said before on updates, you will probably want to synchronize access.
Avatar of mrichmon
mrichmon

Yes it looks like the three of us were answering at the same time and the comments appeared in the order based on who finsihed typing first :o)
Avatar of riceman0

ASKER


mrichmon, what would be the difference there between class myData and namespace myData?  (I'm using VB, probably something similar?)

And it would just be static functions, meaning I could, or couldn't put member variables there that hold data that all pages could access?
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Oh but I would make a static method for retrieving this from the application.
That way if can check to make sure that the application space for that variable is null and if so, regenerate it before passing it off to the user. Ala:

    Public Shared Function GetMyObject() As MyType
        Dim application As HttpApplicationState = HttpContext.Current.Application

        application.Lock()
        Dim myObject As MyType = DirectCast(application.Item(APPLICATION_ENGINE_MANAGER), MyType)

        ' If a object doesn't exist here, create one
        If myObject Is Nothing Then
            myObject = new MyType(whatever_constructor_nonsense)

            application.Item(APPLICATION_ENGINE_MANAGER) = myObject
        End If

        Return myObject
    End Function
and that's what happens if you copy from existing code >_<

swap out APPLICATION_ENGINE_MANAGER for the application variable name =)
or create a constant, as we did, and use it that way (recommended)
Oh something else I forgot to mention... we use locks to stop one person reading or editing something while someone else is reading or editing...

That's the application.Lock()

if that doesnt look like a problem to you, fine, otherwise make another shared (static) function to unlock the application and call this after you're done with the data in your process. Ala:

    Public Shared Sub Unlock()
        HttpContext.Current.Application.UnLock()
    End Sub

So OliWarner, that worked well, however locks are necessary to ensure only one user is accessing an application object at a time stored this way?  Is that because it is essentially shared by everone that accesses the website?

OliWarner, what would happen if I used the Session instead of the Application, is that legal?
Or a context, msdn actually seems to say that's what it's for:

Context Provides access to the entire current context (including the request object). You can use this class to share information between pages. HttpContext
>> Is that because it is essentially shared by everone that accesses the website?

Correct. The object that I use in the application variable is real data that other users might use... If you're not doing something that uses this, you shouldnt need to use the locks... it sounds like from what you said earlier that you might need the locks in place, but as you can see, they're pretty simple... Just call the unlock method after you're done with the variable...

If other people come in and require something from the application, the server puts them on hold for a bit but processing time is so low its never noticeable.


Just a quick question though... why does this object need to persist?
>> OliWarner, what would happen if I used the Session instead of the Application, is that legal?
Sessions are a per-user variable... Each browser "session" with your site has its own session store which is separate from the others. Its good for storing information about the user or other data just about that one user. Its legal - I'm just not sure why you would want to do that. A session can still be the same for multiple concurrent requests... say the user loads up 15 windows of one page at once, if the object is in the session and you have no locks, chances are you'll end up with things overwriting each other.

Context is just an umbrella class for all things web-related in context.. for example it stores server information, down to the very incoming request. It also stores the application values hence why I use: HttpContext.Current.Application

The reason you have to call it through HttpContext here is because I'm assuming you're deep in a class. When working in a codebehind file these vars are autogenerated. Its like the difference between coding in JSP and servlets. Same language, slightly different rules.

The only reason I want the object to persist -- I might have asked this in a confused way -- is because I want information to be the same as a user navigates from page to page on  my site.  for example, the first page is a login screen, which records his information, checks it against a database, and loads up a lot of information about him/her.  If he has permission (per his record in the DB) to go to the edit screen, then he will be able to do so and the buttons on that screen will be enabled/disabled according to his other permissoins.

Having some shared DB info and User info would prevent having to retrieve the data again on each page; his current user info and his last query could remain loaded up in my new class, accessible from each page.

That's it.  Sounds like I might want the session variable?  Can I store my objects in there, too?
session seems to work too, I'll go with that unless anyone thinks I shouldn't,

Seems like I'm in business.  thanks all.
>>namespaces are groupings of classes... mrichmon just forgot to type a class line in there...
Yep I did - typing too fast :o)


Only disadvantage of sessions is that they expire after a time limit, but often this is not a problem.

Good luck