Да и пример reader.GetString(0) не совсем корректен, ведь что если у нас там INT NULLABLE? Есть метод GetFieldValue<T>(и даже async-вариант), но я не проверял, умеет ли он в Nullable<T>.
К тому же, reader.GetString возвращает string, а DBNull.Value — чтож, DbNull, так что даже этот вариант не сработает — эти типы нельзя между собой сравнивать.
и при этом равно 0 описания того, зачем это всё нужно. вроде как статья для непрошаренных, но как я был непрошаренным, так и остался, только на красивые слова посмотрел.
В этом коде класс C не должен откомпилироваться, потому что у него нет конструктора с параметрами int x, int y, а вот класс B откомпилируется без ошибок.
В C# класс С тоже не откомпилируется, он тоже обязан вызвать базовый конструктор через : base(..).
Возможен ещё один вариант: если в наследнике не перекрыт виртуальный конструктор предка, компилятор автоматически перекрывает его
Я не вижу ни одного плюса такой непонятной реализации.
А вот если у нас будут метаклассы, то код с неправильными параметрами просто не откомпилируется.
Все, что от C# требуется, это добавить Method<T>() where T : class. new (int, string), но мелкомягкие уже что-то вроде "сложно и не нужно" писали на этот счет.
Ну и стоит заметить что рефлексия это лишь инструмент для обучения, если нужно именно быстро и динамически создавать строго-типизированные классы, можно воспользоваться скомпилированными ExpressionTrees или даже прямой IL генерацией.
и самое главное, зачем вообще все мапперы нужны в приципе — это expression-based маппинг, шобы с БД тянуть инфу было удобненько, поэтому нужно обязательно это допилить
понятие правильности субъективно. но это еще не все, понятие правильности в контексте конкретной БД зависит только от конфигурации этой БД, а именно от сгенерированного этой самой БД плана выполнения запроса.
как думаете, существует ли query провайдер, умеющий собирать с БД несколько разных планов, для каждого конкретного linq-выражения, генерируя различные варианты sql запроса, а потом еще и определять правильность каждого?
это вопрос про настройку большого старого проекта. да, здесь единственный 100% точный вариант — это просмотреть код, чтобы знать, что nullable, а что нет. (хотя по хорошему уже бы иметь какие-то маркеры, комментарии там, или атрибуты, чтобы декоративно было все видно).
но если вы не хотите тратить время на подобную модернизацию большого и старого проекта, тогда зачем вы написали этот коммент?
Но где написано, что это противоречит? :)
норм, vk api опрашивать — самое оно, его как мейл купил, так там через день 500 стало падать
Не плюйтесь на базовую обертку работы с БД.
Примитивных типов не так много, всегда можно сделать свой generic extension, который будет работать именно так, как вам надо.
Да и пример
reader.GetString(0)не совсем корректен, ведь что если у нас тамINT NULLABLE? Есть методGetFieldValue<T>(и даже async-вариант), но я не проверял, умеет ли он вNullable<T>.К тому же,
reader.GetStringвозвращаетstring, аDBNull.Value— чтож,DbNull, так что даже этот вариант не сработает — эти типы нельзя между собой сравнивать.ни один новичок не знает, как работает дотнет под капотом (когда узнает — становится мидлом :) ), с их стороны это вполне разумно и логично.
Стоит отметить, что всё сильно меняется, если нужно использовать IO и асинхронность. Вот уже вторая часть статьи, а ни одного
asyncа я не увидел.ну а шош поделать то
и при этом равно 0 описания того, зачем это всё нужно. вроде как статья для непрошаренных, но как я был непрошаренным, так и остался, только на красивые слова посмотрел.
Отлично написано, очень много полезной информации, спасибо автор!
я конечно не претендую на звание про, но они ищут кодеров которые пишут нечитаемый говнокод или же все таки простую, понятную и сложную архитектуру?)
я просто использую
JSON.ToObject<T>(data), версия 2.2.4, пакет вроде тот же.странно, у меня fastJSON работает где то в 20 раз быстрее Newtonsoft (на десериализацию). но спасибо за тесты.
А теперь сравните с fastJSON, пожалуйста.
В C# класс С тоже не откомпилируется, он тоже обязан вызвать базовый конструктор через
: base(..).Я не вижу ни одного плюса такой непонятной реализации.
Все, что от C# требуется, это добавить
Method<T>() where T : class. new (int, string), но мелкомягкие уже что-то вроде "сложно и не нужно" писали на этот счет.Ну и стоит заметить что рефлексия это лишь инструмент для обучения, если нужно именно быстро и динамически создавать строго-типизированные классы, можно воспользоваться скомпилированными ExpressionTrees или даже прямой IL генерацией.
я не особо в курсе, когда там уже можно будет полноценно писать на шарпе под браузер?
и самое главное, зачем вообще все мапперы нужны в приципе — это expression-based маппинг, шобы с БД тянуть инфу было удобненько, поэтому нужно обязательно это допилить
понятие правильности субъективно. но это еще не все, понятие правильности в контексте конкретной БД зависит только от конфигурации этой БД, а именно от сгенерированного этой самой БД плана выполнения запроса.
как думаете, существует ли query провайдер, умеющий собирать с БД несколько разных планов, для каждого конкретного linq-выражения, генерируя различные варианты sql запроса, а потом еще и определять правильность каждого?
а зачем нам лочиться на приватном объекте чужого класса?
но если выбирать между старыми проектами и новыми, то выбор очевиден
это вопрос про настройку большого старого проекта. да, здесь единственный 100% точный вариант — это просмотреть код, чтобы знать, что nullable, а что нет. (хотя по хорошему уже бы иметь какие-то маркеры, комментарии там, или атрибуты, чтобы декоративно было все видно).
но если вы не хотите тратить время на подобную модернизацию большого и старого проекта, тогда зачем вы написали этот коммент?