Например, такое выражение

if (enumValue == MyEnum.One || enumValue == MyEnum.Two || enumValue == MyEnum.Three)

можно записать так - гораздо короче и понятнее

if (enumValue is MyEnum.One or MyEnum.Two or MyEnum.Three)

А что если в if проверяется ещё что-то? Например

if (obj != null || enumValue == MyEnum.One || enumValue == MyEnum.Two || enumValue == MyEnum.Three)

Тогда можно записать

if (obj != null || enumValue is MyEnum.One or MyEnum.Two or MyEnum.Three)

Но тогда непонятно, что вперёд выполняется. Где в спецификации языка или в МСДН написано, что операторы имеют бОльший приоритет, чем паттерны?

Или ваше предложение, как написать понятнее, но чтобы не портянку как в третьей строчке.

Нашёл только это пока

https://learn.microsoft.com/en-us/dotnet/csharp/language-r...

Но тут про приоритет лишь паттернов, но не паттернов и операторов.

ну вроде ж очевидно, что сначала выполняется is..or, а потом ||
Или твой вопрос был не в этом?

Для твоего случая можно написать что-нибудь типа этого

int number = 5;
bool res = number.In(1,2,3,4);
 
public static bool In<T>(this T item, params T[] items)
{
    if (items == null)
       throw new ArgumentNullException("items");

    return items.Contains(item);
}

Ну, для меня было не очевидно. Вообще, все "очевидности" должны быть явно прописаны - вот я и спрашивал, может кто знает, где точно указано, что операторы вперёд паттернов.

Да для таких вещей не надо ничего расширяющего писать - всё есть. Если руками каждое отдельное число забивать, то проще массив через скобочки. Если сгенерить последовательность подряд идущих чисел, то проще Enumerable.Range или что-то такое. И потом IEnumerable.Contains. У меня вариант, когда надо проверить на равенство двум-трём значениям. Обычно это для перечислений или чего подобного с небольшим количеством возможных значений. Просто неохото писать портянку || или && с повторением проверяемого значения.

Вобщем, уже понял, что проще делать типа такого

A is B or C or D

или для понятливости

A is (B or C or D)

А ты поломай голову и напиши тест, который тебе это покажет. Ставлю на то, что не напишешь.

Да для таких вещей не надо ничего расширяющего писать - всё есть. Если руками каждое отдельное число забивать, то проще массив через скобочки. Если сгенерить последовательность подряд идущих чисел, то проще Enumerable.Range или что-то такое. И потом IEnumerable.Contains.

По мне так это гораздо более громоздко чем в моём примере.

Всё написано и проверено уже - работает.

ну вроде ж очевидно, что сначала выполняется is..or, а потом ||

Почему очевидно?

if (obj != null || enumValue is MyEnum.One or MyEnum.Two or MyEnum.Three)

ЕМНИП вычисление выражений идет слева направо, так что сначала будет вычислено "obj != null" и если это выражение true, то все остальное в принципе не должно вычисляться.

Просто неохото писать портянку || или && с повторением проверяемого значения.
Вобщем, уже понял, что проще делать типа такого
A is B or C or D
или для понятливости
A is (B or C or D)

Для понятливости надо избегать смешивания разных видов записей.

И чем проще выражение внутри if'а, тем лучше.

В твоем случае лучше было бы записать так:

bool allowedValue = enumValue is MyEnum.One or MyEnum.Two or MyEnum.Three;
if (obj != null || allowedValue)

ЕМНИП вычисление выражений идет слева направо, так что сначала будет вычислено "obj != null" и если это выражение true, то все остальное в принципе не должно вычисляться.

Ну поэтому я и переспросил, как по-другому компилятор это может понять.

Просто неохото писать портянку || или && с повторением проверяемого значения.
Вобщем, уже понял, что проще делать типа такого
A is B or C or D
или для понятливости
A is (B or C or D)

Для понятливости надо избегать смешивания разных видов записей.
И чем проще выражение внутри if'а, тем лучше.


В твоем случае лучше было бы записать так:

bool allowedValue = enumValue is MyEnum.One or MyEnum.Two or MyEnum.Three;
if (obj != null || allowedValue)

