This may be common knowledge but I’ve never seen it online.
[] public Entity Entity { get; set; }
You now get a warning when accessing without a check and when setting to null.
Sadly you still need to ! in quries
This may be common knowledge but I’ve never seen it online.
[] public Entity Entity { get; set; }
You now get a warning when accessing without a check and when setting to null.
Sadly you still need to ! in quries
Well, you still have to ! because it may, based on the annotation, be null.
Very handy, regardless. Microsoft’s docs on these attributes are very interesting, particularly the postconditionals.
But that’s correct behaviour because if it isn’t included in the query it is null. So you should check it and the warnings are correct.
But like you say irritating if you’re doing it straight after an include haha
I think .NET and EF should handle navigation property nullabiloty better out of the box, especially when you explicitly set the foreign key to long?.
That said, while I understand these relationships in my own projects, adding clear annotations is very helpful for colleagues who may have to provide support in the future. That could even be me!
So there’s no perfect solution in this stack, but anything that makes a developer’s intent clearer helps. Privilege of least surprise, right?
Exactly.
What we need is someone to create an analyzer that recognises when you are writing an ef query or if you’ve included and disabled the warnings.
The actual issue is using the same model for the database and query results. I.e. it’s not nullable in the database but could be after a query. But there’s no nice way to implement this without mapping everything to a dto.