najh
asked on
OO ASP.net - trying to understand the principles of using objects with ASP.net
I'm a relative newbie to ASP.net but I'm relatively familiar with ASP classic and I have a reasonable understanding of object oriented languages such as Java. (and C# seems very similar to me, so that's what I've been using in my early ASP.net development).
I'm quite happy with most of my ASP.net learning, but there's a big hole in my understanding - and I'd like some lovely experts to come along and explain some things to me in order to fill this chasm.
Right, lets say I have a web page for some customers and I want to hold some details about the customer who is logged in. Some of these details will be from what the user has supplied, like userid and password, and some of the details will be from the database which holds all the other details about the customer of course.
So, in my mind I'd like to instantiate a customer object, in which I'd hold various details. If the customer was to buy anything, I'd attach a shopping cart object and then some "shopping cart item" objects. Make sense?
Anyway, I can't understand how on earth this sort of thing works with ASP.net. I can create my customer object and I can call methods etc from an ASP.net page, but then what if i want to access my customer object on the next ASP.net page? How do i do that? I can't go an re-create the customer object can i. (well I can, but that's obviously a bit silly) Am I mean to keep some kind of reference to something? I just don't quite get it. Is it anything to do with Server Objects? (and if so how?)
So, I'd love an explanation. I've googled for many many hours and read (skimmed) a couple of books, but I still don't feel like I quite get this. I also realise I could hold this kind of data in a Session object, but that seems wrong. Surely the whole point of this is to use an object oriented methodology?
I'm quite happy with most of my ASP.net learning, but there's a big hole in my understanding - and I'd like some lovely experts to come along and explain some things to me in order to fill this chasm.
Right, lets say I have a web page for some customers and I want to hold some details about the customer who is logged in. Some of these details will be from what the user has supplied, like userid and password, and some of the details will be from the database which holds all the other details about the customer of course.
So, in my mind I'd like to instantiate a customer object, in which I'd hold various details. If the customer was to buy anything, I'd attach a shopping cart object and then some "shopping cart item" objects. Make sense?
Anyway, I can't understand how on earth this sort of thing works with ASP.net. I can create my customer object and I can call methods etc from an ASP.net page, but then what if i want to access my customer object on the next ASP.net page? How do i do that? I can't go an re-create the customer object can i. (well I can, but that's obviously a bit silly) Am I mean to keep some kind of reference to something? I just don't quite get it. Is it anything to do with Server Objects? (and if so how?)
So, I'd love an explanation. I've googled for many many hours and read (skimmed) a couple of books, but I still don't feel like I quite get this. I also realise I could hold this kind of data in a Session object, but that seems wrong. Surely the whole point of this is to use an object oriented methodology?
ASKER
Thanks strickdd, so is this the normal thing to do? And is it good practice to do this kind of thing? (I don't necessarily mean is this solution normal, but is the whole approach normal?)
I'm just really puzzled that I've not seen any tutorials or references in books regarding holding objects between pages and it makes me nervous that I'm actually just doing something in a weird ad-hoc way rather than going for a more "normal" solution.
I'm just really puzzled that I've not seen any tutorials or references in books regarding holding objects between pages and it makes me nervous that I'm actually just doing something in a weird ad-hoc way rather than going for a more "normal" solution.
"holding objects between pages"
this is called "state management", you can google "asp.net state management" for articles like this:
http://www.csharphelp.com/archives/archive207.html
if you're looking for a nice and fairly complex tutorial have a look at the ecommerce startkit provided by MS:
http://www.asp.net/downloads/starter-kits/paypal-ecommerce/
this is called "state management", you can google "asp.net state management" for articles like this:
http://www.csharphelp.com/archives/archive207.html
if you're looking for a nice and fairly complex tutorial have a look at the ecommerce startkit provided by MS:
http://www.asp.net/downloads/starter-kits/paypal-ecommerce/
najh,
Sessions are by far the most popular way to maintain state. You can also use cookies, querystrings, and a few other options. The reason Sessions are used more often is their ease of use, security, and resource management.
1) ease of use - view the code above and compare it to reading and writing a cookie, it is MUCH easier. You can also store complex objects (like your class object) to sessions
2) security - a session variable is specific to one computer, one browser session on that computer, and is linked by an ID that is basically un-guessable. Compared to a plain text query string, the security can't be beat.
3) resource management - sessions will hold their memory until the code tells them to clear or the timeout expires. This way you don't have information floating out there. Also, it prevents the problems of public terminals where someone can open a browser that has a login cookie for someone else.
Sessions are by far the most popular way to maintain state. You can also use cookies, querystrings, and a few other options. The reason Sessions are used more often is their ease of use, security, and resource management.
1) ease of use - view the code above and compare it to reading and writing a cookie, it is MUCH easier. You can also store complex objects (like your class object) to sessions
2) security - a session variable is specific to one computer, one browser session on that computer, and is linked by an ID that is basically un-guessable. Compared to a plain text query string, the security can't be beat.
3) resource management - sessions will hold their memory until the code tells them to clear or the timeout expires. This way you don't have information floating out there. Also, it prevents the problems of public terminals where someone can open a browser that has a login cookie for someone else.
ASKER
I think I'd got it into my head that ASP.net would deal with holding a whole application model together for me without having to deal with manually setting and getting the application's objects from the Session object with each trip to the server or change of page.
The thing is, .Net is stateless except when processing the page. This means the only during a post to the server will it maintain variables in the code-behind. These are lost once the postback is finished. The reason for this is simply memory management. If you think about how many people can hit a site and how much memory it would take to maintain state like that for EVERY variable, I don't think there is a server built that can handle that.
.Net is much like classic ASP, but it has a lot more features and flexibility. Hopefully this helps.
.Net is much like classic ASP, but it has a lot more features and flexibility. Hopefully this helps.
ASKER
So, do people ever use objects (like the customer object I gave in my attempt at an example) or do they just keep adding more session variables instead? What's normal? My gut instinct now is to create my customer object and use that (and all it's associated other objects) but I don't know if that's a bad idea or if I should just keep it really really simple and not bother using objects in that way and just create lots of session variables. (and arrays in the case of, say, a shopping cart).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
super. I think I'm happier about all this now... for the time being anyway! Thanks for your help.
Session["MyCustomer"] = myCustomerObject; //where myCustomerObject is already populated with info
On the next page:
CustomerClass myCustomerObject = (CustomerClass)Session["My