Я бы избежал, но в одном паттерне, насколько я понял, нельзя использовать, скажем так, разные данные. Я попробовал сделать заменить это

if (obj != null || (enumValue is MyEnum.One or MyEnum.Two or MyEnum.Three))

на это

if (obj != null or (enumValue is MyEnum.One or MyEnum.Two or MyEnum.Three))

или даже так

if (obj is not null or

(enumValue is (MyEnum.One or MyEnum.Two or MyEnum.Three)))

- так нельзя. Ругается что-то типа, что obj и enumValue разные данные и их нельзя в одном паттерне использовать. Хотя по логике, оба паттерна "возвращают" bool - потому почему бы не использовать? Основная идея была - не повторять для каждого сравнения enumValue.

Паттерны вообще что-нибудь "возвращают"?

Просто неохото писать портянку

-----

А кто тебя заставляет писать портянку?

Да понятно, что можно доп. переменных навводить. Но ещё охота, чтобы было красиво.

доп. переменных навводить

-----

Нах?

У тебя список чего-то и переменная - делаешь список статическим для и проверяешь вхождение.

Ну либо два списка и ищешь один в другом...

Немного не так. Есть пара переменных, значения которых надо проверить. Одну - на null, вторую - на равенство некоторым значениям из перечисления. По сути, это либо портянка if-else, либо портянка из логических операторов с кучей скобок. Паттерновые конструкции позволяют сделать эти портянки поменьше чисто за счёт менее многословного синтаксиса. Только и всего. Ну а дополнительные переменные просто сделают портянку более читаемой, но всё равно оставят портянкой. Можно ещё со свичём поиграться и кортежами - все возможные комбинации загнать в кортежи и сделать их кейсами свича. Но при числе комбинаций больше 3 это уже само по себе та ещё портянка.

Щас прочитал, в чём отличие использования операторов от паттернов. Паттерны нельзя перегружать. Поэтому при их использовании с логикой, аналогичной операторной, тебе гарантируется, что ты не попадёшь на какую-нибудь незамеченную перегрузку оператора, которая сломает тебе код.

любишь "код с сахаром" (syntax shugar)?

почитай еще здесь, может будет интересно.

https://blog.ndepend.com/csharp9-new-keywords-for-pattern-...

но если перфоманс не критичен, то, конечно, следует выбрать более читабельный вариант. или что диктуют "правила кодирования", примятые в данной конторе (если имеются).

Щас попробовал поэкспериментировать со свичом и кортежами - плохо получается. Т.е. типа

switch (a, b, c)

(,,) => true,

(,,) => true,

(,,) => true,

_ => false,

где в скобках возможные сочетания переменных а, b, с. Но проблема возникает, если одна из переменных nullable, как я раньше писал в примерах, и нужно проверить, что она не null. Вот null можно, а литерала "not null" нет. Приходится тогда всю эту "таблицу" кортежей инвертировать и перебирать варианты с возвратом false, а всё остальное - true. Но если вариантов с false в разы больше, то получается совсем большая портянка. А вот паттерны "is, is not, and, or" делают это всё короче - буквально в одну строчку.

Ну там по сути перечисляется то, что у же давно в МСДН описано. Только добавить, как я выше написал, что новые паттерны не только заменяют некоторые операторы, но и предоставляют доступ именно к неперегруженной логике (в отличие от операторов, которые могут быть перегружены).

Ну и мой пример приведён:

A better example is the expression if(x is 1 or 2 or 3). It is more compact than if((x==1) || (x==2) || (x==3)) and makes sense.

Вобщем, эта штука удобна в том числе, когда надо проверить переменную на соответствие некоторым значениям перечисления.

Если много разных кейсов обработки переменной на разные значения перечисления - то лучше выражение switch -

weekDay switch =>

{

DaysOfWeek.Monday => ...,

DaysOfWeek.Tuesday => ...,

DaysOfWeek.Wednesday => ...,

...

_ =>

};

Если один кейс на меньшинство значений перечисления, то лучше паттерн "is (or...)" -

bool isHoliday = weekDay is (DaysOfWeek.Saturday or DaysOfWeek.Sunday);

