Keeping Users logged in

[TomTees]

What are the different ways you can keep a User "logged in"?

 

From what I *vaguely* recall from a year or two ago when I read a whole hoard of PHP books, you commonly use cookies and sessions.

 

But I'm asking this more from an OOP standpoint than a PHP standpoint.

 

Let's say I have a User record in my database, and a User comes along and attempts to log in.

 

In OOP terms, I would think you'd call some class to help log them in, and upon successfully logging in, you would "load" the User object into memory and set the "LoggedIn" field to "True". Then as long as that field was set in their object, they could surf all over the place and do things like change their account and buy things.

 

Is that how you would do it in OOP?

 

 

 

TomTees

 

[KevinM1]

You can still stuff that user object in a session.  You may not want to store the entire object that way if your user object is fairly large, however.  Also, there's nothing wrong with doing it the 'normal' way.  In fact, you could store a user's username and some sort of temporary unique identifier in sessions, then rebuild the user object when necessary from that.  That would save you from passing the entire object from page to page.

[TomTees]

You can still stuff that user object in a session.  You may not want to store the entire object that way if your user object is fairly large, however.  Also, there's nothing wrong with doing it the 'normal' way.  In fact, you could store a user's username and some sort of temporary unique identifier in sessions, then rebuild the user object when necessary from that.  That would save you from passing the entire object from page to page.

 

Why would I need a User object in the first place (after creating a User in the database)?

 

I'm still trying to figure out how to model things and struggling.

 

Like I want to have a Registration class (maybe call it RegistrationService).  I can see why it exists, i.e. to register someone!  But after they are registered, that object is no longer needed.

 

I'm not so sure when and where and why you would use a "User" object unless you are doing something directly to the user.

 

I mean do you need a "User" object loaded into memory to allow someone to surf your website?  Or even to add items to their Shopping Cart?

 

I am trying to build an OOP site, so I don't want lots of procedural spaghetti code messing things up, but I'm also having a big disconnect of when and where to use a "User" object if that makes sense?! 

 

 

 

TomTees

 

 

[KevinM1]

You can still stuff that user object in a session.  You may not want to store the entire object that way if your user object is fairly large, however.  Also, there's nothing wrong with doing it the 'normal' way.  In fact, you could store a user's username and some sort of temporary unique identifier in sessions, then rebuild the user object when necessary from that.  That would save you from passing the entire object from page to page.

 

Why would I need a User object in the first place (after creating a User in the database)?

 

Well, what else could "load the User object into memory" mean?  I'm only responding to what you wrote.

 

I'm still trying to figure out how to model things and struggling.

 

Like I want to have a Registration class (maybe call it RegistrationService).  I can see why it exists, i.e. to register someone!  But after they are registered, that object is no longer needed.

 

Hint - think static.

 

I'm not so sure when and where and why you would use a "User" object unless you are doing something directly to the user.

 

I mean do you need a "User" object loaded into memory to allow someone to surf your website?  Or even to add items to their Shopping Cart?

 

For the former, not necessarily.  For the latter, I would.  At the very least it's more convenient to deal with objects in that case than with the db directly, especially if you have a decent ORM.

 

I am trying to build an OOP site, so I don't want lots of procedural spaghetti code messing things up, but I'm also having a big disconnect of when and where to use a "User" object if that makes sense?! 

 

Again, it's often a matter of convenience.  For one, you can keep the object in memory, giving you delayed execution if you want it.  Second, you can represent CRUD as methods.  Third, for me, it makes more sense conceptually to deal with objects.  Since this is OOP, why wouldn't I represent a user as an object?  Yeah, it's overkill if you only want to display their name on the screen, but for anything of reasonable complexity it makes sense to use an object.

[TomTees]

You can still stuff that user object in a session.  You may not want to store the entire object that way if your user object is fairly large, however.  Also, there's nothing wrong with doing it the 'normal' way.  In fact, you could store a user's username and some sort of temporary unique identifier in sessions, then rebuild the user object when necessary from that.  That would save you from passing the entire object from page to page.

 

Why would I need a User object in the first place (after creating a User in the database)?

 

Well, what else could "load the User object into memory" mean?  I'm only responding to what you wrote.

 

You lost me...

 

