▲ | mrheosuper 5 days ago | |||||||||||||||||||||||||||||||||||||||||||
I dont like this pattern. The author example, checking if "Datetime is null" to check if user is authorized or not, is not clear. What if there are other field associated with login session like login Location ? Now you dont know exactly what field to check. Or if you receive Null in Datetime field, is it because the user has not login, or because there is problem when retriving Datetime ? This is just micro-optimization for no good reason | ||||||||||||||||||||||||||||||||||||||||||||
▲ | monkeyelite 5 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||
> Now you dont know exactly what field to check. Yes you do - you have a helper method that encapsulates the details. In the DB you could also make a view or generated column. > This is just micro-optimization for no good reason It’s conceptually simpler to have a representation with fewer states, and bugs are hopefully impossible. For example what would it mean for the bool authorized to be false but the authorized date time to be non-null? | ||||||||||||||||||||||||||||||||||||||||||||
|