I suppose it is almost like the question, 'do you need to know your own phones number?' For the majority of uses of a telephone as a communication device, you don't need to know it.
Personally, I would be a little uncomfortable with this. mostly because it feels like you are taking a user 'entity' and splitting it up and spreading its information across your system in different places (user name being stored in session at point of login?) But, I realise that that is just a gut reaction from someone who has ALWAYS done it that way, not for any actually valid reason (that I can immediately) articulate. On 29 July 2013 12:12, Phil Kershaw <[email protected]> wrote: > Yes, a User object should be aware of it's username, password (encrypted > or otherwise), email address etc.. > > Then pass the User to a Validator Object. Whether the validator validates > against the username is irrelevant since the username may be used elsewhere. > > The point being, in my opinion, the User object should be made up of > everything that describes a User (i.e. username is this and/or user can do > this/that). > > > -- > Phil > > > On 29 July 2013 11:52, Jon Rowe <[email protected]> wrote: > >> > You also don't need the User to know the username for display purposes, >> as you captured that when the user logged in. >> >> So where is the username held for display purposes? Or are you using a >> real name / email on screen? How will you correlate actions between the >> user and other elements in the system? >> >> Jon Rowe >> ----------------------------- >> [email protected] >> jonrowe.co.uk >> >> On Monday, 29 July 2013 at 20:35, Ash Moran wrote: >> >> Hi all >> >> Quick question (and maybe a Monday brainteaser) for you all, but first >> I'll explain the context. >> >> I've just written a User (in the sense of user account / login) class >> (pure Ruby, no ActiveRecord). I'm doing validation in a separate object, to >> separate the concerns, so effectively I have a User, and a UserValidator. >> >> Originally, to sign up a user, a SignUpUser object creates a User and >> validates it with a UserValidator. I realised that I was passing in >> username and email fields, only to fetch them back out to validate. This >> made me wonder why I wasn't just making the SignUpUser validate the >> details, and not create the User if this failed (basic Lean stuff really). >> So I refactored it and now use the UserValidator to validate the command >> itself - if username or email are invalid, the server rejects it and never >> even instantiates a User object. >> >> Now lacking validation as a reason to store the username in the User, I >> started to wonder what *is* a reason. So here's the question: has anyone >> ever implemented any behaviour (decision, or action on another object) on a >> User object that requires the username? For example, the user needs to know >> its encrypted password in order to decide whether to accept a given >> password to log in. But you don't need the username for this by the time >> you have the User. You also don't need the User to know the username for >> display purposes, as you captured that when the user logged in. >> >> I'm using a technique called event sourcing[1] to persist objects, so I >> have the option later to put the username in the User's internal state when >> I retrieve an object, but currently I don't do that, and that surprised me. >> >> Ash >> >> [1] http://codebetter.com/gregyoung/2010/02/20/why-use-event-sourcing/ >> >> -- >> http://www.patchspace.co.uk/ >> http://www.linkedin.com/in/ashmoran >> >> -- >> You received this message because you are subscribed to the Google Groups >> "NWRUG" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/nwrug-members. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "NWRUG" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/nwrug-members. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "NWRUG" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/nwrug-members. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/groups/opt_out.
