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.
