Well, you wouldn't ask the User object itself, because then it would have to know about the data layer which increases coupling: not a good thing.
You could ask the mapper whether or not the username was allowed, but that would require a highly specialized function added into the interface: sure, it works, but only one segment of code uses it.
I like my technique best, though, because it sidesteps a possible (albeit unlikely) race condition where you check if the username is available, instantiate the user object, and then attempt to save it to the database. During the period where you checked availability and you insert the user, there's a chance that another person may register that same name. Once again, this is highly unlikely, but exists nonetheless, and requires you to build appropriate error checking.
Of course, if you want to add an AJAX like call to the registration interface to check availability, you'd need a function like this. Once again in the spirit of laziness, I would simply attempt to retrieve the user via the usual channels, and depending on the success of the operation report back appropriately. You may argue that this is inefficient, since you are pulling back a bunch of columns you don't need, but it seems that MySQL doesn't really care how many columns you pull: they don't incur a performance impact.
usernameAvailable method of Model class - good design?
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
If it is an object created by a Data Mapper then no. But if it is and Active Record or Table Data Gateway object then it could certainly know.Ambush Commander wrote:Well, you wouldn't ask the User object itself, because then it would have to know about the data layer which increases coupling: not a good thing.
(#10850)