I will add my voice to the others here who recommend avoiding LINQ syntax. Most MS development shops have gotten away from LINQ syntax and your query shows one good reason:
It might be more efficient for the where to execute before the join. With the LINQ syntax you can do it but it looks odd.
For your specific case, I suggest you turn _context.Tokens into an IDictionary<string, Token> or even IDictionary<string, User> where the token body is the key. Then your method looks like this:
Ah. I did not know what _context was and I was not aware you were using EF. I assumed _context was some kind of property bag or class you controlled. So, the answer is no you would not have a UsersByToken property on your DbContext and it would not map to the database. Instead it should be a local field/property in your login class. Now that I understand you are making round trips to the database, you will find IDictionary<> to be even more efficient than your current code, but you will need a fall back to retrieving the user from the database if it is not found associated the provided token in your dictionary.
I will add my voice to the others here who recommend avoiding LINQ syntax. Most MS development shops have gotten away from LINQ syntax and your query shows one good reason:
It might be more efficient for the
where
to execute before thejoin
. With the LINQ syntax you can do it but it looks odd.Now compare:
For your specific case, I suggest you turn
_context.Tokens
into anIDictionary<string, Token>
or evenIDictionary<string, User>
where the token body is the key. Then your method looks like this:I have a question with this one. How would my DBContext class look like, will this UsersByToken field have to be mapped to a table in the bd too?
One thing that has been mentioned a couple of times is that I should consider using IDictionary, I'm looking forward to it
Ah. I did not know what
_context
was and I was not aware you were using EF. I assumed_context
was some kind of property bag or class you controlled. So, the answer is no you would not have aUsersByToken
property on yourDbContext
and it would not map to the database. Instead it should be a local field/property in your login class. Now that I understand you are making round trips to the database, you will findIDictionary<>
to be even more efficient than your current code, but you will need a fall back to retrieving the user from the database if it is not found associated the provided token in your dictionary.Thank you for this. Seems like IDictionary and IQueryable are my best bet for getting the most out of EF