Comments 11
С приходом C#6 вот такое выражение DOOR_ID = door != null? door.DOOR_ID: (int?) null можно писать как door?.DOOR_ID
А вот такое doorHandle.Color != “RED” || doorHandle == null можно писать как doorHandle?.Color != “RED”
И я не совсем понял, почему условия тут идут в этом порядке, почему левую часть не переставить с правой?
А вот такое doorHandle.Color != “RED” || doorHandle == null можно писать как doorHandle?.Color != “RED”
И я не совсем понял, почему условия тут идут в этом порядке, почему левую часть не переставить с правой?
0
почему левую часть не переставить с правой?Можно и переставить.
Это ещё одна демонстрация концептуального разрыва. Для запроса к бд такая запись корректна, а в юнит-тесте выбросится исключение, если doorHandle == null.
0
В LINQ-запросах нельзя использовать оператор безопасной навигации. Для него не добавили особый тип Expression'а, поэтому ваш вариант не будет работать.
+2
Можно немного покодить, получить похожий, но немного более verbose вариант: www.thomaslevesque.com/2010/02/21/automating-null-checks-with-linq-expressions
0
Если мы говорим про EF и Navigation Properties, то там можно обойтись и без него: обычный оператор навигации при трансляции в SQL превращается в безопасный.
from c in context.Comments
select new
{
Text = c.Text,
UserName = c.User.Name // если c.User = null, UserName = null, ошибки не будет
}
0
Проблема в том, что тут абстракция течет. Нам нужно знать, что это IQueryable поверх EF, а не поверх какого-то другого провайдера. А если вы в тестах подкладываете реализацию поверх InMemory коллекций — получаете внезапно null ref
0
Тестировать работу с базой, собственноручно подсовывая вместо нее InMemory-коллекции, имхо, слишком ненадежно. Не отлавливается целая куча глупых багов, допускаемых по невнимательности — использование нетранслируемых методов типа
First
вместо FirstOrDefault
, или забытый ToList()
перед циклом. Хочется надеяться, что с этим как-то поможет поддержка тестирования в EF7.0
Подход похожий: модификация дерева выражений перед его выполнением.
Кстати, у вас для предотвращения NulLReferenceException возвращается не null, а default(TResult) (в методе With). Из-за этого в будущем могут быть проблемы, если вы решите обрабатывать ситуацию сравнения null == null.
Кстати, у вас для предотвращения NulLReferenceException возвращается не null, а default(TResult) (в методе With). Из-за этого в будущем могут быть проблемы, если вы решите обрабатывать ситуацию сравнения null == null.
0
А если null возвращать — будут проблемы со всякими не null типами
0
Sign up to leave a comment.
Библиотека, помогающая преодолеть концептуальный разрыв между ООП и БД во время тестирования при использовании ORM, — LinqTestable