On Nov 6, 2007 5:05 PM, Danny Angus <[EMAIL PROTECTED]> wrote: > On 06/11/2007, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > > Maybe the right solution would be to split the UsersRepository in > > "AuthService" and "UserPreferenceService". IIRC we discussed this in > > past, but I don't remember anymore the result of the discussion. > > > > BTW I'm also fine with what you proposed. > > I much prefer Stefano's idea, have a separate service with a clear > responsibility for meta-data "joined" to users. We did discuss it > before. I think we need to be careful where people might want to > implement users in shared ldap or something, not to impose a whole lot > of other things on their implementation.
separating user authentication from user meta-data sounds like the right call to me UsersRepository seems fine as it is - maybe we just need to create a new interface. following that naming pattern, UserMetaDataRepository suggests itself. the next question has to be about the structure of the data Zsombor suggests object storage. serialization issues upon upgrade could be worked around by careful use of SerialUID or externalisation. another option would be to just store text and force callers to format (into xml, say). i think the simplest keying strategy should be good enough - just a string, reserving org.apache.james namespace for JAMES use. in API design terms, the question is interface granulatity. one extreme is to use a value object containing all user meta-data: UserMetaData getData(User user) at the other, get each separately: ??? get(User user, String key) set(User user,String key, ???) (not sure i have a strong preference) opinions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