I was asking what purpose having a User object loaded into memory would be while you are just surfing.

 

You suggested using sessions the normal way which means I wouldn't even need an object, right?

 

So I'm just trying to figure the purpose of a User object.

 

 

 

I'm still trying to figure out how to model things and struggling.

 

Like I want to have a Registration class (maybe call it RegistrationService).  I can see why it exists, i.e. to register someone!  But after they are registered, that object is no longer needed.

 

Hint - think static.

 

Not following you.

 

 

I'm not so sure when and where and why you would use a "User" object unless you are doing something directly to the user.

 

I mean do you need a "User" object loaded into memory to allow someone to surf your website?  Or even to add items to their Shopping Cart?

 

For the former, not necessarily.  For the latter, I would.  At the very least it's more convenient to deal with objects in that case than with the db directly, especially if you have a decent ORM.

 

So just like anything left in memory - which is all objects are, right? - you do it to speed things up, right?

 

Just like the concept of cache...

 

 

I am trying to build an OOP site, so I don't want lots of procedural spaghetti code messing things up, but I'm also having a big disconnect of when and where to use a "User" object if that makes sense?! 

 

Again, it's often a matter of convenience.  For one, you can keep the object in memory, giving you delayed execution if you want it.  Second, you can represent CRUD as methods.  Third, for me, it makes more sense conceptually to deal with objects.  Since this is OOP, why wouldn't I represent a user as an object?

 

No.  Not, "Why would I represent a User as an object".

 

I'm asking, "What justification do I have for keeping a User object tying up my memory?""  (Unless I'm doing something major like changing an e-mail, updating preferences, etc.)

 

 

Yeah, it's overkill if you only want to display their name on the screen, but for anything of reasonable complexity it makes sense to use an object.

 

That I can see, but then that leads me to ask...

 

1.) Exactly how much memory would it take up to leave a User object up and running in memory?

 

Right now, my fields would be...

 

- email

- password

- firstName

- middleInitial

- lastName

- displayName

- agreeToTerms

- age

- lastVisited

- loggedIn

- userRole

 

and maybe a half-a-dozen more fields?!

 

(All of the preferences and what-not would be in separate, but linked classes.)

 

So how much would such a creature take up in memory?

 

 

2.) What is the hit to load and unload a User object if it would be deemed a "memory hog"?  (I'd think it would be more of a strain on your database loading it up again?)

 

 

3.) What does Amazon.com do?

 

 

TomTees

 

 

[KevinM1]

 

 

 

You can still stuff that user object in a session.  You may not want to store the entire object that way if your user object is fairly large, however.  Also, there's nothing wrong with doing it the 'normal' way.  In fact, you could store a user's username and some sort of temporary unique identifier in sessions, then rebuild the user object when necessary from that.  That would save you from passing the entire object from page to page.

 

 

Why would I need a User object in the first place (after creating a User in the database)?

 

Well, what else could "load the User object into memory" mean?  I'm only responding to what you wrote.

 

You lost me...

 

I was asking what purpose having a User object loaded into memory would be while you are just surfing.

 

You suggested using sessions the normal way which means I wouldn't even need an object, right?

 

So I'm just trying to figure the purpose of a User object.

 

Well, like I tried to say last night, in most cases you wouldn't, unless you needed to act upon the user object itself.  Take something like a user editing their profile.  It makes sense to load an object with the current data stored in the db, have the system work with the object to make the changes, then have the object save the new changes back to the db. 

 

 

I'm still trying to figure out how to model things and struggling.

 

Like I want to have a Registration class (maybe call it RegistrationService).  I can see why it exists, i.e. to register someone!  But after they are registered, that object is no longer needed.

 

Hint - think static.

 

Not following you.

 

If user registration is a one-time-use activity, you don't need to go through the hassle of instantiating an object for it.  You don't care about actually having an object in hand, but rather you just want access to its registration method.  Make that method static and call it:

 

 

RegistrationService::registerNewUser(/* data */);

 

 

 

I'm not so sure when and where and why you would use a "User" object unless you are doing something directly to the user.

 

I mean do you need a "User" object loaded into memory to allow someone to surf your website?  Or even to add items to their Shopping Cart?

 

For the former, not necessarily.  For the latter, I would.  At the very least it's more convenient to deal with objects in that case than with the db directly, especially if you have a decent ORM.

 

