C# - У чего приоритет больше - у операторов или паттернов?
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 назад, было бы в разы меньше геморроя.
Вот то же самое и у меня. Только они нашли меня - мне деваться некуда, кроме как копаться в этом пока. В другом проекте тоже поучаствовал - сказали, что молодёжь из местных, у кого выбор получше моего, у них долго не задерживается по причине странного (неканоничного) использования, да ещё устаревших технологий. Т.е. мало того, что надо старьё знать, так ещё и врабатываться в особенности велосипедостроения местных гур, которым до зарезу надо было сделать не по канонам.