Если один кейс на большинство значений перечисления, то лучше паттерн "is not (or...)" -

bool isWorkingDay = weekDay is not (DaysOfWeek.Saturday or DaysOfWeek.Sunday);

Всё это можно и операторами написать, конечно, но будет раза в полтора длинее и больше разных значков, тогда как выражения с паттернами в основном состоят из слов.

хз, один раз написал свою функцию In и не нарадуюсь

1. Ваша In это слишком небольшая надстройка над Contains. Да по сути просто повторяет её. Вы не добавляете никакой функциональности. Просто кусок внешнего кода - организация последовательности и проверка её на null - поместили в свою функцию. Да даже организация снаружи происходит - params это просто лишний промежуточный контейнер для уже существующего контейнера последовательности.

2. Сколько подобных функций надо написать на все случаи жизни?

3. Таскать потом эти функции в каждый проект, организовать свой репо, спросить начальство, можно ли свой репо в проект подключить и прочие оргвопросы.

4. Подобные функции уже как правило написаны более крутыми дядями, используются и поддерживаются широко сообществом - MoreLinq, например. С этим и вышеупомянутых оргвопросов меньше. Велосипеды - зло, и должны быть отринуты при первой же возможности.

А паттерны вот они - всегда доступны из коробки без внешних зависимостей и можно написать за несколько секунд по месту. "По месту" - значит можно подогнать под каждый конкретный случай с небольшими различиями, расширениями, в которые может не уложиться ваш метод. Т.е. ваш метод требует работу по организации последовательности, и лишь потом может включаться в работу сам. А в подобных моим случаях, если я уже с помощью тех же паттернов организовал нужную мне последовательность, то работа считай сделана - нет смысла вызывать специальный метод для проведения последней простейшей операции.

"По-научному" всё разложил. "Как диссер написал."

))

так и паттерны твои никакой функциональности не добавляют

У тебя твоя совковая прививка все ещё действует: если правильные пацаны сказали, то надо делать.

Моя функция из 3х строк работает наверное с версии .net 2.0 из 2005го года

А is…or в какой версии вышел и когда крупные конторы на него перейдут?

так и паттерны твои никакой функциональности не добавляют
У тебя твоя совковая прививка все ещё действует: если правильные пацаны сказали, то надо делать.

А вы что, авторитетов отрицаете? Нигилист, штоле?

Моя функция из 3х строк работает наверное с версии .net 2.0 из 2005го года
А is…or в какой версии вышел и когда крупные конторы на него перейдут?

А, нет - консерватор. Так в чём же дело? В кои-то веки старички модные фишечки продвигают.

Вроде, философия дотнета, начиная с версии 5 - всегда обновляться и использовать последние версии. Нет? А не как раньше - проект написан для дотнета 3.0 - всё, сидим на нём 10 лет и ничего не обновляем.

Сравните время поддержки дотнета до 5 версии и после. В первом случае в среднем - лет по 5, а во втором - пару лет. Если новые версии языка позволяют писать без нелепых костылей и портянок, почему бы не перейти на новые версии? У кого я сейчас проект делаю, держали всё до упора. А потом спешно-срочно переводим проект на дотнет коре, потом на 5 и т.д., спотыкаясь на пути обо всякие .NET Standard. А вот нихрена - куча либ в проекте либо хрен переведёшь, либо вообще аналогов не имеет. И проект проще переписать. Работает - не трожь, ага.. А потом просто берёт и перестаёт работать. Всё и сразу. Только выбросить остаётся.

а ты штоле философ?

Продать заказчику переход на новую версию дотнета могут не только лишь все.

Факт того, что Алексу нужно будет меньше слова писать, как аргумент не работает.

Мне сказали, что в моём проекте будут дальше развивать свой фреймворк на дата сетах. А EF им не нужен. Теперь все остальные нормальные фреймворки, типа того же Radzen, которые основаны на EF и нормальных интерфейсах типа IQueriable, нужно использовать с конвертерами для их кастомного фреймворка. А если бы юзали стандартно-современно, то всё бы из коробки заводилось. Тут волей-неволей начнёшь материться философствовать.

значит так нужно.

