This project is read-only.

Email address, Primary Key, validations Error messages and DAL

Oct 2, 2014 at 11:34 PM
Would be nice if I could discard de UserName and keep the Email for authentication. Today I have both fields with same data.

I think its very complex (to me) to change that Guid user id and start use int. Same thing to rewrite the error messages returned when the manager validade that user already exists. Today Im showing to my user the "Name {0} ia already taken" message for an Email field.

Another thing is that I using a DAL (with procs and EF) to access the data and have to mainteining the Identity access layer.
Oct 15, 2014 at 12:34 PM
I think it makes sense to expose the email as two properties. You don't have to actually store it twice; if may only be a single property in your DAL / a single column in your database table / whatever is relevant for your data store. Think about it: you'd still need a way to say "the identifier used for authentication is the email". The choice roughly comes down to setting a flag and checking it everywhere or setting two properties to the same string object and just use the appropriate property when you need it without thinking about it. I believe the latter (which is used today) is better (more flexible, simpler all-around, probably more efficient - though negligibly).

I agree though that the name of the property "UserName" is not appropriate, and neither are the error messages. That being said, no good generic replacement immediately comes to mind. I think your best bet is to provide your own translation for this string, falling back to the official resource files for the other strings.

They could use a flag (or check if UserName == Email) to switch the message to return (providing another one specifically for the case when the identifier is the email address), but I feel this is too specific to be accepted. Indeed, the identifier (UserName) could be any other property on the type (which you may extend, don't forget), so at some point it becomes application-specific.

Letting applications specify just that property name in a localized string (to be embedded in the localized error message) is not satisfactory either, as some languages may see the order of words change depending on the words themselves.

Hence, the only correct solution (short of special-casing for a subset of the problem) is to ask the developers to provide the entire application-specific string for that message (if they're not happy with the default).