So just like anything left in memory - which is all objects are, right? - you do it to speed things up, right?

 

Just like the concept of cache...

 

Somewhat.  It's more to make it faster on a human level.  If I can deal with an object, I don't need to worry about the implementation details of how to record and store that data.  It's hidden behind methods.  I'd much rather deal with an object's interface than have to it the other way.

 

Remember, OOP is a methodology to make programming easier for humans.  If this was about memory efficiency, we'd all be writing binary or assembly.

 

 

I am trying to build an OOP site, so I don't want lots of procedural spaghetti code messing things up, but I'm also having a big disconnect of when and where to use a "User" object if that makes sense?! 

 

Again, it's often a matter of convenience.  For one, you can keep the object in memory, giving you delayed execution if you want it.  Second, you can represent CRUD as methods.  Third, for me, it makes more sense conceptually to deal with objects.  Since this is OOP, why wouldn't I represent a user as an object?

 

No.  Not, "Why would I represent a User as an object".

 

I'm asking, "What justification do I have for keeping a User object tying up my memory?""  (Unless I'm doing something major like changing an e-mail, updating preferences, etc.)

 

 

Yeah, it's overkill if you only want to display their name on the screen, but for anything of reasonable complexity it makes sense to use an object.

 

That I can see, but then that leads me to ask...

 

1.) Exactly how much memory would it take up to leave a User object up and running in memory?

 

Right now, my fields would be...

 

- email

- password

- firstName

- middleInitial

- lastName

- displayName

- agreeToTerms

- age

- lastVisited

- loggedIn

- userRole

 

and maybe a half-a-dozen more fields?!

 

I'd say your User object is a bit bloated.  I wouldn't store password info in an object at all.  You're most likely not going to use it.  Leave it in the db, and retrieve it when necessary.  AgreeToTerms is a useless field.  Presumably there wouldn't be a user if they didn't agree to terms.  The same goes for loggedIn - there wouldn't be an instantiated object if they weren't logged in.  Think about trimming it down.  You don't need a 1-1 mapping between your object and its backing db row.

 

 

So how much would such a creature take up in memory?

 

At the very least, as much as its component data structures.  One byte per string character, 4-8 bytes per int, etc.  There's some overhead for it simply being an object.  Not sure how much methods take.

 

 

2.) What is the hit to load and unload a User object if it would be deemed a "memory hog"?  (I'd think it would be more of a strain on your database loading it up again?)

 

Yeah, the bottleneck is at the db in most cases.

 

 

3.) What does Amazon.com do?

 

Not sure.  I have the feeling they use a simplified user object until you go to checkout, or another account area, where it then loads the full object.  I don't think credit card info ever leaves its db.

 

All that said, I wouldn't worry about memory at this time.  The key is to get an understanding of the principles first.  Performance should come later.

[TomTees]

Nightslyr,

 

This was a very informative post.  Thanks!!

 

Well, like I tried to say last night, in most cases you wouldn't, unless you needed to act upon the user object itself.  Take something like a user editing their profile.  It makes sense to load an object with the current data stored in the db, have the system work with the object to make the changes, then have the object save the new changes back to the db.

 

And then you would destroy the current object when you are done updating it (and the record behind it)?

 

 

If user registration is a one-time-use activity, you don't need to go through the hassle of instantiating an object for it.  You don't care about actually having an object in hand, but rather you just want access to its registration method.  Make that method static and call it:

 

RegistrationService::registerNewUser(/* data */);

 

Well, accept I would expect "Registration" to have some state/persistence.  If the registration process fails at any point, you'd need an object to allow a person to pick up where they left off, right?

 

Also, Registration is complex in my mind.  There are several steps involved, it has "data" and "actions" and it can be extended.  All of these things require a class/object and not just a method.

 

 

Somewhat.  It's more to make it faster on a human level.  If I can deal with an object, I don't need to worry about the implementation details of how to record and store that data.  It's hidden behind methods.  I'd much rather deal with an object's interface than have to it the other way.

 

Remember, OOP is a methodology to make programming easier for humans.  If this was about memory efficiency, we'd all be writing binary or assembly.

 

Okay.

 

 

 