У дотнета может быть своя философия. Переход с одной технологии на другую - это всегда повышенные риски. Поэтому аргумент "это новый фремфорк, которым мы сможем заменить половину существующего кода" не является аргументом. Сможешь ли ты гарантировать, что переход пройдет безболезненно? Можешь ли ты гарантировать, что в результате перехода на новую технологию не появятся старые баги? И ладно если старые, а можешь ли ты гарантировать, что не появятся новые баги? Ну и самое важное для менеджмента - переход на новый фреймфорк стоит денег, можешь ли ты гарантировать, что пореход на новый фремворк окупится? И если хотябы на один из этих вопросов ты отвечаешь "нет", то есть еще один самый последний способ перехода на новый фреймворк - нахови хотябы одну причину, почему переход на новый фреймворк жизненно необходим. Если таких причин нет (потому что врядли найдется смельчак, который захочет что-то гарантировать :D), то никто не будет ничего менять :)

спасибо, что изложил мои мысли ☝️

Фреймворк один и тот же - Дотнет. То, что я фреймворком внутри него называю - это небольшая библиотека, остающаяся в рамках Дотнета. И дата сеты это уже всё - полностью устаревшая вещь. Это блин как сегодня машины новые делать даже не на ДВС, а на паровой тяге. Надо было МС отрубить поддержку этого старья в новых версиях Дотнета, а то они так и будут до скончания веков "развивать" этот перегной.

А чем тебя вдруг датасеты не устраивают?

Потому что с ними надо писать километры кода, потому что они дубовые (доступ к их данным - та ещё запутанная хрень), потому что они малопроизводительные и жрут много (если есть таблица с кучей полей - все они будут запрошены, а ты уже потом можешь запросить отдельные столбцы, но лишь из датасета, который уже в памяти), потому что они статичные, потому что современные либы (типа того же Радзена) их не поддерживают, потому что они старые, и многие их коллекции, типа RowCollection и ColumnCollection не поддерживают IEnumerable<T>, а лишь простой IEnumerable, а это значит, что LINQ по ним не работает без плясок (как минимум надо скастовать всю последовательность через Cast<T>, что возвращает искомый IEnumerable<T>), потому что... Мало?

зато как ты любишь можно записать что угодно любого типа, не создавая новый класс))

Фреймворк один и тот же - Дотнет.

Даже переход с одной версии дотнета на другую - это риски. И для этого перехода нужны железобетонные основания. Без аргументации необходимости перехода с отной версии на другую никто менять версию дотнета не будет.

То, что я фреймворком внутри него называю - это небольшая библиотека, остающаяся в рамках Дотнета.

Нет, Entity Framework - это полноценный фреймворк (включенный в другой фреймворк). Для перехода на EF нужны агрументы уровня "если не сделаем, то продукты хана и денег больше не будет". Как я уже говорил аргумент "с EF можно сделать все тоже самое, только проще" - вообще ни секунды не аргумент. Точнее это аргумент, но на стадии выбора технологии. В твоем случае стадия выбора технологии была пройдена 10-15 лет тому назад. Значит нужны аргументы "выживания", т.к. риски перехода с DataSet на EF просто огромные.

Надо было МС отрубить поддержку этого старья в новых версиях Дотнета, а то они так и будут до скончания веков "развивать" этот перегной.

В отличие о тебя, в MS знают как разрабатывается софт :) И как происходит переход с одной технологии на другую. Клиенты - крайне консервативны. Я уверен, что ты никогда не купишь новую машину только из-за того, что электроника в ней работает на новой операционной системе или из-за того, что там используется какой-то новоможный фреймворк (при этом все фичи остались без изменений). Точно также поступают все остальные клиенты - они платят за то, что имеет дополнительную стоимость. EF никакой дополнительной стоимости по сравнению с DataSet не имеет, поэтому ты врядли найдешь клиента, который будет готов оплатить этот переход. А это значит, что переход этот должен оплачивать сам разработчик. А зачем ему это делать, если все работает без этого перехода?

А зачем ему это делать, если все работает без этого перехода?

Зависит от того, сколько проект жить будет. Что будет делать разработчик, когда фреймворк, с короторого он вовремя не мигрировал, перестанет работать на Windows XXX а клиенты мигрируют на неё, потому что саппорт для XXX-1 прекращён?

