Библиотека, помогающая преодолеть концептуальный разрыв между ООП и БД во время тестирования при использовании ORM, — LinqTestable

[VladVR]

С приходом C#6 вот такое выражение DOOR_ID = door != null? door.DOOR_ID: (int?) null можно писать как door?.DOOR_ID
А вот такое doorHandle.Color != “RED” || doorHandle == null можно писать как doorHandle?.Color != “RED”
И я не совсем понял, почему условия тут идут в этом порядке, почему левую часть не переставить с правой?

[FiresShadow]

почему левую часть не переставить с правой?

Можно и переставить.

Это ещё одна демонстрация концептуального разрыва. Для запроса к бд такая запись корректна, а в юнит-тесте выбросится исключение, если doorHandle == null.

[impwx]

В LINQ-запросах нельзя использовать оператор безопасной навигации. Для него не добавили особый тип Expression'а, поэтому ваш вариант не будет работать.

[FractalizeR]

Можно немного покодить, получить похожий, но немного более verbose вариант: www.thomaslevesque.com/2010/02/21/automating-null-checks-with-linq-expressions

[impwx]

Если мы говорим про EF и Navigation Properties, то там можно обойтись и без него: обычный оператор навигации при трансляции в SQL превращается в безопасный.

from c in context.Comments
select new
{
    Text = c.Text,
    UserName = c.User.Name // если c.User = null, UserName = null, ошибки не будет
}

[mird]

Проблема в том, что тут абстракция течет. Нам нужно знать, что это IQueryable поверх EF, а не поверх какого-то другого провайдера. А если вы в тестах подкладываете реализацию поверх InMemory коллекций — получаете внезапно null ref

[impwx]

Тестировать работу с базой, собственноручно подсовывая вместо нее InMemory-коллекции, имхо, слишком ненадежно. Не отлавливается целая куча глупых багов, допускаемых по невнимательности — использование нетранслируемых методов типа First вместо FirstOrDefault, или забытый ToList() перед циклом. Хочется надеяться, что с этим как-то поможет поддержка тестирования в EF7.

[mird]

Скажите, а ваш подход к реализации чем-то отличается от описанного мной тут?

[FiresShadow]

Подход похожий: модификация дерева выражений перед его выполнением.
Кстати, у вас для предотвращения NulLReferenceException возвращается не null, а default(TResult) (в методе With). Из-за этого в будущем могут быть проблемы, если вы решите обрабатывать ситуацию сравнения null == null.

[mird]

А если null возвращать — будут проблемы со всякими не null типами

[FiresShadow]

Да, но их можно решить. Можно менять дерево выражений внутри как угодно. Нельзя наружу вернуть null, если возвращаемое значение присваивается not nullable полю, но это и не нужно: при такой попытке ORM кидает исключение; следовательно, должен кинуть исключение и unit-тест.