1.) Exactly how much memory would it take up to leave a User object up and running in memory?

 

Right now, my fields would be...

 

- email

- password

- firstName

- middleInitial

- lastName

- displayName

- agreeToTerms

- age

- lastVisited

- loggedIn

- userRole

 

and maybe a half-a-dozen more fields?!

 

I'd say your User object is a bit bloated.  I wouldn't store password info in an object at all.  You're most likely not going to use it.  Leave it in the db, and retrieve it when necessary.

 

Oh, I thought there had to be a 1-to-1 mapping between objects and the database.

 

 

AgreeToTerms is a useless field.  Presumably there wouldn't be a user if they didn't agree to terms.

 

Not useless in the database.  I need proof someone "accepted" the "terms".  Depending on how I would use (or not use) the "User" object during "Registration", would affect if I need this field in the object.

 

 

The same goes for loggedIn - there wouldn't be an instantiated object if they weren't logged in.  Think about trimming it down.  You don't need a 1-1 mapping between your object and its backing db row.

 

But this goes back to my original post in some ways...

 

Let me describe a related scenario and you tell me if I'm thinking this OOP thing out correctly...

 

A registered user (i.e. "Customer") needs to log in to my site to do whatever.  As such, they have already registred, and for this discussion, we really don't care how they registered or what objects were involved.

 

If I had to take a stab at how logging in would work in the OOP world, here is my best guess...

 

Logging In Sequence:

- Customer goes to Log-In screen

- Customer enters Email and Password

- Customer clicks "Log In"

- A User object is created with the form credentials

- An Authentication object is created

- The User object is passed to the Authentication object

- The Authentication object compares the credentials in the User object against the database

- If there is a match, the Authentication object *SETS* the "LoggedIn" field in the User object to "True" (and possibly does something in the backend database, but probably not)

- The Authentication object passes control back over to the website, and the Customer is taken to wherever they were trying to log in to (e.g. User Control Panel, Checkout, Email, etc).

- As long as the Customer wants/needs to be "logged in", they are relying on their User object being in memory, following them around, and their User object having its "LoggedIn" field set to "True".  (Basically I'm using the User object as a cookie or session on steroids!!  With the added benefit being that a User object in memory can do more for the Customer and the Programmer than just a static cookie or session could do...)

 

If you asked me how I would conceptualize and implement "logging in" using OOP, that is the approach I'd take.

 

What do you think?

 

 

 

So how much would such a creature take up in memory?

 

At the very least, as much as its component data structures.  One byte per string character, 4-8 bytes per int, etc.  There's some overhead for it simply being an object.  Not sure how much methods take.

 

Okay.

 

2.) What is the hit to load and unload a User object if it would be deemed a "memory hog"?  (I'd think it would be more of a strain on your database loading it up again?)

 

Yeah, the bottleneck is at the db in most cases.

 

Okay, I thought so.

 

 

3.) What does Amazon.com do?

 

Not sure.  I have the feeling they use a simplified user object until you go to checkout, or another account area, where it then loads the full object.

 

I don't personally think my User object was that bloated.  30+ fields is bloated.  I only had maybe a dozen, and now that I understand you don't have to have a 1-to-1 mapping between object and table, maybe I could drop out a few one-time fields like "age", "agreeToTerms", etc.

 

That is an interesting point about splitting an object up into two parts!  I was wondering about that last night...

 

 

 

  I don't think credit card info ever leaves its db.

 

In my world, I won't be storing them at all!

 

 

All that said, I wouldn't worry about memory at this time.  The key is to get an understanding of the principles first.  Performance should come later.

 

True.

 

Thanks for the help so far!

 

 

TomTees

 

 

 

[KevinM1]

I wouldn't construct a User object at all unless their credentials are legit.  That way, you save yourself the trouble of building an object which may not represent an actual user, and the mere presence of a User object tells you that the person is logged in.  No need for a separate field.

 

So, send the raw data to the Authenticator, have it do its thing, and if successful it returns a populated User.

 

Regarding the use of a User object in updating a profile, in a lot of cases you wouldn't have to manually destroy the object.  Either you'd keep it loaded in sessions if you need to keep it around for other processes, or it would be destructed automatically when the end user is taken to a different part of the site (update confirmation screen, or even a reload of the current page).