В твоем случае стадия выбора технологии была пройдена 10-15 лет тому назад. Значит нужны аргументы "выживания", т.к. риски перехода с DataSet на EF просто огромные.

Нет, риски скорее оставания на дата сетах. И затрат с ними много - пишешь днями то, что на EF делается за час. Хотя бы и потому, что с EF уже работал, а с дата сетами - нет. И, как я раньше говорил, там не чистые дата сеты, а своя корявая надстройка в попытках написать универсальную обёртку надо всеми базами данных - т.е. велосипедный EF, только без типизированного возврата. Точнее, надстройка используется для построения запросов, а возврат данных - на дата сетах. Вобщем, химера из велосипедов и древностей. И они это "будут дальше развивать". И тот, кто с этим работает, должен их надстройку изучить (и дописать, т.к. там разных штук не хватает), и дата сеты, и к их глюкам привыкнуть.

А ещё у них есть формы без редактирования. Чисто отобразить данные. Так из коробки Радзен это делает на EF в несколько строчек. Я попробовал тестово сделать за час - всё работает. Но в репу пойдёт лишь вариант с датасетами и их надстройкой, над которым я уже вторую неделю корплю (в том числе из-за сложных и ограниченных пояснений, как у них эти надстройки работают, т.к. они сами их тоже не писали - досталось по наследству). Вот что значит вовремя не перейти со своих неподдерживаемых никем велосипедов на признанные распространённые вещи... Кстати, они задачу изначально ставили - обновить UI, но на старом беке. На очень старом беке. То, что это потребует кучу работы по подгону, им то ли в голову не пришло, то ли... Да всё это чушь. Просто хотят продлить занятость. Мне только нужно лавировать между всем этим - подыгрывать им, не улететь с работы и самому не выгореть.

Зависит от того, сколько проект жить будет. Что будет делать разработчик, когда фреймворк, с короторого он вовремя не мигрировал, перестанет работать на Windows XXX а клиенты мигрируют на неё, потому что саппорт для XXX-1 прекращён?

Это вопросы выживания проекта. И такие вещи не происходят внезапно. Все это планируемо. Мы, например, только сейчас перешли на .Net 4.8 с .Net 4.0 При этом не взяли более новый .Net, т.к. если какие-то несовместимости нашего кода и нового фреймворка. При этом всем понятно, что 4.8 - это не навсегда и нам придется устранять имеющуюся несовместимость. Эти работы запланированы и обязательно будут сделаны, т.к. это вопрос выживания продукта.

И затрат с ними много - пишешь днями то, что на EF делается за час.

Еще раз, ты готов взять на себя ответственность за переход на EF и гарантировать, что ты сможешь мигрировать весь имеющийся функционал не наделав при этом багов?

Хотя бы и потому, что с EF уже работал, а с дата сетами - нет.

Ты :) А остальные коллеги? Или на этим продуктом работаешь только ты?

Это вопросы выживания проекта. И такие вещи не происходят внезапно. Все это планируемо.

Фишка в том, что переходить на новую версию год-два после того, как она вышла дешевле всего. Уже есть опыт (можно найти много в сети) и этот опыт ещё не забыт. Можно нанять людей кто таким уже занимался и что-то помнит. Тут сейчас одна страховка переползает DB2 с z/OS на LUW (Linux, Unix, Windows) версию и огребает дикую кучу проблем. Фиг кого найдёшь. Куча народу, которые такую миграцию лет 10-15 назад сделали уже тупо на пенсии или начальствуют. Переходили хотя бы лет 5 назад, было бы в разы меньше геморроя.

Итого: если продукт собирается жить лет 10 (ну, в зависимости от платформы, в вебе не 10 а 2-3 года, имхо), НАДО переходить на новые версии всего, что в нём используется. Причём не "когда-нибудь потом".

P.S. Ещё одних знаю, они с 8й явы на 17 мигрируют. Отрыв башки. Раза в три по времени затратнее выходит чем 8 - 9 - 11 - 17 мигрировать (4 миграции)

Фиг кого найдёшь. Куча народу, которые такую миграцию лет 10-15 назад сделали уже тупо на пенсии или начальствуют. Переходили хотя бы лет 5 назад, было бы в разы меньше геморроя.

Вот то же самое и у меня. Только они нашли меня - мне деваться некуда, кроме как копаться в этом пока. В другом проекте тоже поучаствовал - сказали, что молодёжь из местных, у кого выбор получше моего, у них долго не задерживается по причине странного (неканоничного) использования, да ещё устаревших технологий. Т.е. мало того, что надо старьё знать, так ещё и врабатываться в особенности велосипедостроения местных гур, которым до зарезу надо было сделать не по канонам.

это значит, что LINQ по ним не работает без плясок

-----

В данном случае неработоспособность LINQa - чисто производная квалификации исполнителя.

И затрат с ними много - пишешь днями то, что на EF делается за час.

-----

Снова - квалификация.

В большинстве случаев будет объемнее, но быстрее по реализации именно на dataSet'ах.

Алекс, а ты вообще уже работал в каком-нить проекте на EF?
Прям в коммерческом, а не хелловорлд в НИИ.

Далее будет вопрос - а если работал, то какую роль выполнял? А то ведь можно просочиться в какой-нибудь ФААНГ, и там годами быдлокодить. Это апелляции к личности, а не к теме разговора.

А по теме, вы с дата сетами дублируете данные. Вы сначала загружаете в них всё, а потом их опрашиваете, создавая объекты с теми же данными, что и в датасетах. И чтобы иметь возможность опрашивать не только частично, но и полные (по столбцам) таблицы, вы всегда держите в датасетах полные таблицы. Тогда как в EF вы получаете эти объекты сразу и только те столбцы, что запросили. Я вообще не понимаю, как с датасетами работали в начале 2000-х, когда памяти на машинах было куда меньше. Оно же жрало как не в себя и ворочалось как черепаха, особенно на том древнем железе.

Опросить таблицу в дата сете - это неочевидная грёбаная простыня из вложенных циклов, т.к. данные в тиблице хранятся в виде двухмерного массива, но без удобного доступа по двум индексам одновременно. Или пара отдельных запросов LINQ to objects.

Из-за своей древности дата сеты не поддерживают нормально налловые значения. При обращении к свойству вы не знаете, может ли оно быть налл. Надо проверить кучку методов Is<PropertyName>Null - нет ли в них названия свойства, к которому вы хотите обратиться. Поняли, да? Каждый раз, чтобы прочитать свойство, надо открыть класс с ним и внимательно его изучить. А теперь представьте себе таблицы с десятками столбцов - удачи в блуждании по сгенеренным дата сетами классам для этих таблиц.

Снова - квалификация.
В большинстве случаев будет объемнее, но быстрее по реализации именно на dataSet'ах.

Какая, в задницу, квалификация позволит вам выкопать котлован лопатой быстрее, чем экскаватором? Будь вы хоть суперпрофессиональным землекопом семизначного уровня, но даже начинающий студент-экскаваторщик выполнит работу в разы быстрее. ))

чот ты какую-то херню несёшь

Что из базы данных выбрал, то и сохраняется в датасете

string queryString =
  "SELECT CustomerID, CompanyName FROM dbo.Customers";  
SqlDataAdapter adapter = new SqlDataAdapter(queryString, connection);  
  
DataSet customers = new DataSet();  
adapter.Fill(customers, "Customers");  

Опросить таблицу в дата сете - это неочевидная грёбаная простыня из вложенных циклов, т.к. данные в тиблице хранятся в виде двухмерного массива, но без удобного доступа по двум индексам одновременно.

до жего же ты ебанутый

Покажи мне как ты к коллекции из EF обратишься по двум индексам, чтобы взять второе свойство третьей строки?

в наших старых проектах мы на null проверяли вот так. Что тебе мешает?

foreach(DataRow row in table.Rows)
{
    object value = row["ColumnName"];
    if (value == DBNull.Value)
        // do something
    else
        // do something else
}

Какая, в задницу, квалификация

------

Именно в упомянутом месте и лежит твоя квалификация.

выкопать котлован лопатой быстрее

------

Вот Я так и понимаю - незачем хвататься за лопату при наличии многократно проверенного в работе экскаватора.

И, кстати, от DataSet'а ты используешь от силы 2-3% доступной функциональности. Когда изучишь хотя бы до 50-60% - будет об чем поговорить. И это... LINQ на том же уровне нужен...

т.к. данные в тиблице хранятся в виде двухмерного массива

------

интерфейсная частьтам в виде RB-дерева... а представление в виде двухмерного массива это винда и стоит это почти половину наличной памяти.

Мат.часть учи...

представьте себе таблицы с десятками столбцов

-----

представил - строготипизированные таблицы.

и никаких проблем.

Единственное - мат.часть учить надо-ть...

object value = row["ColumnName"]; 
if (value == DBNull.Value)

А чего так сложно?

У меня вроде как всегда было

row.ColumnName.IsNull

А как и с чем оно сравнивается - закопано в типизированной таблице.

через функцию Field<> вообще сразу получаешь nullable тип

using (DataTable dtSources = SQLHelper.Fetch(sQuery))
{
    foreach (DataRow drSource in dtSources.Rows)
    {
        int? iID = drSource.Field<int?>("ID");
    }
}

ну и повторю вопрос: есть ли у тебя боевой опыт с EF или только пару хелловорлдов написал?

Он не знает где и сколько ему придется мудохаться с EF...

Я изначально тоже радовался... Оказалось - зря - дохрена чего просто невозможно сделать через EF. Но, да. на первом этапе все неплохо компактикуется... а потом начинаются проблемы, решать которые сложнее, чем в датасетах...

взять второе свойство третьей строки?

------

А мне, плс, поменять его значение и после 10 секунд простоя записать в обратно в базу в одном баче с остальными изменениями...

Покажи мне как ты к коллекции из EF обратишься по двум индексам, чтобы взять второе свойство третьей строки?

А в EF и не надо по индексам:

Skip(2).Take(1).<второе свойство>

Теперь так же коротко в датасетах сделайте. Хоть с индексами, хоть без. Только у меня в EF эта строчка сразу и запрос выполняет, и я считываю нужное свойство. А в датасетах надо сначала выполнить запрос, а потом считать датасет.

в наших старых проектах мы на null проверяли вот так. Что тебе мешает?

foreach(DataRow row in table.Rows)
{
    object value = row["ColumnName"];
    if (value == DBNull.Value)
        // do something
    else
        // do something else
}

Наверное, 4-5 строк кода на каждое свойство, вместо одной?

В принципе, ничего не мешает копать котлован лопатой вместо экскаватора.

Он не знает где и сколько ему придется мудохаться с EF...

Я изначально тоже радовался... Оказалось - зря - дохрена чего просто невозможно сделать через EF. Но, да. на первом этапе все неплохо компактикуется... а потом начинаются проблемы, решать которые сложнее, чем в датасетах...

Проблемы в чём? В скорости и неоптимальных запросах? В узких местах пишете свой оптимальный запрос "вручную". Нет универсального инструмента, подходящего всегда. Но есть подходящие в подавляющем большинстве случаев.

Вы как те придурки, кто жалуется на производительность C# после работы с низкоуровневыми оптимизациями - вот мол вас Сишарп тормозной. Ну так в узких местах вставляй свои оптимизации, а в остальных - пользуйся удобным Шарпом.

взять второе свойство третьей строки?

------

А мне, плс, поменять его значение и после 10 секунд простоя записать в обратно в базу в одном баче с остальными изменениями...

И ещё добавить, что все 100% ваших запросов только из таких условий и состоят. Тогда да - EF можно закапывать (для вас лично).

А в EF и не надо по индексам:

тут надо, тут не надо.

Алёша крутит жопой.

Наверное, 4-5 строк кода на каждое свойство, вместо одной?

где там у тебя на EF одна строчка, болезный?

только из таких условий

-----

Это совершенно обычные "условия"... а вот задача - вне возможностей EF.

И тому, и тому отвечу, когда оба ответят на остальные мои аргументы, а не будут педалировать только один-два своих.

обидели мышку, написали в норку 😀

Скорее лужу прогазифицировали. ))