Запоздалый перекот треда о лучшем языка на планете.
1. Ресурсы:
— https://dotnet.microsoft.com/learn
— https://ru.stackoverflow.com/a/416585/422180
— https://metanit.com
— https://professorweb.ru
2. С# для веб
— https://docs.microsoft.com/ru-ru/aspnet/core
3. C# для десктопа
— https://docs.microsoft.com/ru-ru/dotnet/desktop
4. С# для игр
— https://ru.stackoverflow.com/a/609901/422180
5. С# для мобильной разработки
— https://docs.microsoft.com/ru-ru/dotnet/maui
6. Годные ютуб-каналы
— https://www.youtube.com/c/CODEBLOG
— https://www.youtube.com/c/AndreyShyrokoriadov
— https://www.youtube.com/c/DevJungles
— https://www.youtube.com/user/Shmachilin
Шапка: https://pastebin.com/HT7Hi6FD
Прошлый тред: >>3218902 (OP)
По сути, в дотнете две книжки, которые стоит прочитать. Там объясняется как вот это вот всё работает.
Документация в основном на сайте Microsoft, читай её на английском (я ни в коем случае не выёбываюсь, просто там автоперевод жопой на русский язык)
Если хочется кратко и быстро, читай https://professorweb.ru/ и https://metanit.com/
Тут есть такие как я? Или тут только мальчики "решил написать первую программу на сишарп" и петушня из java-загона?
У меня в резюме написано просто: C# MSSQL. Поэтому меня никто не берет на работу, ведь хрюшам надо типа работал с itextsharp 2.0, itextsharp 2.1, itextsharp 2.2, itext 5.5, itext 5.5.3, тогда сразу видно кокой опытный мущина.
Это как-то связано с тем, что дотнет фреймворков два, и везде нахваливают только дотнет кор, но про .net framework 4.5.2 НИ СЛОВА?
Анон, Binding Redirect помнишь? А что глазки отводишь? А как же кроссплатформенность под Windows и ад в Global Assembly Cache ?
А как ты свой ASPNET собираешься обновлять до дотнеткоровского?
Вот и два треда они как бы символизируют это.
Дотнеткор - это из мира микропенисов, фулстека, крипто копро финтех аи стартапов и поиска работы раз в полгода. Негоже благородным господам нырять в этот чан с дерьмом. Продуктовые компании как сидели на классике, так и продолжают, максимум обновятся до 4.8, но это не точно. Если системе 15+ лет, никто не будет ее переписывать под очередную модную хуйню.
Ну как бы да и как бы нет.
Если системе 15 лет, то она, наверное, хочет ещё 15 лет работать.
После новости о том, что netstandard-2.1 будет несовместим с классическим фреймворком, стало ясно, что это дорога в одну сторону и надо переползать на дотнеткор.
Моё мнение - все там будем. Серверные приложения - прямо обязательно перетаскивать надо. Перетаскивать сложно, но, если делать маленькими шагами и не останавливаться - то это гарантированно приводит к успеху.
Но главное - делать.
Десктопные приложения, WPF - тут наверное тупик, пусть ебутся с о старьём
Я видел систему, которая написана на дотнете 1.1 и собирается в студии 2003. До сих пор работает и приносит бабки, туда даже иногда дописывают новые фичи. Ценность новых фреймворков немного преувеличена.
Тут надо не переходить на очередной нет-стандарт-кор-ультимейт, а выкатываться из этого цирка. После ухода Гейтса микрософт покатился в пизду, в 2024 дотнет неиронично пытается конкурировать с нодежс в помойных стартапах, а ведь когда-то были планы подвинуть джаву в энтерпрайзе.
>когда-то были планы подвинуть джаву в энтерпрайзе.
так говоришь, как будто не подвинули
> неиронично пытается конкурировать с нодежс
эээ, ты еблан?
>> так говоришь, как будто не подвинули
А в чем подвинули? ржава даже подвинула Сишку на тиобе, в то время как шапр падает (хоть этот индекс и хуита собачья, но на безрыбье тоже можно смотреть)
Плюс политика мелкомягких насильно тащить всех в свой азур, начинает подбешивать
Хочу сгенерить сервис и месседжи из .proto файла, по гайду скачал зависимости, закинул куда надо (пик 1).
При этом в файл генерации не видит импорты (пик 2). Что я могу делать не так?
Как вы храните изображения в бд? Asp.net mvc ef6
Я перевел base64 картинку в byte[] ImageData поле модели. Дальше хз как отобразить во view. У меня будет много изображений, поэтому 1 картинку во вьюбег не получится, тем более что мне надо вместе с определенным контентом картинки добавлять
Их не хранят в бд. Хранят ссылки на них. Ссылки, либо путь к файлу, хэш.
Пусть пользователь загружает в любое другое хранилище, а ты в БД ссылки положи.
> Дальше хз как отобразить во view
Если ты уже решил в БД класть, то ты всегда можешь возвращать что-нибудь типо...
[HttpGet]
[Route("files/uploads/{fileName}")]
public async Task<FileStreamResult> DownloadFile(string fileName)
{
Stream stream = await this._files.DownloadUploadedFile(fileName);
var response = File(stream, "image/jpeg");
return response;
}
А шо?
Никто же не говорит что надо хеш у изображений пересчитывать каждый раз. Файл изображения переименовывается в hash и ищется файл по имени-хешу. Зато дупликаты не нужно хранить.
мимо
Или боишься колизий? Очень очень очень маловероятно если хороший хеш
Не понял, а как это во вью обработать. Я обычно ивент накладываю на какое-то действие чтобы пользователь вызвал аджаксом действие контроллера
Я бы отталкивался от того, что на серверной стороне два метода, положить файл и загрузить файл.
А всё остальное я бы делегировал коду, который в браузере запускается.
>Зато дупликаты не нужно хранить.
Пожалуйста, скажи, что ты сначала проверяешь хеши на совпадение, и затем побайтово сравниваешь вероятные дубликаты? Напоминаю, что коллизии либо есть, либо их нет. Третьего не дано.
Всмысле хэш сумма файла для целостности, чтобы при загрузке файла проверять это, если требуется.
Боится, что произойдёт событие, вероятность которого 1/2^160.
Я так понял, ты как-то по тупому использовал хеши не по назначению, нихуя не работало и с порванным очком теперь всем рассказываешь, какие они говно без задач?
Я сам раньше мечтал писать системщину, но в России с плюсами никуда не брали особо, поработал немного в игровой студии стажёром плюсовиком, потом вкатился на C#, а там оказалось ещё хуже, пару лет поработал джун->миддл разрабом, теперь же довольный сижу на JS. Всем советую. Куча вакансий, работа вообще простая и приятная, современные технологии и отсутствие легаси.
Подумай, стоит ли оно того? Лучше вкатывайся в NodeJS, как я сделал. Вакансий гораздо больше, вкат очень лёгкий, work/life баланс лучше, а сложности меньше. И да, совет ньюфагам, не слушайте местных красноглазиков, упорно зазывающих в свою EnterprisePoopShittingDesignatedFactoryClass
Есть у кого успешный опыт релокации?
Что там более востребовано бекенд или десктоп?
Ноль. Дотнет умирает, это очевидно. Вакансии есть только в нищебродские стартапы, где ты одной рукой правишь разметку, другой настраиваешь пайплайны в ажуре ебаном, ебашишь как проклятый без процессов по системе "да тут на 5 минут переделать ну че ты", через полгода снова ищешь работу, конкуррируя со стадом паджитов. Есть еще немного вакансий в копролегаси на всяких winforms и jquery, но там требуют ворк пермит и знание местного языка, нет пути. Релокацию никто делать не будет. Дотнет - это новый делфи, никому нахуй не нужен.
>js
>достаточно выучить язык
Это тот самый язык, где всяких исключений и странного поведения больше чем операторов в самом языке? Нахуй, сам такое говно ешь.
Ещё у Сишарпа в российских фирмах есть странный red flag - какая-то часть проектов даже не использует git и SCRUM-Agile разработку. Тупо как в нулевые сайты ебошут. Но это уже в основном легаси или какая-нибудь попильная контора.
На какой язык тогда переходить, если в приоритете релокация?
Ну и что же я неправильно понял?
Мне кажется, всё я правильно понял.
На девопс. Мартышки высрали тисячи микросервисов, а теперь прод разваливается на части при малейшем движении.
>какая-то часть проектов даже не использует git
Ну это кстати не так уж и страшно. В основном такое осталось там где совсем легаси и сидят деды-пердеды, для которых проще в zip-папочки по датам все паковать. Если гита нет, то поломать их и внедрить его достаточно просто. Но лучше вообще не работать на таких проектах.
Меня гораздо больше напрягает ситуация, что сейчас везде пытаются пропихнуть "модный" Trunk-Based-Development ("ебашь все в мастер" по простому), причем в проектах совсем не предназначенных для такого.
Как будто что-то плохое. Сделал свою ветку от мастера, закончил таску, померджил обратно через реквест. Нет никакой путаницы со 100500 веток.
Так на мастер во всех нормальных проектах завязана автоматическая сборка проекта. Обновляется мастер - автоматически ребилдится проект. Смерджил ты такой таску прямо в мастер, без тестов, а там какой-то баг, который лишил компанию потенциальных заказчиков.
>Подумай, стоит ли оно того? Лучше вкатывайся в NodeJS, как я сделал.
Да, конечно стоит того. А ты пиши на ноде, пиши.
Это только в веб петушении, где комиты сами деплоятся на прод и где шизы соревнуются, у кого быстрее. Там своя ебанутая атмосфера с дежурствами по ночам. В продукте билд сначала долго и нудно тестируется вдоль и поперек, лишь потом попадает к кастомеру.
А это хороший хеш или не очень?
Я вот ебусь с пятилетним легаси, где какие-то долбоёбы решили айдишники объектам вот таким образом генерировать.
Пиздец блядь, мне как будто детский мат поставили, сверху на доску насрали и скрылись в неизвестном направлении
Для ин-мемори хеш-таблицы пойдёт. Для хранения картинок - нет.
PS. Офф дока по Breaking Changes ущербная, хз как либу портировать
https://dusted.codes/how-fast-is-really-aspnet-core
Да эти микробенчмарки нахуй не сдались.
Судя по статье, дотнет действительно достаточно быстрый, чтобы вообще не париться о производительности при его выборе. Берёшь дотнет - у тебя всё хорошо.
После райдера больновато, но привыкаешь быстро.
Да и последнее время райдер стал жрать память как бледина (8-14 гигабайт у меня) и прогревать помещение.
Jet brains гаденькая компания, не заботится об углеродном следе
У них хуй который они могут класть на санкционные требования толще чем у жидбрейнсов.
Там целая страница в опциях для настройки шрифтов. Поставь какие нужно и работай. Хоть джетбрейновские.
>Судя по статье, дотнет действительно достаточно быстрый, чтобы вообще не париться о производительности при его выборе. Берёшь дотнет - у тебя всё хорошо.
Как раз таки наоборот, мягкие там потели, делали оптимизацию, выпили все, даже асп.нет, шаблонизатор, при том умудрились получение даты раз в 300 запросов сделать, в общем по максимуму все обтесали и все равно получилось медленнее чем джавы, у которой и шаблонизатор есть и роутинг и полноценный сервер, то есть, никаких манипуляций.
Я, кстати, не понимаю почему так все печально. У шарпов вроде и валуе-типы есть со структурами и ансейв и по дефолту методы не виртуальные, а жаба берет просто еб..т
Еще тесты переехали на азур и неожиданно назание за накрутки обошли всех кроме тех шарп тестов. Они до сих пор с тем позорам висят там. И, кстати, та картинка с главной страницы, это картинка на те буллшит тесты, лол.
Чел, да кому не поебать? Тем более на синтетические тесты?
В реальности ты просто говоришь кабану докупить очередной сервак и ебашишь коды дальше.
не, я пробовал ставить тот, который в вскод, всё равно рендер шрифтов какой-то другой
да и каждый раз применять изменения и лезть в меню, чтобы посмотреть на шрифт не очень хочется, присмене в опциях он сам не меняется до нажатия "ок", а просто кнопки применить нету
КРАСНЫЙ КОД
КРАСНЫЙ КОД
ОДНИ СИНТЕТИЧЕСКИЕ ТЕСТЫ ОПРОВЕРГАЮТ ДРУГИЕ
Зачем защищать барена, если он обосрался? В открытом мире опенсорса на тебя смотрят тысячи глаз, считать всех за дебилов уже не так легко. Пускай учиться, старается, мир кроссплатформы жесток и требователен, ничего научится.
Сами шарпы от этого хуже не стали, так что не треггерись.
Ну так еще проще. Берешь и сам себе дополнительный сервак покупаешь.
Ты бросил говно на вентилятор, но забыл его включить.
Есть стойкое мнение что будущее за wasi и по ощущением на передке технологии сейчас шарпы и расты. JS с отсутствием нормальной целочисленной математики и кучей подводных камней просто утонет, а вместе с ним потянет ts (или им придется ломать совместимость с js, что они и сделают).
Так что наслаждайся последними деньками круда на жс.
Ты про Tiered compilation?
https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#tiered-compilation
Я хз про джаву, т.к. там много jit'ов, но я что-то где-то слышал, что там вроде как интерпретатор, а потом jit'ится код. У .NET вроде только: минимальная оптимизация (Tier0) и полная оптимизация (Tier1) (+ там ещё PGO и т.д.), ну и у mono есть интерпретатор и jiterpreter. Кто лучше знает - поясните.
И ещё:
Why not ‘Interpreted’?
https://mattwarren.org/2017/12/15/How-does-.NET-JIT-a-method-and-Tiered-Compilation/
https://github.com/dotnet/coreclr/pull/10478#issuecomment-289412414
https://github.com/dotnet/runtime/tree/main/docs/design/security
>Security design doc for Dictionary<TKey, TValue> and HashSet<T>
>Security design doc for System.HashCode
>Security design doc for System.StringComparer
Вот тут ещё есть красивая диаграмма с TC и PGO:
https://github.com/dotnet/runtime/blob/main/docs/design/features/DynamicPgo-InstrumentedTiers.md
>Dynamic PGO: Instrumented Tiers
Почему народ не радуется халяве? Или асп.нет там не реализуешь?
>В шарпах есть прогрев как в джаве (компилит в jit на 10к итерациях функции)?
а можно как-то пропустить джит-конпеляцию? Можешь как-то удачнее свою мысль выразить?
От них массовый отток пользователей идёт, так как богомерзкий джет-брейнс говнит. Идея и райдер очень медленное говно последнее время, жрёт под 7-9 гигабайт памяти на средних проектах.
Надеюсь, ждет-брейнс нахуй схлопнется
VS давно по функциональности сравнялась, поэтому продавать райдер, когда есть бесплатная VS - это ну такое себе.
Только богомерзкий джет брейнс мог до такого догадаться?
Прога тупо ищет конец массива char (символ '\0'). Хотел посмотреть, что будет если не итерировать указатель каждый цикл, а делать это с большим шагом.
Левая прога и правая с 1-им ifом = за 175к тактов.
Правая с 2-мя if-ами = 123к тактов.
с 4-мя = 85к
с 8-мю = 55к
далее скорость заметно не растет.
Я из джавы, там по дефолту интерпретатор байткода, но если функция вызывалась ~10К раз срабатывает jit компилятор хотспот (если он есть в вашей опенждк). Этот процесс называют "прогрев джавы".
Я захотел узнать что в шарпах, есть ли прогрев (уже узнал).
Смотри ассембленый выход, там на 03 может твориться неочевидные вещи.
https://godbolt.org/
Я не видел такого термина в доках, сам момент прогрева и горячего кода есть, но отличается от хотспота. Так что есть, но со сноской.
Ты бы ещё у JSников спросил.
Я не эксперт, точно не помню, давно читал и читал жопой. Кто может - поправьте.
Мне кажется что здесь замешаны большинство "трюков" связанных с тем как выполняется код на CPU: branch prediction, out of order execution, speculative execution, etc.
Первый вариант хоть и имеет 1 бранч, он будет always taken (почти всегда), т.е. всегда возвращение к предыдущим инструкциям. Во 2-ом варианте на одну итерацию 8 бранчей вперед, которые never taken (почти всегда) и 1 бранч назад который always taken. Эти always taken, never taken и т.д. относятся к предсказателю переходов, т.е. предсказатель видит что этот переход never taken, что позволяет ему предположить что и сейчас он будет never taken (т.е. не будет перехода), так что ЦП продолжит спекулятивное выполнение инструкций. Если оказалось ("реальное" выполнение кода дошло до бранча) что в этот раз предсказатель переходов ошибся, то конвейеру ЦП нужно откатить все изменения/расчёты связанные с неправильным выбором перехода, что может быть довольно дорого. К тому же вроде как переходы назад дороже чем переходы вперёд. Так же чем современнее процессор, тем менее дорогим становится отсутствие перехода который предсказатель переходов предсказал правильно.
Компилятор тоже может перетасовать код так, что наиболее вероятные бранчи будут идти последовательно и не потребуют переходов.
Компиляторы могут векторизировать циклы (но не в это случае), что тоже может давать прирост.
Есть ещё зависимости между инструкциями (и данными/результатами) которые мешают out of order execution (как пример "a = b + c; d = e + a;" - результат "d" зависит от результата "a", "a = b + c; d = e + f;" - "a" и "d" независимы и могут выполняться параллельно).
Вообще есть много статей/литературы на эти темы.
А, ну если ты серьезно интересовался, то:
В джаве сначала компилится в байткод (интерпретатор), а в jit переводит при ~10.000 итераций функций.
В шарпах сразу в jit нулевого тира (облегченный вариант), а после 30 итераций (не тысяч) в более оптимизированный тир 1 с рантайм оптимизацией.
В шарпах это выглядит лучше, но хотспод тоже очень хорош. Непрогретая жаба (или без хотспота) - кусок говна.
Язык развивается, мс потеет, шарпист доволен, имидж растет
Джава протухла, технологии раз в 15 лет, с мобильных выпинули, доживает на кобол-монолитах последние века.
1. Есть ли на современный решарпер взлом?
2. Если нет, то какими плагинами можно его заменить?
Он бесплатный теперь. Весь ребус теперь только в том, чтобы суметь его скачать.
А, сорян в глаза ебусь. Ты про решарпер, а не райдер. Тогда не знаю.
Я сейчас пользуюсь проплаченным райдером с оффлайн-лицензией и зайбанеными сервера жетбрейнса через хостс на время, но в новых реалиях будет дебилизмом проплачивать лицензию.
Теоретически можно использовать бесплатную комьюнити-версию, но за её использование в коммерческой разработке теоретически анальнику могут устроить пикрил, так как телеметрии там до жопы и стучит она обо всем и, вероятно, де-факто использует код для обучения жетбрейновских сеток.
Поэтому хочу прикрыть жопу и использовать VS2022 на работе, обмазанный плагинами, максимально приближенный по функционалу к райдеру. Ну или хотя бы спиздить решарпер, там всей этой телеметрии не будет так как это просто плагин для студии.
Вообще, мне кажется идея платных IDE умерла так как бесплатные и опенсорсные инструменты достигли паритета с жетбрейновским говном, и они теперь не знают где им приткнуться.
>так как телеметрии там до жопы и стучит она обо всем
Как ты себе это представляешь? Ты думаешь однажды тебе придет письмо, что мол "наша IDE тут нам настучала, что вы работаете над коммерческим продуктом ООО Кабаныч-лимитед" - плотите. Так?
Конечно если ты где-нибудь в Европе (особенно в Германии), то может такое и может произойти. Они там ебанутые даже за торренты людей подтягивают. Но по моему в нынешнее время в там вообще нечего делать.
Алсо, есть вот такое мнение.
https://law.stackexchange.com/questions/1691/intellij-idea-community-edition-commercial-proprietary-software-developing
НУ и до кучи. Я работаю в санкционном банке. Там разрабам ставят лицензионную VS Enterprise Edition. Я х.з. как они ключи достают, но проблем у них с этим явно нет.
>Я работаю в санкционном банке. Там разрабам ставят лицензионную VS Enterprise Edition
Банк это олигарх, а отдельный разработчик это народ. Разные вещи, не путай. Олигархи не могут идти против олигархов, не важно что американские олигархи устроили войну против русских олигархов, русские всё равно не могут идти против них, даже против своего врага, не могут разрешить пиратство. Если разрешить пиратить, народ будет пиратить не только вражеских олигархов, но и своих, то есть подрыв олигархической системы не выгоден никаким олигархам, независимо от их междоусобчиков, так что олегархи всегда друг за друга и будут соблюдать лицензионные правила в любых условиях.
Таким образом, олигархи между собой союзники, а враг у них - народ, простые люди, так что эти санкции бьют именно по простым людям, и соответственно тактика поведения простого человека должна отличаться от тактики олигарха - его врага. Там где олигархи соблюдают лицензии по любому ((где-то)) получая ключи, там простой человек должен всё пиратить напропалую, потому что играть по правилам своего врага это проигрыш по умолчанию.
Ты уже нарушаешь закон, технически нет разницы что ты сделал затычку в host или же поставил китайскую затычку от сильного брата. Лицензии у тебя уже нет.
Не, пока она есть (на сайте всё на месте), просто я иду под радарами жетбрейнса и они не могут её отобрать ввиду того что их система не отметила меня как хитреца. Т.е. де-факто EULA уже нарушен за нарушения экспортного контроля, но технически лицензия ещё есть. Притянуть за это в суд будет крайне сложно. Но проплачивать дальше, я конечно, не стану (лицензия у меня до осени 2025 года), так что буду потихоньку мигрировать на что-нибудь другое, начну с Вебшторма->VSCode и попробую снова студию (ушёл с неё в 2020 году потому что она была невыносимым лагающим говном с перегруженным интерфейсом).
Пусть юристы поясняют, с уходом из рынка они вообще могут тебе что-то предъявить? От чьего лица это тогда будет?
В теории, если нет юрлица, то претензии в нашей юрисдикции подать некому. Но на пиратский софт вполне может залупнуться какая-нибудь проверка из силовичковых, и плевать им будет на здравый смысл - палки важней.
>Пусть юристы поясняют, с уходом из рынка они вообще могут тебе что-то предъявить?
Как ты себе представляешь такую юридическую предъяву?
Ну т.е. в теории если твой комп попал под рейд отдела К и там нашли ломаные (именно ломаные) программы или средства их взлома, то ты можешь попасть. Даже без наличия юридически правообладателя в стране.
А вот за коммьюнити версию, что тебе могут предъявить?
Да, ты прав. Ну тогда нафига вообще привыкать к этим IDE.
Ломает ровно так же когда вскод настроил и потом сел на что-то другое. Тоже везде что-то не то, что-то не там.
>Ну тогда нафига вообще привыкать к этим IDE.
>Ломает ровно так же когда вскод настроил и потом сел на что-то другое. Тоже везде что-то не то, что-то не там.
Ну так это проблема не только IDE, а в принципе любого рабочего софта как такового. Причем не только при смене одного на другое, а часто просто при переходе на новую версию. Как минимум раз в 2...3 года приходится ебаться с настройками и крыть хуями разрабов/дизайнеров которые решили в очередной раз переделать UI.
Так что тут только смириться.
Она охуенная
Ну, блядь, это же поле, а в сишарпе все поля _плинтуются
Про то, что "настрой сам" хрюкать не надо. Я не настраиваю свой единственно правильньный код стайл чтобы не ебать мозги себе и окружающим, а если надо помандеть - хожу в двач
Так это не поля, лол. Это аргументы конструктора.
А вообще, я отказался такого вот синтаксиса, т.к. на старый код ложится херово, плюс - нельзя нормальную валидацию в конструкторе провести.
>Ну, блядь, это же поле, а в сишарпе все поля _плинтуются
И главное зачем, неужели нет подсветки свойств класса и локальных переменных?
>Так это не поля, лол. Это аргументы конструктора.
Вот ты видишь их как аргументы конструктора. А я вижу вызов метода с полями класса. Противоречивое это дело. Поэтому и именование по пизде пошло
Сорян, я тупой. Не понял сразу, что это класс с primary consructor. Я про record подумал, там это действительно свойства.
> И главное зачем, неужели нет подсветки свойств класса и локальных переменных?
Просто, повелось так. Чтобы по не писать this, наверное
А если поле protected?
_protected
__protected
#protected
Это все напоминает пережиток венгерской нотации си апи
m_pszMyString
pszMyString
Кроме тех, которые должны быть доступны в дочерних классах.
Попробуй по слову multiplexer поискать.
Вообще, есть ощущение, что на каждый подобный случай кастомное решение пишется в зависимости от требований
Нет, дочерних классов не должно быть, наследование запрещено.
Давай, поясняй, как ты до такого дошёл.
Послушаем крутого программиста хоть.
В очереди предопределённая логика, нужно что бы была возможность отказаться от запроса если уже кто-то занял устройство.
>>3309658
Мультиплексор вроде просто пакует все в один канал (по сути та же очередь), чего-то никаких программных паттернов не гуглится.
Очередь - это очередь. Туда кладутся заявки, дальше какой-то один воркер выбирает заявки, делает что там надо и вызывает колбек или резолвит таску.
Незачем. Это что-то типа async/await когда еще не было тасок. Я когда-то писал на yield свой BackgroundWorker для приложения на винформсах, сейчас бы в коде вместо yield return было бы await.
Ну простым
Тебе надо обработать список и вернуть другой список.
Можешь писать
var list = new List<int>();
foreach(var i in list)
{
list.Add(i++);
}
return list;
А можешь чуть проще
foreach(var i in list)
{
yeild return i++;
}
>var list = new List<int>();
Тут должно быть другое имя, что бы не вводит в заблуждения с foreach.
Это не проще, это сложнее. Поэтому yield никто не использует, как не используют dynamic и прочую хуиту уровня свитч со стрелками.
Уже не помню какой по счету
> Поэтому yield никто не использует,
В некоторых случаях помогает написать код который работает как коллекция, но не выделяет память.
> как не используют dynamic
У меня на прошлой работе использовали когда типы не сходились. Но это европейцы, они долбоёбы.
> и прочую хуиту
можно сюда отнести БД-подобный, но вывернутый наизнанку синтаксис Linq?
>уровня свитч со стрелками.
Э, блядь, чем тебе паттерн мальчик не угодил?
Что это вообще такое, как оно выглядит? Для чего оно?
Представь, что тебе надо отправить своего братюню сделать какую-то работу. Ты выдаешь ему пейджер (СancelationToken). Братюня отправляется делать дело. В какой-то момент ты решаешь что, надо завязывать и отсылаешь на пейджер сообщение "бросай все и сваливай" (token.Cancel();). Поскольку братюня у тебя ответственный, то он периодически чекает пейджер и как только видит, что приходит сигнал (token.IsCancellationRequested==true), бросает все и съебывает завершая задачу
Дополнительно можно нажатием специальной кнопки ( token.ThrowIfCancellationRequested() ) делать так чтобы пейджер взрывался ( выброс исключения ) и задача завершалась.
Да хуль пилить, в итоге это по моей вине, надо было учить и зубрить
Дали заревьюить код, общие вопросы по дотнету, тут я хорошо, потом пошло SQL (который я знаю хуево, ну типа если я работаю условно в pgAdmin я могу там несложные join сделать, апдейтнуть че, селектнуть, но это бывает по работе ну ОЧЕНЬ редко, в основном все через EF, и то, ничего сложного, профильтровать через .Where или селекнуть через .Select
Поэтому EF тоже завалил, там практическое задание мол запили такой-то запрос через linq
Потом пара вопросов по ASP.NET, про middleware и фильтры, тоже не ебу, в работе не использовал никогда, про конвеер обработки запросов спросили
А, еще юнит тесты, на работе MSUnit когда весь мир на xUnit или nUnit, но не суть
Там был класс, наследуемый от интерфейса, и метод, который вызывает другой метод
Я на своей работе всегда мокал через интерфейс (потому что старшие коллеги так делали, а как и почему я спросить не удосужился, думал мол так принято наверное), а мне интервьюер говорит надо тестировать саму реализацию, в общем там тоже обсер
Просили опыта в Cloud, но тут совсем ноль, я даже не знаю с чего начать изучать это, так и сказал опыта в этом нет
Ну и про JS спросили, про промисы, тоже обосрамс, полтора года на писал на жабаскрипте (да даже когда и писал то проекты были максимально убогие и примитивные, и каких то особых знаний по промисам были не нужны, тупо хуяришь через await .then
Не знаю в общем, работу надо бы уже менять, но времени и главное сил учить новое абсолютно нет после целого дня работы
Понял, спасибо, этими токенами и можно ответить если на собесе спросят типа "Как завершать Task принудительно?"?
А зачем token.ThrowIfCancellationRequested() если есть Cancel()?
>А зачем
Лень расписывать, вот тут понятно и просто
https://metanit.com/sharp/tutorial/12.5.php
Без обид, но звучит все как будто у тебя совсем жидкая база и работаешь ты просто как кодомакака, как тебе когда-то показали и просто хуяришь по шаблону. Без попыток разобраться глубже как собственно работает все то, чем ты пользуешься.
Вот например
>по ASP.NET, про middleware и фильтры, тоже не ебу, в работе не использовал никогда, про конвеер обработки запросов спросили
Ну это ж блин, совсем база асп-а.
>класс, наследуемый от интерфейса
Над тобой в открытую не ржали на собесе за такие формулировки?
>Я на своей работе всегда мокал через интерфейс (потому что старшие коллеги так делали, а как и почему я спросить не удосужился, думал мол так принято наверное), а мне интервьюер говорит надо тестировать саму реализацию, в общем там тоже обсер
Тут вообще хуй поймешь. Ты что, мокаешь интерфейс который реализует класс и потом это мок тестируешь или что? Естественно, что это звучит как хуета, а не тестирование.
Ты, как бы да, тестируешь конкретную реализацию, а мокаешь то, что у неё в зависимостях и подбрасываешь в неё эти моки. Ну и соответственно мок ты делаешь на то, что требуется.
Про js не скажу. Я про него забыл благополучно, как только в чистый бэк ушел и сейчас даже не рассматриваю вакансии с ним.
>Не знаю в общем, работу надо бы уже менять, но времени и главное сил учить новое абсолютно нет после целого дня работы
С таким подходом ты еще долго будешь собесы въебывать.
Есть такое правило, если собираешься менять работу, то на текущую кладешь самый большой болт из возможных. Делаешь ровно столько, чтобы продержаться и не вылететь нужный период без сильных подозрений, а все остальное высвободившееся рабочее время тратишь на подготовку к новой. Все, что ты описал, можно пофиксить за пару недель, вдумчивым чтением хотя бы того же метанита, это не рокет саенс, чтобы на это дохуя времени тратить пришлось.
Ебать пиздец, я дотнет трогал только в виде хэлоувордов, linq ковырял пару раз, пару лет назад и мне кажется что прошел бы собес лучше чем ты. Ты просто базовую базу не знаешь, тебя наверное за волчару приняли
Мимо не шарпист
>чем тебе паттерн мальчик не угодил?
Нечитабельное говно. У обычных ифов четкая структура: заголовок с условием и тело с логикой. Легко читается на ревью. В свитче со стрелочками у тебя ебаное месиво из символов уезжает за экран. Надо напрягаться, чтобы распарсить этот мусор, особенно с дженериками. В свое время перл хуесосили за write-only код, но выросло поколение смузи и придумало новый перл.
Не откликайся на фулстек вакансии, там говно и пидорасы. Подавайся конкретно на бэкенд.
>Нечитабельное говно.
А ты случайно не из тех разаботчиков, с объективным и единственно правильным чувством прекрасного?
>Я на своей работе всегда мокал через интерфейс (потому что старшие коллеги так делали, а как и почему я спросить не удосужился, думал мол так принято наверное), а мне интервьюер говорит надо тестировать саму реализацию, в общем там тоже обсер
Ты тестировал мок интерфейса то есть? НАХУЯ?
>>3310999
>>3311124
Я давно осознал что я лоуайкью, но уже поздно
Буду дальше пытаться вызубрить, потом все равно забуду потому что в работе не использую
Другой вопрос, почему в авалонии окна не синглтоны блеать.
Толсто. Он всё правильно сказал, мок через интерфейсы и только через них тестируется.
У тебя вместо мозга насрано. Илды годная фича которая на асинках ещё дальше в космос улетела, ты её не используешь только потому что тебя как макаку не допускают до чего-то серьёзного, по факту ты конечно ими косвенно пользуешься через библиотеки даже не подозревая об этом.
> устроить очередной жабосрач.
Зачем? Ну жаба и жаба. На ней вроде тоже можно писать ЭЛЕГАНТНЫЕ решения
@
начинаешь делать
@
на удивление обнаруживаешь что уже почти закончил, не такая уж и сложная
берешься за якобы "легкую" задачу
@
ебешься с ней неделю
Есть сервис
Есть DTO которую принимает от фронта
Там всякие валидирующие аттрибуты и прочее
Это надо сохранить в базу
Есть модель самой таблицы
И вот поля из DTO
[SomeAttribute]
public string EstimatedVolume {get; set;}
В модели
public EstimatedVolume EstimatedVolume {get; set;}
Сам класс EstimatedVolume
public class EstimatedVolume
{
public int Id {get; set}
public string Name {get; set;}
}
Типа в будущем возможно появиться необходимость добавить возможные значения, поэтому это тоже сделали таблицей
И таких вот полей штук 15
Так теперь это все надо маппить с DTO на модель
И получается что в методе маппинга есть очень много таких вещей
EstimatedVolume = await _dbContext.EstimatedVolumes.FirstOrDefaultAsync(x => x.Name == someDTO.EstimatedVolume.ToUppper())
?? throw new MappingException(nameof(someDTO.EstimatedVolume), nameof(EstimatedVolume), someDTO.EstimatedVolume)
И вот таких вот штук 15
Скажите, это нормально? Есть ли способ сделать это лучше/более элегантно? Или так принято/правильно?
>нормально
Да, нормально. У тебя возникнет соблазн использовать автомаппер. Но он сделает только хуже.
Попробуй поиграйся required init свойствами, чтобы не конпелировалось если забыл
>[SomeAttribute]
>public string EstimatedVolume {get; set;}
>В модели
>public EstimatedVolume EstimatedVolume {get; set;}
Как минимум нейминг у тебя хуевый. Приходится прилагать дополнительные усилия, чтобы вникнуть в контекст, поскольку все одинаковое.
Сделай хотя бы так:
>public string EstimatedVolumeName {get; set;}
>public EstimatedVolumeModel EstimatedVolume {get; set;}
>Но он сделает только хуже
Был соблазн до того как решили вынести некоторые поля в отдельные таблицы
Автомаппер тут недолюбливают? Сам почти никогда его не юзал, он чем то плох?
>он чем то плох?
Самый медленный из всех мапперов.
Херово дебажить. Часть логики может быть неявной и скрытой.
Если делать так чтобы работало правильно, то там заебешься нормально все правила расписывать, так что проще руками обычный экстеншен написать.
Опять же пример, что ты вверху описал с EstimatedVolume по сути не маппинг, а обогащение модели. А это немного другое.
>Автомаппер тут недолюбливают? Сам почти никогда его не юзал, он чем то плох?
Если коротко, Automapper добавляют, в проект, он первые 2 недели работает, а потом с ним гей-секс ежедневный.
https://www.reddit.com/r/dotnet/comments/13fb1q3/is_automapper_the_most_hated_library/
То есть для 15 полей ты делаешь 15 запросов для каждой модели? Твой сервис умрет нахуй на проде.
Почему бы просто не использовать dapper? Быстрая легковесная штука без лишних наворотов.
Наследование - это как goto. Усложняет код и отладку не давая особых плюсов. Вызывает проблемы с непонятным поведением, когда переопределяются методы, тем более в шарпе, где методы бывают виртуальные/не-виртуальные. Чтобы понять, что конкретно происходит, приходится долго копаться.
При этом наследование легко заменяется композицией.
Даппер тут не при чём. Хороший, предсказуемый инструмент. Правда, авторы немного намудрили с генерацией IL кода на лету, но в целом норм библиотека.
Автомаппер же это совсем другое дело. Там можно ебашить в обе стороны, вдоль, поперёк и между слоями приложения. Можно маппить замапленное. Синтаксис автомаппера полон по тьюрингу, на нём можно в целом даже UI фреймворк написать.
> Наследование
> Композиция
Под каждое место свой инструмент, разве нет?
>где на самом деле у него враг
мой враг - это выразительный и ЭЛЕГАНТНЫЙ код
Я честно не понимаю о чем ты, это какой-то твой локальным мем. Наверное нашел какую-то олдфажную херню и носится с ней, аки ребенок. Поверь, жаба - это не та платфома, где нужно начинать легаси войну
Нет. Композиция - это серебряная пуля и золотой молоток.
Для композиции нужен сахар, а вообще это тоже самое что двигать кровати в борделе. Проблема не решается никак, но добавляешь еще бойлерплейт.
Иногда наследование нужно, не всегда, но лучше когда оно есть, чем его нет (только что делал свою иерархию ошибок в либе, а теперь иди посмотри как трахаются гоферы, оборачивая хрень в мудень)
>>3311748
>>3311896
Хуже нет когда вот такие шизы до позиций лидов дорастают и начинают транслировать свое "единственно верное мнение" на всю команду.
То ли дело, когда джуны насмотрятся инфоциган и тащат в проект самые новые модные технологии. Индусы из микрософта жидко пукнули новой фичей уровня linq - срочно добавляем в проект. Потом джун прыгает на новое место через полгода, а проект остается с кучей говна.
>Индусы из микрософта жидко пукнули новой фичей уровня linq
Что с линком не так? Он же настолько охуенен, что на него даже сверху забесплатно нашлёпнули sql-подобный синтаксис
Говно без задач. Когда появляется задача обработать какой-то массив, это проще и понятнее сделать в цикле, а не сочинять длинную соплю из Select и Where.
>жидко пукнули новой фичей уровня linq
>>3313104
>обработать какой-то массив, это проще и понятнее сделать в цикле
Джавист совсем не палится. И 15-летний LINQ у него свежая фича и циклы ему удобнее, ну-ну.
В пару строк пожонглировать данными.
Не-е-е, будем писать простыню на две страницы. И хер бы это писать, так потом сидеть вдуплять полчаса что там происходит с этими данными.
Ладно гоферу некуда деваться, но у тебя же есть котлин с мап/редюс/фильтром
>это проще и понятнее сделать в цикле
Мамка твоя говно без задач. Linq очень хороший и продуманный. Даже не могу придумать, чего там добавить или убрать.
Не, хуже когда лид старый предпенс застрявший в кондовом совковом ООП начала нулевых и не выкупающий новые фичи сишарпа связанные ФП, начиная даже с асинков. Который ебёт тебе мозги кривыми архитектурами практиковавшимися во времена второго сишарпа а аргументы против просто игнорит.
Вы просто скорее всего два петушары, один выёбывается всем новым, а другой строит из себя сениур милорд девелопера.
Вас обоих надо закрыть в номере без компа, чтобы вы сделали гей-секс и помирились.
Нахуя всё это объект? Что за пидормен догадался вводить такое категоричные понятия в программирование?
А самое обидное, что эти мудаки, которые программирование придумывали, ходили друг перед другом гоголем и в ответ на дебильные "ВСЁ ЭТО" придумывали свои "ВСЁ ЭТО". ВСЁ ЭТО АСПЕКТ, например. И похуй, что это значит
Вот у меня есть хуевая туча типов, и только процента два из них нужно использовать как ключи в словаре. ToString переопределён на проекте только один раз и то по ошибке. Что, нельзя было вынести метот GetType в статику, и захуярить интерфейс IDictionaryKey?
До сих пор на собеседовании только половина разрабов отвечает правильно на все вопросы про базовые медоды объекта.
Я в противоположном состоянии от восторга!
Вот ты говоришь два процента. А те, кто придумал концепции "ВСЁ ЕСТЬ X", не имели вообще никакой статистики, им оставалось только наугад реализовывать идеи и потом смотреть, что приживётся.
Пизжу, наверное. не два, а 0,00002 процента. По сути кроме строк и энамов не припомню ключей нигде.
Логика просматривается следующая.
Все объекты можно сравнивать друг с другом, но если ты сравниваешь их, они обязаны соблюдать контракт хешей словаря.
Хуйня, короче, я заебался делать ебало кирпичом и делать вид, что это нормально.
Но да, сишарп охуенен по сравнению с прочим говном.
ну мне, для того чтобы динамически строить древовидную таблицу с кучей свойств и колонок с разными типами.
Структура и свойства задаются через БД, в итоге одну и ту же апишку можно переиспользовать в нескольких проектах, которые при этом могут кардинально отличаться.
Написано в спешке перед дедлайном, вот ща подумываю запилить свой орм для удобства
Было б ещё охуенно запилить ui для редактирования структуры таблицы
Пара строк, потом еще пара строк и еще хотфикс, снова и снова. Через полгода никто уже не понимает, что происходит в этом ебаном месиве. Брейкпоинты поставить нельзя, отладка силой мысли.
Всегда забавляют джуны, которые открывают для себе ФП и начинают совать его во все дыры.
Ты намешал разные слои. Service - это нейминг из слоя бузинес логики, в DAL принято называть Repository. Суть везде одна - какой-то интерфейс что-то делает важное.
Ты сейчас реально пытаешься сопоставить простыню кода с циклами, где обязательно кто-то сделает по другому или обосреться, с короткими калбэками вида
map { it * 2 }. filter { it > 0 }
Какого ты жабер пытаешься обмануть? И что с твоим отладчиком в синхроном коде?
В джаве не было алиасинга импортов (а может до сих пор нет) и там было просто соревнование кто придумает длиннее имена.
Джунишка, и сколько же раз будет выполняться реаллокация памяти в твоем коротком смузи коде?
> Джунишка
> реаллокация
Я тут три недели назад выкинул кусок кода, который на пост запрос
писал в лог 8 мегабайт состояния приложения. И работало же как-то. Около двух лет работало, никто не жаловался.
В выборе между вложенными циклами и функциональными коллбеками отдам предпочтение коллбекам. Ну будут они немного немного медленнее чем кастомный вариант, да и хуй с ним.
Зато не стрельнет с выходом за пределы массива и вчитываться не надо. Если ты предпочитаешь писать производительный код - ебись с ним сам, не втягивай в это окружающих
Хороший холоп, переживает за железку барена. Но чаще так бывает что такие алгоритмы имеют оптимизацию, а твоя дрочка руками, чаще, нет.
И опять же, мы говорим что важнее читабельность кода. Читать размазанную портянку бойлерплейта на пару экранов куда сложнее.
>и сколько же раз будет выполняться реаллокация памяти в твоем коротком смузи коде?
Столько же сколько в твоей лапше на циклах.
Ну и для развития можешь почитать про последние оптимизации в 9-м дотнете, там много чего подтянули и по памяти и по производительности конкретно в linq-е
>>3314157
>>3314204
Караван охуительных историй от вкатунов. Вы же литкод решаете, за о-большое шарите, должны понимать, как работает монада энумерабл и как выделяется память в листе. Походу, литкод - это про гоферов, в дотнете публика попроще.
> за о-большое шарите, должны понимать, как работает монада энумерабл и как выделяется память в листе.
А так же понимаем, что на правку цикла, выскочившего за пределы массива может уйти месяц. Просто потому что процессы так настроены. За этот месяц твой менеджер настолько выебет мозги, что ты перестанешь думать категориями аллокаций
Тем что использование int в качестве ИД это дурной тон.
1) жирная вероятность получить колизию
2) требования сильно резать яйца уровнем изоляция БД
3) принципиально невозможно генерировать ключ на стороне клиента
4) int когда кончится и в некоторых системах такого ключа хватит на пол года максимум.
Guid решает все эти проблемы потому что вероятность его совпадения около 0.
>При этом наследование легко заменяется композицией
Нет. Это абсолютно разные вещи.
Наследование – А является В по своей сути
Композиция – А состоит из В, Д, С, М но не является ими.
Желание использовать композицию скрывает в себе желание сделать множественое наследование классов, что запрещено, а множественое наследование это хуево.
>Тем что использование int в качестве ИД это дурной тон.
Ты не отличаешь автоинкремент от хеша, а хеш от гуида?
Ну и где твой бог теперь?
Слушай. Зайдай спискам В в начале размер по длине А. Это должно улучшить работу Add. В основе List лежит массив и там есть этап копирования и аллокации нового если размер инициализации превышен.
По идее тогда все три будут работать одинаково потому что ВНЕЗАПНО генерируется примерно одинаковый IL
Т.е. я вроде и слышал много хорошего и сахарного о шарпе, как тут все удобно, просто берут джаву и делают лучше, и язык развивается, и чуть ли там не в микросервисы пытается, соревнуясь по скорости c node.js и т.п.
Но на деле тред видно полуживой, вакансий меньше, чем на джаве, но есть, з/п тоже меньше в среднем, качество и количество обучающих источников (книги, гайды какие-то, комьюнити с видосами и ответами) наверняка хуже и меньше, еще и на шинде копошиться. Легаси кода чуть меньше и новых проектов наверное чуть больше, хоть небольшое преимущество то есть, или те же яйца?
Ну я джава в целом популярнее и везде, а тут якобы 90% работы - это фулстэк разработка, и всё, остальное какие-нибудь 2.5 страховые
Еще и обидно будут обзывать сисярпом
Ну на юнити хотел побаловаться игрушки попробовать поделать, но думаю при желании и с джавы выучить юнити не составить труда
И в целом слышал, что лучше учить джаву, а работать удобнее всего на шарпе.
В общем, буду рад ваше адекватное мнение и советы
Джун, ты не очень умный. Из-за таких, как ты, игры на юнити стали мемом.
При создании collectionB сразу указывай размер массива. Сейчас ты три раза написал одно и то же и что-то пытаешься доказать.
И это я молчу про inplace алгоритмы, с linq это в принципе невозможно.
Ты сам ответил на свой вопрос. По дотнету мало вакансий и там один сраный фулстек в нищебродских галерах. Гейдев на юнити - это вообще дно дна, будешь ебашить по 12 часов за зп меньше курьера.
>При создании collectionB сразу указывай размер массива.
Ну будет размер одинаковый во всех трех случаях. Это один хрен подтверждает вот эти тезисы: >>3314204 >>3314148
Теперь запусти бенчмарк для миллиона операций.
Алсо одинаковое Allocated говорит о том, что они добавили костыли и вместо честного IEnumerable через yield передают какую-то свою монаду, где сохраняют размер исходной коллекции, а потом в ToList чекают типы и выделяют память один раз. Или же индусы подпилили компилятор, чтобы он распознавал такие паттерны и в искусственных манятестах выдавал одинаковый результат, от них всего можно ожидать. В реальном коде результат будет немного другой.
>>3315240
Тебе пиздят. Джава мёртвый язык, на нем не пишут ничего нового. Дотнет же основой стек разработки ВСЕХ финтехов России, Азии и Запада, а финтех это куча денег.
Учи шарпы и иди работать в банк и будет тебе зп 300к в месяц и премии каждый год.
Нет чел блять не поэтому. Потому что нет там никаких блять монад, все эти методы развернутся в ОДИНАКОВЫЙ код при сборке. В данном случае весь linq это просто сахар.
Главная мощь linq это когда ты запросы в БД бесшовно переводишь в запросы в памяти, потом пишешь кучу фильтров и групировок и заменяешь огромные партаки, на оптимизированый код. Ещё скажи ты будешь yield return имитировать через goto или break.
Как ты кстати предлагаешь строить цепочки запросов без linq? Мне вот достаточно написать пачку методов расширения или через if накидать where на запрос и готово можно хоть 40 фильтров добавить на запросы к БД и это выглядит очень легко и приятно.
https://github.com/microsoft/referencesource/blob/master/System.Core/System/Linq/Enumerable.cs
https://github.com/microsoft/referencesource/blob/master/mscorlib/system/collections/generic/list.cs
На блять читай. Ахуеть неправда ли? Они просто копируют содержимое памяти одного массива в другой. Даже пизже чем твои приседания с new. Самое тут интересное что это значит что на миллионе операций работает linq ещё лучше
На ДЕСЯТИ МИЛЛИОНАХ разница между лупом и linq 18807,14 наносекуд это 0,01880714 миллисекунд. Восемнадцать тысячных тысячных секунды.
При этом есть огромное подозрение, исходя из предыдущих прогонов, что задержка связана с тем что в конце происходит копирование и мы просто не попадаем в кэши процессора или что-то такое.
В целом очевидно что linq пизже. Он при материализации оптимально использует память.
>Как ты кстати предлагаешь строить цепочки запросов без linq?
SQL пишут на SQL, долбоеб ты из епама. Как ты собираешься потом оптимизировать свою соплю на живой базе? Волшебный linq сам индексы пропишет и денормализацию сделает? Пиздец нахуй.
>Как ты собираешься потом оптимизировать свою соплю на живой базе?
А оно надо? У тебя есть достоверные данные что оптимизированый запрос ускорит выполнение?
>SQL пишут на SQL, долбоеб ты из епама
Так ты предлагаешь с помощью stringbulider строить строку запроса? А потом ещё скажи даппером или руками на объекты мапить?
Как в твоём манямире без ORM ты контролируешь свои 200 классов и их мапинги на таблицы и типы колонок и пропертей, связи между таблицами их отображение в классах.
У меня это делает EF, он просто тупо отвалится если не сможет сопоставить БД с иерархией классов.
>У тебя есть достоверные данные что оптимизированый запрос ускорит выполнение?
>с помощью stringbulider строить строку запроса
>свои 200 классов
Матерь божья! Скажи, что ты троллишь.
Давай кстати вернёмся обратно к теме.
Че там с linq и лупом? Вон оказывается linq быстрее работает.
>Волшебный linq сам индексы пропишет и денормализацию сделает?
Ты совсем ебобо? Ты у себя что там, для каждого запроса перекидываешь данные между таблицами и индексы создаешь?
Какими хреном ты вообще умудрился смешать область запросов к БД и область её проектирования?
Ра-адостно.
Джавая это обрезанные шарпы.
Зная шарпы с легкостью вкатишься в джаву, наоборот нет.
Еще, говорят, дотнет популярен в госдепе США. Это может говорить о многом.
Но я мелком повникал в движуху шарпов, у меня сохранилось ощущение что мс потеет над языком, например, вроде как, пролоббировал его в годот, он теперь в списках основных. Или как в джаве вышли грин треды и тима сразу среагировала, начала исследовать и решили улучшить асинки через вирт машину (раньше CLR ничего не знал об асинках, то есть, это сделано через компиляцию).
Меня как потребителя привлекает, что инструмент развивается, а не кусок говна, в который с годами добавляются базовые потребности типа пакетного менджера или дженериков. Джава тоже раз 15 лет техи завозят и в основном живет на капитале кода и сторонних потребителей.
Надо делать нормально вот че. Если нормально это циклы написать, то нужно циклы делать, если просто преобразовать набор данных то делай на linq.
Если посмотреть на бенчмарки окажется что нужно не убирать linq, а правильно использовать List делая инициализацию размера для уменьшения аллокации памяти.
Даже в жабе принято писать слой DAO.
Ты из сервиса получаешь готовые данные, а откуда они пришли (из бд, из файла, из сети, из памяти для мок-тестов) это не важно. И если надо будет оптимизировать и написать SQL руками - ты напишешь их через имплементацию этого сервиса. гребанные вкатуны даже базу не знают
Я обосрался, простите меня, я дурачок выращенный на ютуб вскриках, а там идеально все только в джаве, а все что в ней нет - ужасное, кривое зло, незаслуживающие джавы.
мимо 10 лет работал в джаве, там примерно такой манямир. Ну как еще, кроме манямира там ничего и нет.
Ну использовать DAO и любые репозиторий поверх EF это уже хуйня из под коня. Везде где видел это обычно превращается в написание адаптеров над ним и классов РепозиторийГовна на 200 методов под каждый пук.
Почему-то никому в голову не приходит что EF и linq то и так полностью скрывает от тебя откуда берутся данные. В случае тестов ты одним движением делаешь все из памяти, можно подключить любые провайдеры.
Ниразу не видел чтобы кто-то пользовался даже продвинутыми фишками самого EF, не то что реально начинал писать доступ к данным через другие штуки.
Че шучу клоун. Тебе с фронта пришло 5 фильтров и три сортировки. Ты это через сырой sql как будешь делать?
Или необходимо изменить типы и провести миграции.
Пишу на нескольких языках и на чистом SQL ибо затрах вникать в каждый велосипед, поэтому DAO даже вне кровавого энтерпрайза норм.
Да и банально когда клепаешь прототип, то DAO с объектами-затычками это просто удобно.
Понятно что это долго и муторно писать, но это потом окупается в отладке.
Дай угадаю: ты фулстек в финтех стартапе, который никогда не выйдет в релиз и там можно писать что угодно. EF сам по себе кал говна и годится только побырику нахуячить чето там, а потом выбросить при первых же проблемах с перфомансом. Ведь SQL это сложна нипанятна индексы нормализация ой все, некогда думать надо высрать 100 микросервисов до пятницы. Неудивительно, почему хайперфоманс пишется на голанге, а дотнет тонет в аутстаф галерах.
На твоей галере когда-нибудь слышали про хранимые процедуры?
Коллеги, подскажите плз вопрос по камере HikVision iDS-TCM203-A. Не могу разобраться, как с неё вытянуть номер автомобиля
https://stackoverflow.com/questions/79141957/how-to-capture-car-license-plate-by-using-hikvision-isapi-ids-tcm203-a-camera
Слышали. А еще слышали насколько больно будут пиздить тех кто попробует их протаскивать в проект.
>Ведь SQL это сложна нипанятна индексы нормализация ой все
Чувачок, я теба удивлю, но при использовании ORM тебе точно так же придется и индексы прописывать и БД проектировать с учетом нормализации/денормализации.
>2к24
>хранимки
За такие штуки в приличных местах ебучку ломают
Ну а как ещё сохранить лицо? Гордость не позволяет написать "Сорри, был не прав", вот и сливаются по-тихому.
>Дотнет же основой стек разработки ВСЕХ финтехов России, Азии и Запада
Прохладная история. Пруфы на это будут?
Вакансий меньше, джава всегд на слуху, на нем написан финтех и никто его переписывать не будет. Из крупных контор у нас, я видел лишь озон, который использует шарп.
>>3315751
Тоже прохлада какая-то, в чем это заключается и аргументируется? Скорее, наоборот, засахаренная и допиленная джава
Чувачок, если орм - это даппер, вопросов нет. Вопросы возникают, когда фулстек дебилы используют EF и тянут соплю из Queryable аж до самого контроллера. В джаве хибернейт считается моветоном, в гошке такой хуйни вообще нет, только в дотнете продолжают жрать говно из жопы индуса. Поэтому дотнет в хайлоаде и не используют.
Читаешь тред:
>в новом дотнете будет новая фичанейм, в джаве такого нет
>смотри вот тест, работает на 10 наносекунд быстрее, чем в го
>100500 вакансий ты просто искать не умеешь
Открываешь вакансии:
>пук пук требуется фулстек на аутстаф в ип аванесян
>требования: знание вуе реакт ангуляр, опыт администрирования кластера кафки от 5 лет
>молодой динамично развивающийся коллектив
>испытательный срок 6 месяцев
>оплата ветками
Ты инженер или гуманитарий? Как ты воспринимаешь разницу между 5000 и 3000 вакансий? Ты реально думаешь что сможешь пройти 1000 собеседований? Или ты сможешь сменить 1000 рабочих мест за 10 лет? А сопоставимы ли вакансии джавы к шарпу 1 к 1? Одинаковый у них "вес" и качество? А хочешь ли ты писать на джаве и ее зоопарке легаси инфраструктуры? А сколько соискателей на место? Не забываем что джава это инфоцыганский язык как и питон.
Мой коэффициент и множитель шарп вакансий где-то, условно, 0.2 (3000 0.2 = 600), а так как я не хочу писать на допотопной кобол-джаве конкурируя со специалистами индии, мой множитель 0.0 (5000 0.0 = 0)
И что мы получаем, я могу рассмотреть нормально на шарпах примерно 600 вакансий, когда из джавы мне доступно 0!
>Тоже прохлада какая-то, в чем это заключается и аргументируется? Скорее, наоборот, засахаренная и допиленная джава
Практика показывает что лучше когда сахар есть, чем его нет. Исключение только когда ты джун, то да, тебе учить много и это страшно. Но ты же не вкатун, да?
Простота языковых конструкций чаще приводит к бойлерплейту, тот же мап/редюс, я реально недавно видел простыню го кода, где на 2-3 страницы кода можно было сократить до нескольких десяток строк, попутно выкинув еще err != nil. То есть, человеку на простые действия пришлось писать портянка кода, попутно дергаясь на err != nil, а мне пришлось читать эту портянку кода, чтобы понять что по сути это манипулирование списками данных.
>В джаве хибернейт считается моветоном
Кто считает, твой очередной протык с ютуба? А индустрия в курсе вашего выбора?
>Поэтому дотнет в хайлоаде и не используют.
О это классическая мантра манямира джавы. На деле, мы же инженеры, да? Мы не верим этим фразам из конференций, насколько жаба быстра и пойдем тестировать, ведь да?
А потом выходит что быстрый срыг (как прям заявляют они) по производительности как питонодресня, ой.
В джава мире проще развести кабана на железку, чем нанимать спецов умеющих писать код, в итоге мы получаем инфраструктуру которая медленнее чем пхп. Представь мое лицо, когда из каждого носка мне утверждали о том, что джава быстра и вообще супер пупер, но на тестовой машине она отсасывала пхп эквиваленту и жрала аки слон? Тебя передернет, но переписывание с джавы на пхп, мы выиграли в свое время. (хотя ладно, джава-манямир устойчив, помню когда вышел го, на конференциях хуесосили GC го, мол насколько у нас в джаве лучше и тут же параллельно начали в попыхах пилить аналог, ну что за лицемерные мрази? Секта, не иначе.)
Давай язык фактов, ты инженегр или гуманитарий? Пока что они рассуждения.
>джава это инфоцыганский язык как и питон
Охуительные истории, пруфов на это тоже не будет? Как бы да, всякие курсы по джаве есть, потому что финтех нуждается в джавистах, и что? Это скорее очередной камень в сторону шарпа, что он настолько нахуй никому не нужен, что даже курсов по нему не пиарят. По такой логике, надо учить какой-нибудь руби или хотя бы скалу, там вообще заебись.
>конкурируя со специалистами индии
Какими блять индусами, ты шиз что ли блять очередной? Ты жопой в Барнауле, но всем сердцем в Сан-Франциско и тебя душат аутсорсеры из стран 3 мира?
>>3316148
>Практика показывает что лучше когда сахар есть, чем его нет. Исключение только когда ты джун, то да, тебе учить много и это страшно. Но ты же не вкатун, да?
Так я вкатун, об этом и речь, я же сказал. Типо шарп весь такой прикольный, допиленный, сахарный по сравнению с джавой, только вот он нахуй никому не нужен в основном, кроме фулстэка, такого количества работы, ажиотажа и годной литры нет. Как язык в вакууме он то возможно и лучше, не мне судить.
Не то что срыг 10 летней давности или самописный EE, и все это на модной молодёжной восьмой джаве, с дикой текучкой кадров, доходило до такого, что пытались засунуть бизнес логику в PL/SQL, потому что было невозможно сопровождать этот размазанный код. Именно в джаве в противовес спаггети-коду - появился термин блинный-код. Когда слой за слоем накладываются дырявые абстракции, аки блины. Но зумеры не знают этот тырпрайз ад, для них жаба это мобильная разработка, а не кровавый.
А вообще надо быть совсем тупым чтобы брать плохую вакансию на шарпах и сопоставлять с хорошей на джаве, это же не /b чтобы черрипикинг прокатил.
Какая разница если в противовес релевантных вакансий на джаве 0.
>Почему твой коллега обосрался и замолчал, а ты бегаешь с обосранными штанами по всему треду? Никому твой кобол не нужен, никто за ним не стоит, кроме крупных игроков с легаси кодом. Сидящих на проклятом вендерлоке, которым приходится адаптироваться.
Котлин и джава сидят на одном локе IDE и знаешь почему котлин в бэкенде не выстрелил? Да потому что никто не начинает новых проектов на jvm уже более 10 лет. Почему в джаве мало фуллстека, да потому что у тебя зоопарк инфраструктуры, да еще легаси код. И так перегружена и текучка.
Индустрия больше вкладывается в манямир чем в реальные технология. Именно от джавы пошли такие понятия как "евангелист" джавы, а потом "адвокаты".
Когда с языком беда, начинают вылазить евангелисты.
Покажи хорошую вакансию для бэкенда на шарпе. Ой, ее же нет, есть только фулстек на аутстафе.
Шарпы есть в бигтехе. Какие проблемы?
То что мелкие кабаны начинают проекты на шарпах и есть фуллстек, это же наоборот хорошо. Ну типа он есть в ноде, го, пхп, питоне, что в этом плохого? Страшнее когда на jvm новые проекты практически не начинают и есть перегруженный легаси зоопарк базводов. Зачем усиливать текучку кадров на джаве прикручивая туда еще фронт?
Ты общаешься с бывшим джавистом, я знаю всю вашу кухню и реальном могу тебя закрытыми глазами обоссать. Если ты сидишь на вкусном рабочем месте, отскребая легаси черкаши, то сиди и попукивай, на твой век жабы хватит. Но жабе стало плохеть еще 15 лет назад, а котлин на андроиде ее просто добил. Я тебе говорю, котлин нанес вреда больше чем шарпы. Не важно сколько написано кода, важно сколько кода пишут сейчас, шарпы скорее конкурируют с го за свежие умы, чем противопоставляют себя с протухшей жабой.
Ах да, вы еще сами завендерлочились об IDE. Я вас с этим просто поздравляю.
Потом оказалось что EF тоже плохо, надо писать сырой SQL и выгружать в память пол БД и руками мапить эту хуйню и потом прокидывать все это через все слои.
Зачем? Ну потому что ORM плохо, так сказали на ютубе. Даже придумал что на джаве не пользуются плохим аналогом EF в виде хиберхни.
Теперь уже просто отрицание реальности через мифические говноваканси. Ну не работайте там, идите работать в банки и другой финтех.
>писать сырой SQL и выгружать в память пол БД
Ты совсем дебил? Как раз на sql ты будешь доставать только то, что надо. Это EF радостно сделает тебе N+1. Руками мапить ничего не надо, есть даппер.
>Это EF радостно сделает тебе N+1
Он не делает так уже давно. Он запоминает такие объекты по ИД в памяти и привязывает все другие к одной ссылке в куче.
Можно вообще явно разделеные запросы писать.
Нет никаких объектов, эта хуйня осталась в 1995 году. Есть кортежи данных из бд. Если надо получить (id, username) из бд, эти данные придут из индекса, а что будет в твоей модели? Будешь загружать все поля?
>Прохладная история. Пруфы на это будут?
Ну только я пруфануть могу своим анусом. Сам в финтехе работаю.
Ничего лучше дотнете для не го не придумали ещё
Ну так ты назови, что за финтех и какой ВЕСЬ финтех сидит на дотнете?
>Главная мощь linq это когда ты запросы в БД бесшовно переводишь в запросы в памяти
Не, я, конечно, люблю экстеншены к енумерейблу, но я знавался с одним ебанатом, который везде возвращал IEnumerale<T>. Всё свелось к тому, что я сидел и объяснял ему, что такое DBContext, IDisposable, и почему он постоянно получает ObjectDisposedException
Я это к чему. Бесшовность хороша только в теории. На практике же если швов нет, то их приходится руками делать.
>только в дотнете продолжают жрать говно из жопы индуса
в дотнете вообще все по разному пишут.
Это же тебе не обоссаная спринг-джава, где у разработчиков одни мозги на десятерых
>ВЕСЬ
Банки в основном. Из того, в чём я работал - страхование и форекс. Там тоже на дотнете все. Российский финтех сидит на дотнете не потому что это хорошо, а потому что исторически так сложилось
Проблема в том, что создавать эти файлы не очень удобно. Сохранить всю базу не получится, там сотни таблиц с сотнями тысяч записей, для тестов нужно выбирать только те записи, которые нужны для запроса, а запросы бывают очень сложные с обращением к десяткам таблиц. Хочется это автоматизировать.
Появилась идея сделать прокси где-то между linq выражением и базой данных, и при выполнении запроса к реальной бд сохранять те записи из тех таблиц, к которым и был запрос.
Выглядят запросы примерно так:
var query = select user from GetTable<Users>()
from // дофига джойнов
where user.Name == "karasique" && // куча условий
select new MyDto
{
Name = user.Name
//...
};
var res = query.First();
Query содержит expression tree, на проде оно транслируется в sql.
Можно ли как-то понять, какие именно записи используются в запросе?
Все с ними так, если разработчик не дурак. Почему-то вкатунцы думают, что в хранимках обязательно надо писать бизнес логику. Видимо, какой-то хуй на ютубе им рассказал. На самом деле, хранимка - это sql запрос, написанный в одном месте. Открыл, посмотрел, чекнул план, погонял на живой базе и все это в консоли без запуска приложения. Надо сделать чуть другой запрос - просто скопировал файл, старая хранимка работает по-прежнему, ничего не ломается и не надо дежурить по ночам. Когда ты тянешь соплю из Queryable, логика запроса размазывается по всему коду, потом хуй разберешься, что и как работает. В фулстеке это не проблема, там код пишется с нуля, через полгода выбрасывается нахуй, но продукт живет десятилетиями.
Кароч, суть та же, что и в вопросе оркестрация vs хореография: логика написана в одном месте или размазана тонким слоем говна по всей системе.
Ты занимаешься хуйней. SQL надо писать на SQL, а не на сишарпе. Как ты потом собираешься оптимизировать свой запрос? Каждый раз перекомпилировать и запускать приложение?
> Перенос бизнес логики на уровень БД.
перенос джоинов в оперативную память.
>Для этого нужно мокать таблицы из базы. Сейчас подход такой: берем записи из задействованных таблиц, сохраняем в файлик, и в тестах берем данные из этих файлов вместо реальной бд.
Для этого нужно замокать контексты и кормить EF объектами из памяти.
>Для этого нужно замокать контексты и кормить EF объектами из памяти.
Мышление уровня "я ничего кроме EF не видел, значит все используют EF". Ты читал оригинальный пост?
У меня не EF
>>3317116
Занимаюсь потому что так уже решили до меня. Смысл в том, что мы будем переходить на другую бд, и это будет сделать проще с такой прослойкой. Есть еще причины, но не суть.
Еще раз вкратце: есть IQueriable, который я могу завернуть в прокси класс, есть Linq запрос, который берет из него данные. Вопрос: есть ли возможность понять, какие объекты из IQueriable попадут результат запроса?
> Query содержит expression tree, на проде оно транслируется в sql.
На каком, блядь, проде, что за каша у тебя в голове
> Хочется это автоматизировать.
У тебя есть код с обращением к десяткам таблиц. Ты только сейчас понял, что надо что-то тестировать и с горящей жопой пытаешься подпихнуть что-то автоматически? Раньше надо было думать
> Смысл в том, что мы будем переходить на другую бд
Пиздец тебе, удачи, ставлю лайк
> Вопрос: есть ли возможность понять, какие объекты из IQueriable попадут результат запроса?
Чел, не обижайся, но я с третьего раза распарсил, что ты пытался донести. Ты долбоёб, иди на хуй пиши на пейфоне, пожалуйста
>Смысл в том, что мы будем переходить на другую бд, и это будет сделать проще с такой прослойкой
Проще чем скачать с нугета адаптер? Или вы не такие как все и это какая-то богом забытая хуйня?
Под EF кажется даже для документарных БД есть адаптеры.
>>3317293
>Еще раз вкратце: есть IQueriable, который я могу завернуть в прокси класс, есть Linq запрос, который берет из него данные. Вопрос: есть ли возможность понять, какие объекты из IQueriable попадут результат запроса?
Те что пройдут фильтры или вообще все в случае вызова без них. Единственный если укажут First или Single. Возможно количество элементов если будет вызван такой метод, возможно флаг наличия элементов в коллекции по предекату.
Смысл всей этой штуки чтобы тебя не волновало что там вернётся и откуда эти данные вообще берутся. Причём EF и linq позволяют использовать доступ к данным на любом слое приложения сохраняя изоляцию от уровня хранения.
>Чел, не обижайся, но я с третьего раза распарсил, что ты пытался донести
А что кстати?
Пытаешься закрывать тестами уже существующий, сложный код, который намертво приколочен гвоздями к конкретной БД.
С какой БД переползать то хоть решили на какую? Дай догадаюсь, с оракла или sql-server на постгре?
>Проще чем скачать с нугета адаптер? Или вы не такие как все и это какая-то богом забытая хуйня?
>Под EF кажется даже для документарных БД есть адаптеры.
Как-то переползал с MSSQL на постгрес на EF. Вообще лепота.
- Заменил адаптер
- Снес миграции
- Перегенерил миграции.
Из трудностей легких неудобств, была только правка конфигурации одного сиквенса и все.
Я другой чел. И вообще я прочел три раза ветку, но не понял что он хочет и как с такой кашей в голове он пишет коды.
>На каком, блядь, проде, что за каша у тебя в голове
Я работать дом, говорить люди мало, уга-буга.
>Раньше надо было думать
Раньше я с другим проектом работал.
>Чел, не обижайся, но я с третьего раза распарсил, что ты пытался донести
Я хочу странного, это сложно объяснить
>>3317616
У меня вот это вместо EF.
https://github.com/linq2db/linq2db
По сути то же самое. Архитектурные решения я не принимал, я просто винтик в корпоративной машине.
>Те что пройдут фильтры или вообще все в случае вызова без них
Запрос выглядит вот так
public static Product GetProduct(int id)
{
var query = from p in db.Product
where p.ProductID == id
orderby p.Name descending
select p;
return query.ToList();
}
Тут условие простое, по нему можно руками взять записи из бд, и сохранить для тестов. Проблема в том, что запросы сложные, вплоть до сотен строк, а бд большая, запросы могут по нескольку минут выполняться.
Хочется сделать так: вызвать GetProduct(25), и чтобы одна запись из Products сохранилась в файл, чтобы потом замокать им бд, и чтобы в тесте GetProduct(25) выдал то же самое.
Сохранять для тестов всю таблицу слишком неэффективно, там сотни тысяч записей, и тесты тогда будут несколько дней выполняться.
>>3317624
>sql-server на постгре
Угадал
Не рекомендую. Последние версии (24-го года) стали тормозным говнищем. Через 30 минут активной работы выскакивает увеломляшка что ему не хватает оперативки и он начинает дико тормозить. Приходится его перезапускать.
Специально для теста ставил версию 22-го года. На ней такого дерьма с непомерным жором памяти нет. Но, т.к. в ней нет поддержки 8-го дотнета, то пришлось-таки перейти на VS. Она сейчас заметно бодрее работает, даже с решарпером.
>Проблема в том, что запросы сложные, вплоть до сотен строк, а бд большая, запросы могут по нескольку минут выполняться.
Уволься.
Серьёзно тебе говорю. Ты описываешь контору профнепригодных долбачей которые делают хуйню.
Такие запросы скорее исключение, большинство выполняются за разумное время. Такие монстры появляются из-за того, что весь проект - это миграция с делфи, где бизнес логика лежала в хранимках в sql
Дело не в запросах. Просто ты тратишь время на бесполезные скилы в говнопроекте. Это как работать в Яндекс, потратил время, но все твои навыки бесполезные.
Скилл разгребать легаси не бесполезный. И это не говнопроект, а здоровенная система, связанная с государством и финансами. И весь проект этим легаси не ограничивается, тут еще много всего более современного
>Скилл разгребать легаси не бесполезный.
Если ты из одного кала в другой перегоняешь, то да - бесполезный.
Вот если бы ты к хуям снес хранимки, оптимизировал структуру БД и перенес всю бизнеслогику на уровень приложения, еще и без потери производительности ну или хотя бы с добавлением возможности горизонтального масштабирования - вот это были бы хорошие строчки в резюме. А "Я все время писал юнит-тесты для хранимок старого легаси сервиса" - такое себе.
>Просто ты тратишь время на бесполезные скилы в говнопроекте
Ты не прав, разгребать старый код это самое полезное, что может быть.
Учишься на чужих ошибках.
Пропускаешь этап всевластия мнимого СЕНЬЁРА, когда у тебя что-то по твоему мнению стало получаться, но на самом деле ты обдристался во сне и через пол года твой говнокод будут обводить мелком как место преступления.
Погружаешься в олдскульную философию написания кода. Например, итт есть один дебил, который при слове "хранимка" плакать начинает. А опытный разработчик увидев код написанный на хранимках, смекнёт, что его окружают БДшники, и что у них свой особый склад ума. И как с ними общаться когда залетел на проект, чтобы не стать местным форточником.
И так далее, я могу ещё долго продолжать, но иди на хуй
Так не старый код разгребает, а просто говно из тележки в тележку кидает.
Этот правильно развернул >>3317971 Какие навыки он получит? Как переводить хранимки из mssql в постгрю? Очень полезные навыки нет
Если бы его работа была в том чтобы перенести всю логику из хранимок в код, убрать linq2db, нормально распедалить все по слоям и привести в божеский вид это да полезно, в процессе можно узнать тонкости какие-то или неочевидные штуки. А так его работа это поесть говна и заниматься переносом sql кода на другой диалект.
Верните мне пожалуйста славные времена когда в компаниях были должности ДБ инженеров которые заведовали базами, бэкенд разработчиков которые заведовали и писали бизнес код, архитекторов которые придумывали архетуктуру приложения, фронтов которые писали фронт, дизайнеров которые рисовали макеты и верстальщиков которые стругали шаблоны из них.
ИТ катиться в какой-то Пиздец из-за отмирания разделения труда. Один разработчик пишет бэк, фронт, БД, верстает разметку, пишет деплой и админит сервера и ещё до кучи бегает на совещания к заказчикам и рабочим группам.
>Один разработчик пишет бэк, фронт, БД, верстает разметку, пишет деплой и админит сервера и ещё до кучи бегает на совещания к заказчикам и рабочим группам.
Ты забыл еще сам пишет ТЗ и сам тестирует ("А чо вы не можете проверить то, что сами написали")
>хотя бы с добавлением возможности горизонтального масштабирования
>хотя бы
Проиграл в голос с этого мамкиного архитекта. Масштабирования для бд не существует. Есть шардирование, но для этого надо переколбасить всю систему нахуй.
Это только на аутстаф галерах так. В норм конторах фронт, бэк, девопс и сре - это 4 разных человека, а не один задроченый фулстек.
Причём тут БД пчел. Он про работу бэка, горизонтально это и есть шардировать БД и развернуть 10 инстансов бека.
10 инстансов бэка разворачивать бессмысленно, если они все ходят в одну бд. Тормозит всегда база, а не код. Чтобы запилить шардирование в легаси и починить все баги, надо потратить безумное количество человекочасов.
> Вот если бы ты к хуям снес хранимки, оптимизировал структуру БД и перенес всю бизнеслогику на уровень приложения
То что? Научился бы делать то, чего не просили? Ебать, ты, конечно, лупень
> Если бы его работа была в том чтобы...
Вроде, он написал, что от него требуется?
> перенести всю логику из хранимок в код,
Кто-то просил это делать? Кто-то просил давать ценные советы?
> убрать linq2db,
Кто-то просил это делать?
> нормально распедалить все по слоям
Кто-то просил это делать?
> и привести в божеский вид
Кто-то просил это делать?
Наверное, сами разберутся, да? Или ты умнее?
>>3318459
Ну не просили - пусть не делает. Навыки переноса говна из одной БД в другоу очень ценятся на рынке труда (нет).
Ваши действия?
> Ваши действия?
Пойду посру.
Ну... Я просто думал, вызывает ли это негатив с первого взгляда или нет.
Короче - беру в работу и переписываю легаси на такой вот подход.
Ты че ебнутый? Это же говнокод ебаный под названием сервис локатор. Большей помойки нельзя придумать.
Я знаю. Потому и не хотел делать. Особенно не хотел, потому что если забуду обработчик, а определю что сущность это может - я только в рантайме это поймаю.
Но тут такое дело. Что мой главный - хочет чтобы со своей стороны - он пользовался одним интерфейсом.
Придумал класс с офигенным названием MainClass.
И через этот MainClass - 99% операций это круд-операции.
А меня посадил этот класс поддерживать.
И типа было ок, пока было 2 сущности. Но сейчас их дофига. И методы в духе CreateUser, CreateGroup, CreateJopa, CreateZalupa лично меня уже триггерят.
И если бы логики доменной за ними не было - я бы просто сделал обобщенный метод и радовался. Но там же нет. Создается юзер - надо создать ему какие-то там штуки по умолчанию, создать еще дофига всего. Создается еще что-то надо событие куда-то кинуть и т.д.
Я хотел MainClass превратить в просто диспечеризатор к обработчикам. Оставив этот CRUD-интерфейс и тот 1% методов которые не CRUD.
Потому что ну тяжело. Класс уже 60к строчек. Даже partial не спасает. Потому что в голове тупо это не держится все.
Это самописный DI и что? Очевидно, код был написан до того, как в дотнете появился стандартный DI.
>Я хотел MainClass превратить в просто диспечеризатор к обработчикам.
Чтобы что? Сейчас весь код написан в одном месте. Ты его распидорасишь на 9000 файлов, потом сам охуеешь в этом разбираться.
Джун, запомни два фундаментальных правила в разработке:
1. Чем проще - тем надежнее.
2. Работает - не трогай.
Ты пытаешься нарушить оба просто потому что.
> Чтобы что?
> Потому что ну тяжело. Класс уже 60к строчек
Не тупи, чел.
Я не думаю, что ты все свои апишки через один контроллер делаешь. А ЧОМУ? БЫЛО БЫ УДОБНО, ОДИН КОНТРОЛЛЕР, ВСЕ В ОДНОМ МЕСТЕ. Чет 100% кода что я видел - таки контроллеры зачем-то разбивают по назначению - этот авторизация, тот запрос всякой хуйни, этот для админа чтобы базу мог чистить по кнопке. Вот же дураки, наверное, не могли понять, что чем проще - тем надежнее.
Судя по количеству котлина, кто-то пилит еще мобильные приложения на жабе или реально рынок мобилок такое дно.
Жабун, мне нужно твое лицо в треде.
У тебя пека для учебы и студия зависает на таком большом файле, что ли? Ок, разнесешь ты разные методы по разным файлам, и что? Проебешь кучу времени, сломаешь кучу тестов, по факту ничего не изменится, ты просто две недели будешь сидеть и страдать хуйней. Новую апишку разноси по разным файлам, старую не трогай.
>очень ценятся на рынке труда
На рынке труда ценится то, что человек понимает, что от него хотят. На остальное похуй. Неадекватов, которые переписывают критические куски кода на новую архитектуру без необходимости чекают на собеседованиях специальными вопросами.
Честно, после твоих слов, тебя бы отфильтровали как неадеквата
Как используется? Выглядит как будто кто-то не понимает назначение DI. Само отвалится через пол года, если будешь по нормальному писать
> Класс уже 60к строчек.
60 тысяч строк? Может 6000? Если честно, 600 - уже очень много на мой взгляд. Давай больше подробностей, обожаю читать про говнокод
>Джун, запомни...
Чел правильно говорит, а ты долбоёб знатный. Ещё и джуном его тыкаешь. Стыдно должно быть
>Джун, запомни...
Чел правильно говорит, а ты долбоёб знатный. Ещё и джуном его тыкаешь. Стыдно должно быть
>хочет чтобы со своей стороны - он пользовался одним интерфейсом.
Чтобы что? Вы нищие, на интерфейсах экономите?
Чел, складывать код в один файл нельзя. Не советуй говна
>хочет чтобы со своей стороны - он пользовался одним интерфейсом
Чтобы что? Все эти медиаторы и вызовы всего через 1 интерфейс это говно блядское которое скрывает рельные зависимости класса и усложняет навигацию по коду.
Вот открыл я класс, а там 1 зависимость, а на самом деле их 15 просто с помощью твоего чудо говна теперь нихуя не понятно. Также нет аннотации от интелсенс и нормальных ссылок по коду об использовании методов разных сервисов.
Скривлю ебало. Как по мне, внедрение IServiceProvider приемлимо только в инфраструкторном коде.
У нас оно есть только в одном месте - в своей обёртке над Confluent.Kafka. Там для каждого прочитанного из Кафки сообщения помощью сервис-провайдера создаётся свой Scope, а затем из него выдергивается хендлер для этого сообщения и вызывается.
> в своей обёртке над Confluent.Kafka. Там для каждого прочитанного из Кафки сообщения помощью сервис-провайдера создаётся свой Scope, а затем из него выдергивается хендлер для этого сообщения и вызывается.
Кек, такая же фигня. Ты случайно не с моего проекта?
Стандартная практика, я у себя рэббит так же обрабатываю
Это стандартная практика вообще везде. Аспнет похожим образом поднимает контроллеры.
> Давай больше подробностей
Мой главный главарь - сишник бывший.
И в его практике так сложилось, что ему было удобно один .c файл иметь, в котором все что ему надо было. Писал много под МК, всякие роутеры, вайфай-модули, вот это вот все. По сути - становление, как я понял - происходило, когда у тебя считай вся программа в одном-двух файлах.
Мы пилили код. Я сразу предложил, давай я короче накидаю... Он сразу в отказную, дескать все эти пидорасы-пиндосы-жопотрахи, кто пишут ваши книжки - в руках байты не держали, вот короче, будет интерфейс, я его дергаю из своей части. По необходимости - расширяем.
Вокруг этого интерфейса - он свой статичный класс еще навертел, потому что он крайне не любит DI, и создает экземпляр в Main и хуярит в этот статичный класс. Половина его обертки выглядит как:
public static User GetUser(int id){
if(MainClass is not null){
return MainClass.GetUser(int id);
}
return null;
}
Ну так вот. Я первое время вроде ок, пусть будет. В своей части этот класс таки через DI и сервисы делал.
Вот.
Потом я пошел в отпуск. Вернулся, а этот главарь решил что надо УЛУЧШИТЬ КОД. Мои сервисы поудалял, запихнул в этот класс все. Потому что ему так удобнее.
Я тогда типа забил. Решил - ну, хули там. Пилил дальше.
Так прошел год.
Прошел два.
Этот класс разрастался и разрастался.
Так вот и вышло что в нем - все сущности сразу обрабатываются. Управлять этим делом крайне сложно. Оно до сих пор не наебнулось только потому что я еблан и нахуевертил еще тестов. Тесты это отдельная хуйня, чел их не признает, считает что нужно чтобы тестировщики руками тыкали, и если баг не заметили - то это и не баг. Пока тестеров с моей подачи не заставили автоматизировать тестирование - он все время ржал над тем какие криворукие фронтеднеры, ведь их баги сразу видно, а как начали уже его апишку дергать - приуныл, и начал рассказывать, что никто в реальности так бы не дернул, ведь фронтенд не отправляет такого.
Плюсов для себя того что В ОДНОМ МЕСТЕ - я так и не нашел.
>>3318687
Ну, дядьке просто как я понял хочется типа чтобы Application.DoStuf(); И не думать об интерфейсах. Я на самом деле не понимаю че ему так вот нравится.
Просто хочу чтобы наконец прекратилось расширение интерфейса, Он жирный что пиздец, при этом смысла от этого - никакого.
>>3318766
Ты не понял. Там жирный интерфейс:
interface IMain
{
User CreateUser(...);
User UpdateUser(...);
User DeleteUser(...);
List<User> ListUser(...);
Group CreateGroup(...);
Group UpdateGroup(...);
Group DeleteGroup(...);
List<Group> ListGroup(...);
Note CreateNote(...);
Note UpdateNote(...);
Note DeleteNote(...);
List<Group> ListGroup(...);
...
}
И как-бы ноль зависимостей неявных. Только вот как-бы удобнее от этого навигация не становится. С таким же успехом можно все в Program захуйнуть и радоваться. Все в одном файле. Ток как-бы ну хз. По мне - хуйня какая-то. Лучше будет отдельный понятный класс/нтерфейс. Который можно просто создать, и отдельно еще и протестить.
Ты так и не ответил, чем это плохо. Ты хочешь, чтобы было 100500 интерфейсов по 5 методов в каждом. Он хочет один интерфейс со 100500 методов. Почему прав ты, а не он? Что значит лучше/хуже навигация?
>Мой главный главарь - сишник бывший.
>И в его практике так сложилось, что ему было удобно один .c файл иметь
Что-то у тебя там прямо совсем закостенелый долбоеб. Даже в сях спокойно можно программу на несколько файлов пилить и нормально работать.
>>3319035
>все эти пидорасы-пиндосы-жопотрахи, кто пишут ваши книжки - в руках байты не держали
М-да. Хуже нет, чем лид байтоеб на языках с управляемой памятью. Хотя уверен, что если такому любителю дать поработать с ансейфом и подергать какую-нибудь специфическую апиш-ку где указатели нужны, то он жидко обосрется.
>Ты так и не ответил, чем это плохо.
А смысл, если это как дауну объяснять почему не надо есть суп ножом?
>Что значит лучше/хуже навигация?
А ты случайно не vim-ом пользуешься?
>Почему прав ты, а не он? Что значит лучше/хуже навигация?
Он хочет чтобы один интерфейс неявным образом вызывал 100500 методов.
Я пользуюсь студией. В студии прекрасная навигация по коду. В самом сишарпе можно использовать регионы и сворачивать-разворачивать блоки как тебе захочется. Логику того скуфа я понять могу: зачем обмазывать код абстрактными фабриками, если все работает без них. Он выбросил код анона и ничего не сломалось, следовательно, он прав. У анона же какой-то карго-культ на грани окр: нельзя делать большие файлы потому что потому. Везде должен быть DI, зачем сам не знаю. Будто вернулся в джаву начала нулевых, лол.
Миллиард китайцев едят суп палочками. Объясни им, в чем они не правы.
Ты же мартышка с галеры, тебя научили нажимать кнопки в правильном порядке, ты исполняешь ритуал. Зачем, почему так - некогда думать, надо ебашить микросервисы.
Ну смотри, главное, чтобы у тебя от этого пчелика профессиональной травмы не было.
Типо как у меня, когда я после 3 лет МЕДИАТОР-АВТОМАППЕР-АДА начал писать в категоричном ФП стиле и ругался с коллегами даже за намёк о включении автомаппера или медиатора.
Ну, и наверное, твоего "главного", который порвался в своё время и теперь по инерции творит какую-то дичь
>{
>User CreateUser(...);
>User UpdateUser(...);
>User DeleteUser(...);
>List<User> ListUser(...);
>
>Group CreateGroup(...);
>Group UpdateGroup(...);
>Group DeleteGroup(...);
>List<Group> ListGroup(...);
>
>Note CreateNote(...);
>Note UpdateNote(...);
>Note DeleteNote(...);
>List<Group> ListGroup(...);
>...
>}
Я не фанат наследования, но тут явно напрашивается базовый репозиторий с методами "удалить", "список" и так далее.
> И как-бы ноль зависимостей неявных.
У вас даже такой категории как "зависимости" на проекте скорее всего нет. Так что ты если будешь объяснять, то тебя этот дурак скорее всего не поймёт и в отказ уйдёт потому что ты его из его грёз и маня-мирка в реальный мир пытаешься вытащить.
Не воспринимай серьёзно его, он задрот скорее всего. Смотри по внешним признакам. Обувь, взгляд, и так далее. Если он задрот, то скорее всего будет до конца биться за своё объективное и единственно правильное мнение. Оценивай, смотри, что с ним делать, заходи издалека
>Жабун, мне нужно твое лицо в треде.
Ты бы ещё мамку тут свою поискал
>Почему прав ты, а не он?
Не "прав", а тут по другому стоит смотреть.
Один пчелик явно рассматривает код в какой-то предсказуемой парадигме, вероятно, ООП. Тут всё понятно, с этим можно договориться.
Другой же как будто не понятно какими категориями мыслит. И это опасно. С таким договориться как правило не получается потому что у него в башке какое-то своё единственно правильное понимание как должно быть.
И, очевидно, надо искать не того, кто прав, а смотреть, на что оба ссылаются. На книжки? на опыт? Или на какие-то привидения в своей тупой башке. Надо искать общий язык а не ссать друг другу на лица
>автомаппера
Везде его врубаю. Забись штука, у меня ещё есть свои мидлвари для полной автоматизации всей валидации выходных данных.
Гораздо хуже когда в проекте тысячи срок помойных MapAtoB()
>Один пчелик явно рассматривает код в какой-то предсказуемой парадигме, вероятно, ООП. Тут всё понятно, с этим можно договориться.
Мы вроде в С# треде. Странно обсуждать какие-то другие парадигмы кроме ООП в языке который в базовом уровне построен на ООП. Даже значимые типы это наследники класса object, а DI буквально встроен в язык.
Я когда вижу попытки в процедурку или ФП у меня вопрос нахуя ты выбрал С# иди бери С++ или хаскель и пиши.
У меня вопрос к вменяемости людей которые отрицают наследование, внедрение зависимостей и развесестые интерфейсы потому что "не хочу ООП". Нахуя ты тогда выбрал для мейн языка С# если тебе не нравится подход и философия которая в нем заложена.
Сишарп поддерживает разные парадигмы, наследование от object придумали 20 лет назад и с тех пор многое поменялось. Те же замыкания использовать проще, чем нахуячить 9000 классов в стиле джава 2007.
> Странно обсуждать какие-то другие парадигмы кроме ООП
Чего странного?
>DI буквально встроен в язык.
ебанько?
> Я когда вижу попытки в процедурку или ФП
Уверен, что большая часть разрабов даже не заметит, что код в ФП стиле написан, если он написан хорошо.
> у меня вопрос нахуя ты выбрал С# иди бери С++ или хаскель и пиши.
У меня половина проектов на f#
>Везде его врубаю.
Ключевое слово ВЕЗДЕ. https://www.reddit.com/r/dotnet/comments/13fb1q3/is_automapper_the_most_hated_library/?rdt=34456
> Гораздо хуже когда в проекте тысячи срок помойных MapAtoB()
Чем хуже?
> мидлвари для полной автоматизации всей валидации входных данных.
Дай догадаюсь, ты пишешь по флуент валидатору на хендлер, где проверяешь параметры на NULL?
> https://www.reddit.com/r/dotnet/comments/13fb1q3/is_automapper_the_most_hated_library/?rdt=34456
Собственно.
https://github.com/dotnet/Silk.NET
Когда ты хочешь сам управлять созданием объектов класса. Создаётся статик метод который создаёт новые объекты и private/protected конструктор.
Ничего против ООП не имею. Но только нормального ООП, в котором вместо наследования композиция.
А в чем смысл именно защищенного конструктора?
>>3319584
То есть ответственность за создание дочерних классов будет лежать на дочерних классах? Разве это правильный подход? Почему просто не использовать фабричных класс?
ох уж эти свидетели делегирования. заставить их написать через делегирование на чистом шарпе свой ГУИ фреймворк и поржать над их потугами сделать это поделие хоть немного удобным.
>А в чем смысл именно защищенного конструктора?
Запретить создавать объект через публичный конструктор. А зачем это нужно - это уже вопрос архитектуры.
>В чем смысл protected конструктора?
Ты не с той стороны зашёл. Сначала появляются языковые конструкции, а к ним уже добавляют смыслы. Как хочешь, так и используй, работать будет согласно правилам языка.
Собственно, за это сишарп и любим, потому что к нему любят придумывать всякие мелочи типо линка или укороченных лямбда-экспрешшенов, которые естественным образом появляются на плодородной почве языка.
В этом плане противоположностью будет обоссаный котлин, в котором сначала придумали сценарии использования, из которых собрали песочницу, посадив туда разработчика, потеряв по дороге всю выразительность.
> укороченных лямбда-экспрешшенов
Уточни плиз, о чём речь?
мимоджун
До появления DI - запретить создание объекта через new, чтобы его можно было создать только через статик метод или через фабрику или через синглон.
После появления DI - ненужен.
> До появления DI
С# разработали лет через 20 после появления концепции DI
> запретить создание объекта через new
Это про private. protetcted тебе никак не мешает создавать дочерние классы
> чтобы его можно было создать только через... через фабрику
Чего?
> После появления DI - ненужен.
Я надеюсь, ты не из церкви изгонятелей конструктора? А то у нас был тип, который говорил, что конструкторами пользоваться НЕЛЬЗЯ потому что это ПЛОХАЯ ПРАКТИКА, и пытался регистрировать DTO и DBO в контейнерах
Понимание, как работать с DI, появилось в айти лет десять назад, вместе с клаудами. Когда придумывали протектед конструкторы, все угарали по абстрактным фабрикам и обмазывались паттернами, как в последний раз. В 2024 году никто не пишет развесистые иерархии классов, сервисы создаются через DI, концепция протектед конструктора больше не нужна.
Смысл в том что тебе бывает нужно иметь конструктор у какого-то базового класса, который не доступен извне, но доступен потомкам. Все вот так просто.
Кейсы применения - ты пишешь какую-то библиотеку. У тебя какой-то базовый класс дохуя всего делает общего. Но ты хочешь, чтобы клиент не с твоим базовым классом работал, а производным.
Дальше можно не читать, это пространное говорение с самим собой больше.
Допустим, Ты такой же еблан как и я и решил свою библиотеку для работы с сетевой хуйней сделать. Меня где-то на 3м сервере который работает с TCP - откровенно заебало писать очередную обработку принятия соединений, слежения что там простаивает, одинаковую обработку отвала сокетов, буфферы, пулы потоков чтобы не ебать основной пулл .NET и прочее.
Ну так вот. Ты такой же еблан. Но ты в определенный момент - хочешь передать библиотеку наружу. Чтобы те кто будут ей пользоваться - не лезли в кишки, а просто что им там надо сверху нареализовывали и радовались.
1. Часть людей в рот ебали не то что майковский DI а вообще любой. Им хочется просто MyServer : BaseServer. Реализовать и погнали.
2. Часть не ебали, но у них там свои нинжекты, хуйжекты или вообще самописный DI и под все ты не подстроишься, а форсить их то что ты используешь - ну, говняк откровенно. Потому - если ты сам используешь - оно должно быть зарыто от них, а они должны иметь возможность к себе твое без лишней мороки вклинить.
3. Все без исключения - ебали разбираться что ты там за гений архитектуры, что у тебя там за классы такие хитрые, они хотят server.Start вжух-вжух понеслась.
Так вот. Без протектед конструктора - ты такой пиздец должен будешь навертеть чтобы предоставить удобный интерфейс, что мать его ебал. Конечно, в теплой-уютной команде, где вы там для себя только пишете, можно и подзабить, можно вообще все делать через паблик, никаких инвариантов и прочего, кишки наружу, если надо - спросят. Но даже так. Вот ты объяснишь одному, как этим пользоваться. Другому. Третьему. И вот - уже оказывается, что ты не код пишешь, а 80% времени всем объясняешь как твоим пользоваться - это звоночек, что дизайн хуета, надо переделывать.
Ну напиши мне скаду, без развесистой иерархии классов и протектед конструкторов. Я посмотрю.
То что ты, чел, не умеешь или не пользуешься, не значит что оно не надо. Мне вот на работе не надо докер. Давай я побегу рассказывать, что он не нужен вообще.
Если посмотришь на код майков - они чет в нем активно и в новом коде protected используют, потому что это, блядь, удобно. И DI ты свой сраный в каждую бочку не засунешь. А если будешь пробовать - получишь говняк.
А всего-то достаточно вынести все кишки в приватный класс Impl и просто дергать его внутри публичного класса. Называется паттерн фасад, еще диды так писали на плюсах. Нет, не хотим, хотим наследование инкапсуляцию полиморфизм.
>в нашем некро копро легаси на винформс используются протектед конструкторы
>DI мы не используем
>юнит тесты придумали трусы и слабаки
Я тебя услышал.
Только что это дает-то?
Если тем более, что фассад, если базовому дохуя специфики надо передать - будет таким же всратым.
Вот допустим.
BaseServer(int port, string host, IContextFactory contextFactory, ICodec codec, IBufferFactory bufferFactory, IScheduler scheduler)
Теперь я хочу сделать ModbusServer - который только хост и порт должен принимать в конструкторе.
Каким хреном тут фасад спасет-то? Да никаким.
>>3319778
Чел, ты услышал ровно то что ты хотел услышать.
Если хочешь доказать что я не прав - покажи, как ты будешь реализовывать кейс со скадой без использования протектед-конструкторов. Когда у тебя миллион разных датчиков, миллион разных переменных, драйверов, каналов связи, протоколов, конверторов величин, мнемосхем, тревог, отчетов и прочего, и это еще сверху будет НЕ ПРОГРАММИСТ мышкой на тягать и ручками вбивать какие ему там значения нужны, какую форму отрисовать и прочее-прочее.
Если надо показать наружу BaseServer, но нельзя создавать инстансы ну прям вообще никак - сделай его абстрактным. При чем тут протектед конструктор?
>кейс со скадой без использования протектед-конструкторов
Какое отношение протектед конструкторы имеют к гуи?
> Если надо показать наружу BaseServer, но нельзя создавать инстансы ну прям вообще никак - сделай его абстрактным. При чем тут протектед конструктор?
Так может быть нужно чтобы где-то под капотом и можно было создавать.
Опять - уже из реального опыта - в internal-контексте нужно было иметь возможность создавать объекты базового класса. Потому что там это было удобно и уместно. Делать наследника, просто для internal-штук не хочется, потому что ты плодишь сущности которые нужны только в этом самом internal-контексте.
> Какое отношение протектед конструкторы имеют к гуи?
А при чем тут гуй? Я привожу пример семейства ПО, в котором - у тебя с одной стороны - нужно дать пользователю(как программисту так и не) простой интерфейс взаимодействия. С другой - там дохуя всего под капотом происходит и ты бы хотел в одном месте это один раз написать.
Окей, ты меня убедил. Ваша запутанная система была написана через протектед конструкторы и без них не скомпилируется.
Алсо по поводу скады. Если у вас реально миллионы датчиков и вам надо их обрабатывать в разумное время, про ооп вообще придется забыть и вернутся к процедурному стилю. Загрузили все датчики одного типа в массив структур, залили на ядро, обработали. Датчики другого типа в другой массив, снова обработали. Такой подход используется в геймдеве.
>ну прям вообще никак - сделай его абстрактным
не никак, а снаружи. protected internal иногда бывает весьма полезен
а вообще система видимости в шарпе убогая, как и в тех языках, с которых она это слизала.
>сделай его абстрактным
А если можно, но не всем, а только тебе внутри твоего кода, но при этом необходимо делать класс публичным чтобы пользователь мог кастить к нему.
Да, местами их некоторые кастомные решения иногда непонятны. Или про что ты?
>В чем космический смысл разрабатывать библиотеку и не писать документацию?
Сам напиши! И отправь pr. Ктоооооо яяяяяяяя!?
а еще постой на голове, попрыгай на одной ноге и потяни себя за ухо
есть функционал и тупо советовать избегать его только потому что лишь бы избегать.
Зачем если мне необходима иерархии классов и наследование структуры?
Интерфейс предназначен для наследования поведения.
Приват делают для синглтона, протектет можно если ожидается иерархия таких классов.
> Когда придумывали протектед конструкторы
Я не понимаю, зачем ты продолжаешь какие-то глупости про DI писать.
> В 2024 году никто не пишет развесистые иерархии классов
Все пишут по разному. На WPF и Xamarin очень часто применяют глубокие иерархии наследования. Там так принято.
Тем более, иерархия классов не должна быть глубокой чтобы использовать протектед конструкторы. У меня веб-приложение, есть базовый контроллер с protected конструктором, вроде никто не умер ещё
> сервисы создаются через DI, концепция протектед конструктора больше не нужна.
Может пример приведёшь, как ты связал протектед конструкторы и DI ? Ты сам что-то выдумал и отменил тут же с умным ебальником.
>Смысл в том что тебе бывает нужно иметь конструктор у какого-то базового класса, который не доступен извне, но доступен потомкам. Все вот так просто.
Два чаю этому господину
Устроиться на работу.
Когда тебе пару раз пиздов за переписывание вломят, либо когда проебешь сроки из-за того что переписывал то что работало, либо когда ты что-то сломаешь работавшее из-за переписывания - желание переписывать - пропадет.
>Когда тебе пару раз пиздов за переписывание вломят, либо когда проебешь сроки из-за того что переписывал то что работало, либо когда ты что-то сломаешь работавшее из-за переписывания
Fearless refactoring.
Вкатываться только ради денег. Если для тебя программирование больше, чем просто способ заработать, у тебя всегда будет этот зуд от неидеального кода, его ничем не унять, хоть проработай 10 лет на проектах с вечно горящими сроками. Можно только смириться и научиться находить баланс между временем и качеством.
>>3320098
Ну я для себя пишу, и на заказ тоже пишу троху.
И вот смотрю и понимаю что хуйня же полная получается. Оно то работает да, и задачу выполняет, но вот я смотрю код на гитхабе чей то там так все красиво, а у меня какаето поебень.
Чтобы рефакторить без страха - нужны тесты, няш.
Желательно много. Желательно и негативные. Черный-белый ящик. Вся хуйня.
Интеграционные тоже нужны.
Сверху, нужно писать доки на измененные интерфейсы.
Оформлять ПР и ждать ревью.
Вот и нахуй оно тебе надо, няша? Вот зачем тебе этот головняк? Чтобы что? Почему, просто не сделать свою часть работы, попить чаек и не пойти скроллить двачи?
Смотри. Если оно работает и задачу выполняет - ты берешь и не трогаешь, до того момента, пока снова к этому коду не надо будет прикасаться.
Если никогда не возникает задач которые связаны с модификацией этого кода - просто забей.
Если возникает, и прям мешается то что "поебень", тогда и что-то потихоньку переписываешь. ПЕРЕД ЭТИМ ПОКРЫВ ТЕСТАМИ то что переписываешь.
Все.
А в общем случае. Просто запомни, что тебе не нравилось - и в новом коде не повторяй говняка. Со временем в среднем код будет пизже.
>Может пример приведёшь, как ты связал протектед конструкторы и DI ?
Когда ты используешь DI, ты не пишешь инициализацию в конструкторах. Конструктор нужен, чтобы просто присвоить ссылки, а вся хитровыебаная логика инициализации находится в билдере. Это называется SOLID, дада, тот самый, про который все спрашивают на собесах и который никто не умеет.
>есть базовый контроллер с protected конструктором
Сделай его паблик и ничего не изменится.
Он нужен, чтобы написать
class BaseClass { protected BaseClass(hui, pizda, jigurda) ... }
class MyClass : BaseClass { public MyClass(hui, pizda) : base(hui, pizda, Singleton.Instance.GetJigurda()) ... }
В 1995 году это было нормально, в 2024 за такое определяют на парашу.
Я не пишу на C#, но dependency inversion из SOLID и dependency injection - это, хоть и связанные, но всё-таки разные вещи, если что.
Первая - про программирование на интерфейсах и то, что потребители интерфейса не завязаны на реализацию.
Вторая - что зависимости "вставляются" самим приложением без использования конструктора явно.
SOLID сформулировали 20 лет назад, тогда еще не было DI. Сейчас бы его назвали SOLIDDI белиссимо пер фаворе нахуй.
Спорная штука.
В индустрии в целом чувствуется сопротивление инфоцыганским потугам апологетов "чистого кода", который не решают никаких реальных проблем и только приносят дополнительную сложность.
Честно говоря, я до сих пор не понимаю, почему плохо просто явно вызывать конструктор. Нет, лучше затащим кучу волшебных библиотек с кодгенерацией, которые позволят нам не писать слово new.
Опятяь же, я не знаю C#, может у вас там свой reasoning весомый.
>сформулировали 20 лет назад, тогда еще не было DI.
Жопу ставишь? Эта хуйня старше чем СОЛИД и паттерны.
У тебя наверное инфаркт жопы будет если тебе рассказать как на С писать ООП и как вообще придумали эту парадигму во время анализа памяти приложений.
>Когда ты используешь DI, ты не пишешь инициализацию в конструкторах. Конструктор нужен, чтобы просто присвоить ссылки, а вся хитровыебаная логика инициализации находится в билдере.
Надеюсь, ты понимаешь, что DI контейнер никак не связан с логикой приложения? У контейнера одна ответственность - связать сервисы согласно их скоупам. Никакой инициализации в контейнере нет и не может быть. В билдере DI нет ничего кроме объявления регистраций сервисов. Тем более никакой "хитровыебанной логики"!
Откуда ты это вообще взял?
Я до сих пор не понимаю, каким образом ты умудрился связать protected конструктор с DI, но чем больше я читаю твоих сообщений, тем больше убеждаюсь, что ты долбоёб.
>Это называется SOLID, дада, тот самый, про который все спрашивают на собесах и который никто не умеет.
Каким хуем ты ещё и солид сюда приплёл? Чел, у тебя в голове каша.
Хочу посмотреть на ебальники тех людей, которые спрашивают тебя про СОЛИД, а ты им рассказываешь про вот эту вот всю хуету, что ты пишешь
>Сейчас бы его назвали SOLIDDI белиссимо пер фаворе нахуй.
Схуяли? Это абстракции разного уровня.
>Честно говоря, я до сих пор не понимаю, почему плохо просто явно вызывать конструктор.
Не плохо это. Просто нужно отличать сервисы из контейнера от объектов, которые по месту создаются. Ты же не будешь резолвить из контейнера ДТО, ДБО, агрегат, сущность, список или ещё какую мелочь?
>Конструктор нужен, чтобы просто присвоить ссылки
Чиво блять? Конструктор нужен для аллокации памяти под объект, инициализации каких-то штук типо сетевых соединений или загрузки ресурсов.
Если нормально знать как работает все что ты делаешь у тебя не будет тупых вопросов. Защищённые и приватные конструкторы нужны когда у тебя есть необходимость чтобы пользователи создавали объекты через методы типо Create().
Например майкрософт сейчас переводит работу с алгоритмами шифрования на такой подход, публичные Конструкторы помечены устаревшими и необходимо перейти на создание объектов через методы этого же класса.
>В 1995 году это было нормально, в 2024 за такое определяют на парашу.
А чем это плохо? Ну, кроме того, что ты синглтон впихнул зачем-то? Нахуя ты в кучу смешиваешь одно с другим, наебать кого-то решил?
Поридж, ты тупой. Ты даже не способен понять мою мысль. Ну, бывает, когда всю жизнь копошишься в легаси и наружу не выглядываешь.
>каким образом ты умудрился связать protected конструктор с DI
Когда ты используешь DI, протектед конструктор не нужен. Потому, что ты не создаешь сервисы через new, дебил ты мамин, тебе не надо вызывать конструкторы из базового класса. У тебя вообще нет никаких сраных иерархий наследования, только интерфейсы. Так понятно?
Ты в своём обоссаном примере приводишь две вещи:
- вызов базового конструктора дочерним классом. Это ни разу не проблема,
- использование синглтона в конструкторе. Это проблема для тестов
Не смешивай в кучу, твоей мамке не нравится такое
Откуда вы лезете, блять? Где-то открылся портал в 1998 год?
Зачем скрывать конструктор базового класса - чтобы в наследнике убрать часть параметров, как в примере у >>3319781
Откуда берутся эти пираметры - из синглтона, других вариантов нет.
Как замокать синглтон - никак.
Так понятно?
>Зачем скрывать конструктор базового класса - чтобы в наследнике убрать часть параметров
Сокрытие конструктора никак не связано блять с наследованием.
>Когда тебе пару раз пиздов за переписывание вломят, либо когда проебешь сроки из-за того что переписывал то что работало, либо когда ты что-то сломаешь работавшее из-за переписывания - желание переписывать - пропадет.
Не твоя работа. Есть девопсы и адамины. Твоя работа закончилась когда был влит МР.
Это в голанге не твоя работа, а в фулстеке на сишарпе все твоя работа. Ты скажешь нахуй фулстек, но других вакансий в дотнет не завезли.
>других вакансий в дотнет не завезли
это к вам не завезли. нужно жить на улице где камазы ездят.
>Ты скажешь нахуй фулстек, но других вакансий в дотнет не завезли.
Я фуллстек. Не моя работа, я вообще не знаю как правильно делать релизы и как работает СИ/СД. Я просто жму кнопки в гитлабе и оно само.
голый сервис -> docker -> jenkins -> kuber
В зависимост от того, на что у кабана денег хватит (чем правее, тем дороже)
Как Дженкинс заменяет Докер? Твоя схема не до конца понятна.
>Как Дженкинс заменяет Докер?
Никак. Одно идет за другим и дополняет. Можно и в таком порядке.
jenkins -> docker -> kuber
>Как сейчас модно организовывать CI/CD в шарпе?
Тру шарпобояре деплоят только в ажур. Остальное быдло и нищуки сидят на ку-кук-бернетисе.
https://learn.microsoft.com/ru-ru/azure/devops/pipelines/architectures/devops-pipelines-baseline-architecture
Пфф, петух.
Правишь руками connection стринги в Web.config
Коммитишь в ветку master.
Компилируешь бинарники в Visual Studio.
Запаковываешь в архив в тотал коммандере
Закидываешь себе на электронную почту.
Подключаешься по RDP к Windows Server 2016
Загружаешь бинарники по электронной почте.
Распаковываешь в тотал коммандере
Перекладываешь в IIS
Перезапускаешь аппул
Литералли я, неиронично все из списка делаю и в ус не дую
Литерали наша коробочная система. Только дрочкой с IIS занимаются челики на стороне клиента, наша работа заканчивается на создании zip архива.
Не знаю как модно.
У нас так: Репка под сервис. Приватная репка под разворачивание для прода. Женкинс.
Тесты-хуесты, прогнали, собрали имеж, пометили тегом. Если тег - релиз, репка для прода вытягивает на прод последнике конфиги и образ который изменился. Ну или если конфиг в прод репке изменился - тоже вытягиваем, обновляем все это дело, но там это так редко происходит, что считай не происходит.
Усе.
Куберов не используем, для нас не нужно, у нас просто докеризированые сервисы, не особо под все это облачное подходят(в плане просто так взять и 10 реплик одного сервиса - не получится, некоторые - да, но многие - не, это надо будет когда-нибудь переделывать, но хуй пойми когда). Да и клиентов которым нужно не было, обычно им надо свой няшный инстанс и все.
Единственное что горит. Это железо на котором сборка происходит - старое. Сборка одного сервиса может минут 5 занимать... Это прям расстраивает и заставляет ужиматься, чтобы весь день сборки не ждать. Типа - вроде 5 минут не много, но если сервисов там скажем 100 был бы, это уже 500 минут. Тут был план хитрый - сделать общий слой, который прям все в разом как монолит бы собрал, а остальные имежы - уже свое себе порастягивают. Но пока отказались от этого, хотя по тестам - так прям в разы быстрее на большом кол-ве сервисов.
Да. Всякие графаны, прометеусы, оповещение в телегу/на почту и прочую срань - я опустил. Думаю оно у всех +- одинаково.
https://habr.com/ru/companies/jugru/articles/853728/
для бедных доступен тоже
Нахуя? Вся инфа на английском. На стековерфлоу ответы на английском. Статьи написаны на английском. Нет, не хотим, хотим переводить технические термины и сидеть, как сычи.
Читать большой объем информации на родном языке проще.
Читать большой объем информации на англ без оверхеда для мозгов могут единицы. Такие чаще сидят в фулл англ комьюнити. Переводы популяризируют технологии, укрепляют и объединяют сообщества, от джуна до сеньки. Поддерживать родные языки - хорошо, даже если релокант (учить детей русской или другой твоей культуры это хорошо).
То что ты смог в анг, а другие пока в процессе или не очень, не говорит что это ненужно, в общем, не выеживайся, ты просто тот мусор который потребляет и ничего не отдает взамен.
Хлеб уже и в галантерею завезли! Весной по собесам ходил, все мягко намекают что сеньор теперь и полы моет, и немного девопс, и отсосать ПМу в курилке.
>>3320399
Ну короче если я хочу для своего пета сделать пайплайн, то мне на jenkins ориентироваться? У нас на работе две других системы одна из них гитлаб, вторая тфс, но я в них тупо кнопки нажимаю, работает хуёво. Нихуя не понятно где копать толком.
Чтобы прочитать за два дня а не за два месяца.
Чел, учитывая, насколько мощно работает ИИ в переводах, про английский можно забыть в ближайшие 10 лет как про страшный сон. Разработка на родном языке идёт в 4 раза быстрее, английский это только стопор и помеха.
Это я тебе говорю как человек, проработавший в англоговорящих командах с 2018 года, где араб не понимает грека и оба делают хуйню ввиду языковых ограничений
>Ну короче если я хочу для своего пета сделать пайплайн, то мне на jenkins ориентироваться?
Если у тебя есть где его развернуть, то почему бы и нет.
На последних трех работах где, я работал, дженкинс был стандартом, независимо от того, что там было дальше, кубер или просто архивы сборок на прод отдавались.
Опять же можешь просто на VPS-ке развернуть свой гитлаб, дженкинс. Подружить их друг с другом, сделать проверку покрытия тестами и все-такое. Будет полезно, а слова "у меня есть свой гитлаб с настроеным пайплайном" и последующая демонстрация, очень хорошее впечатление производят на собесах.
Понятно, что большинству разрабов все это знать необязательно, но ситуации бывают разные и чем больше ты разбираешься, тем лучше. У нас например был случай, когда новый девопс пришел, сломал к хуям весь пайплайн и свалил, а чинить пришлось нам восстанавливая все скрипты.
>У нас на работе две других системы одна из них гитлаб, вторая тфс, но я в них тупо кнопки нажимаю
Ну начни с гитлаба - https://docs.gitlab.com/ee/ci/
Потом уже ищи такое же про дженкинс.
Потом как их подружить и т.д.
>Большое внимание уделено минимальным API
>Именно поэтому Эндрю Лок в первой и второй частях книги детально рассматривает минимальные API
Угу, а потом удивляешься откуда столько дятлов берется которые этот минимал api (который по сути инструмент прототипирования) тащат в прод. А когда их тыкаешь носом, чтобы сделали нормально, не знают как, потому, что дальше этих первых двух частей не читают.
>Из третьей части вы узнаете о Razor Pages
Я думал оно уже мертво давно.
>Я думал оно уже мертво давно.
А чего мертво-то? Небольшие корпоративные проекты накидать на шаблонизаторе - богоугодное дело.
Вот, если бы Razor каким-то хорошим способом выделили бы в нугет-пакет - вообще кайф был бы
>араб не понимает грека
>ряяя нахуя мне ваш инглиш у нас арабов великая тысячелетняя культура аллах бабах
>ряяя нахуя мне ваш инглиш у нас греков великая тысячелетняя культура эвклид парфенон
>на митинге: пук среньк
Ты тут вьебал подход CRUD со старта, не?
Get->Post(накройняк Put но транзитивность)
Не смешивать контроллер и его логику. Выноси в отдельный класс.
Вы этого дебила сейчас научите хранить в SQL базах то что там храниться не должно.
>>3298072
Юзай MongoDb и не еби себе мозг
Ну блин. Использование Шарпа попил-мартином это так то антиреклама
Ууу, сишорп это вражеское по, запретить на всякий случай.
>Юзай MongoDb и не еби себе мозг
Монго ужасен во всех смыслах.
Что, картинки в GridFS хранить ещё хуже, чем в блобах в постгресе?
Я бы еще добавил сюда "C# 10 и NET 6 Современная кроссплатформенная разработка" Марка Прайса, когда учился писать на шарпах книга мне зашла, многое разжевала. Для новичков часто советуют еще Head First, ее все так нахваливают, но что то мне подсказывает, что у них рот в джава скрипте.
У человека 7 сообщений за 14 лет, вы представляете как там должно бомбануть, чтобы из редонли вылезти?
Дебаг консоль выдает пикрил.
Я достаю "постранично" в круде данные с таблицы в которой первичный Id это guid. Вся сортировка которая у меня есть это по сути записи которые были добавлены в их текущем хронологическом порядке, у меня нету поля даты добавления или чего-то подобного для сортировки ордером.
То есть я просто хочу достать первые 20 записей, затем вторые 20 записей и т.д., и пока все работает нормально.
Вопрос - почему ef мне пишет про unpredictable results?
Мне ложить хуй или что-то нужно дополнительно сделать?
Потому что без сортировки каждый раз можно получить разные результаты. БД не обязана выдавать тебе кортежи постоянным порядком.
>первичный Id это guid
Нахуя? Вам на курсах не рассказывали про кластерные индексы?
Почему не обязана?
У меня на каждый один и тот же простой select идет одинаковый порядок в котором записи были добавлены хронологически.
>>3321627
Нет, у меня с бд пробелы тащемто, планирую пройти полностью отдельный курс.
Закоментируй месседжбокс в логинформе и посмотри на результат.
>Почему не обязана?
Потому что БД так устроена. Если ты не указываешь порядок, то выдается то, что проще достать.
Данные могут закешироваться. Или между запросами страниц у тебя индекс перестроится.
В любом учебнике по SQL первым делом говорится, что если хочешь однозначные данные, то в запросе должен быть ORDER BY
Так, падажжи. Засунь в assert DialogResult.Cancel вместо None.
за ноуд жи ес ничего сказать не могу, а за пыху - отсутствие необходимости. В новые проекты пых не настолько часто тащат, а в старых и так работает и большинство проблем решается всякими кэфками и рэбитами точеными с редисами дроченными. Впрочем, если под хайлоадом ты подразумеваешь набабахать нод с твоим кодом на пыхе, то так с любым языком получится.
Хочу атрибут сделать, чтобы понавесить на все нужные поля и сократить простыню, но не пони как Action<T, float> и Func<T, float> туда засунуть.
Как быть?
Знаете, иногда полезно вспомнить как ты писал когда-то...
На пыхе много накладных расходов при реквесте nginx дергает php-fpm тот запускает процесс, работает работу, отдает респонс и героически помирает. При каждом реквесте происходит подключение к БД, редису, раббиту и тд, чтение всех файлов, вся остальная поебень, если это симфони или битрикс то там еще всякого говна от фреймворка все это для того чтобы через несколько миллисекунд умереть. Для проектов где высокая нагрузка такой себе выбор, а вот для всяких е-комерс проектов, мухосранских новостей, порталов ЖКХ, сайтов заборостроительных комбинатов с формой "мы вам перезвоним" и картой ебеней промзоны пыха самый раз.
Если из этих двух что-то выбирать, то лучше ноду там все асинхронное и процесс всегда запущен, можно десяток-другой контейнеров поднять и дело в шляпе
не совсем так
php-fpm как раз и служит лечением "героически помирает" ибо представляет собой пул процессов. Со "чтением всех файлов" там кешируется байт код.
в остальном да - сам принцип пыхи "стартануть и выполнить весь код"
зато плюс пыхи в том, что ты можешь наделать 100тыщмиллионов разных сайтов и их один пул php-fpm обработает.
а почему у первого с верным логином неверно показывает?
Накидай простенькое диалоговое окно, которое результ в консоль выкидывает и позакрывай его разными способами. И ты сам всё увидишь. Главный вопрос: Чему равен результ при создании окна? И вопрос вдогонку. В юнит тестах ты проверяешь конкретно что? "Одно значение равно одному значению" или "несколько значений неравны одному значению"?
Обычно при обновлении записей там хронологический порядок добавленич ломается, поэтому обязательно нужен столбец по которому ты ордербай будешь совершать. Вроде есть ещё версия гуида которая сортируется по ордербаю нормально
Есть, называется автоинкремент.
Где вы вообще понабрались этой хуиты про первичный ключ гуид? Чтобы что?
>Чтобы что?
Чтобы не словить переполнение счетчика. Я понимаю тебе сложно понять что автоинкримент НЕЛЬЗЯ использовать в системах с хуевой тучей записей или в конкурентных системах.
Вставка записи с заранее созданым ИД может происходить без блокировки таблицы, а значит можно писать данные из тысячи клиентов без просадки. Также можно легко сделать шардирование.
Гуид может обеспечить уникальные значения даже если ты создал его на 1000 разных машинах в разных частях света и потом все 1000 объектов необходимо сохранить в локальные БД и потом реплецировать в какие-то другие.
> Я понимаю тебе сложно понять что автоинкримент НЕЛЬЗЯ
Используем в транзакциях денег. Если твоя мамка шмара, то это не значит, что у остальных так же
>Сдаётся мне, это вебмакаки с MongoDB ввели такую моду.
Ты бы видел их ебало, когда им объясняешь джоины
>автоинкримент НЕЛЬЗЯ использовать в системах с хуевой тучей записей или в конкурентных системах
Вы там в епаме окончательно ебанулись. Ты бы хоть кабанчика почитал, не позорился.
>Вставка записи с заранее созданым ИД может происходить без блокировки таблицы
Ебать! Ты вообще понимаешь, как работает субд?
>Также можно легко сделать шардирование.
Погугли, что такое композитный ключ, архитектор ты мамкин.
>Гуид может обеспечить уникальные значения
Да неужели? Пропиши это в контракте с неустойкой, камон.
>Чтобы не словить переполнение счетчика.
Если ты возьмешь lopng для primary key и будешь хуярить по миллиону записей в секунду, то тебе понадобится чуть больше 290 лет, чтобы его переполнить. Ты оптимист если думаешь, что хоть одна твоя программа проживет так долго.
>Вставка записи с заранее созданым ИД
А зачем их генерить заранее, когда для этого в БД есть сиквенсы?
А в чем проблема?
Еще раз - Id генерируются самой БД при вставке в таблицу, неважно сколько ты ей записей передаешь.
Если же ты имеешь в виду "получить Id объектов после вставки", то тоже не вижу проблемы. Для этого в постгрес есть returning, в mssql output.
Ну т.е. это вообще не проблема, тут даже за рамки чистого sql или базовых возможностей orm выходить не надо.
Как оцениваешь рынок дотнета после 2022? Хотел бы уйти в джаву, голанг?
>тут даже за рамки чистого sql или базовых возможностей orm выходить не надо.
чистый sql идет лесом. минимально работа с ADO.NET где ест быстрая вставка, но вот получение айди для каждого пункта....
про базовые возможности орм....тот же ef core разве умеет
Не хотел бы. Там я буду меньше иметь. Все же экспертизу я именно тут получал. Плюс - у них тоже не все заебись.
В плане вакансий - +- так же, плюс добавились АНАЛОГОВНЕТНЫЕ конторы, которые раньше не отсвечивали.
В плане проектов - все похуже стало. Я бы сказал - откат в массовом плане по уровню. Но опять же - дофига повылезало АНАЛОГОВНЕТ.
Я бы не советовал шквариться об аналоговнетные если что. Есть мнение, что потом - будет сложнее с таким вот портфолио.
Если бы это были свойства, то можно было бы как на пике, а так - хз.
С полями наверное только кодеген (Reflection.Emit/Dynamic method, Expressions, Source generators, и т.д.).
Мимо не эксперт
Если порождаешь коллекцию чтобы отдать - исходный тип. Если даёшь посмотреть - IReadOnly, а по возможности - инкапсулировать доступ к ней через метод.
Можно так. Ток нахуя - я хуй знает.
>тот же ef core разве умеет
Да.
https://www.milanjovanovic.tech/blog/fast-sql-bulk-inserts-with-csharp-and-ef-core
Плюс любители "быстрого" даппера, могут еще глянуть на результаты бенчмарков и поплакать.))
Ты больной что ли? HttpCallContextAccessor предназначен для получения контекста.
https://metanit.com/sharp/net/2.12.php
про даппер шутники
взяли "пусть даппер делает миллион инсертов" и ха ха ха
даппер это либа читалка. и в CUD не умеет являясь не более чем Sql враппером и маппером результата.
Зато по времени запуска и потреблению памяти EF настолько плох, что не везде и подходит.
>Также можно легко сделать шардирование.
Можно сделать шардирование, а ещё можешь пойти нахуй, если тебя никто не просил делать шардирование.
Типичный высер религиозного фанатика, который пишет единственно правильным способом и мотивирует какой-то побочной хуетой.
Что-то на уровне "ты должен везде использовать автомаппер потому что ОН ОПТИМИЗИРУЕТ ЗАПРОСЫ В БД".
Пиздец, я ебу, надо поговорить с твоей мамкой. Как она такое кресло тупое вырастила?
На мой взгляд лучше воздержаться от возвращения IEnumerable<T>:
- Rider будет тебя задалбывать предупреждением "possible multible enumeration"
- Если качество кода низкое и разрабы плохо понимают время жизни объектов, можно напороться на неожиданные ObjectDisposedException. Часто бывает, кстати
- Потребители будут через каждую строчку делать .ToList()
Естественно стоит воздержаться если это не метод расширения. В 99% случаев есть понимание что на выходе должен быть IReadOnly
>Что-то на уровне "ты должен везде использовать автомаппер потому что ОН ОПТИМИЗИРУЕТ ЗАПРОСЫ В БД".
Лол, с учетом того, что это один из самых медленных и прожорливых мапперов, то я хер знает в чем там смысл этой оптимизации.
Да похуй на оптимизации. Я просто хочу свалить все маппинги в одном месте и забыть об этой хуйне как о страшном сне.
Нет ничего хуже чем бегать по всему коду и искать все эти методы MapZalupaToGovno. В случае автоммапера это хоть все валяется в одном месте рядышком и можно быстро найти все маппинги.
>В случае автоммапера это хоть все валяется в одном месте рядышком и можно быстро найти все маппинги.
Дед писал в одном файле, вот и я пишу!
>Нет ничего хуже чем бегать по всему коду и искать все эти методы MapZalupaToGovno
Нормальные IDE использовать не пробовал?
>В случае автоммапера это хоть все валяется в одном месте рядышком и можно быстро найти все маппинги.
1 - "быстро найти" - все про то же, нахуя их искать? Вот у тебя метод, ткнул в него F12 или мышей и все видишь. В чем сложности-то?
2 - "в одном месте" они у тебя будут только если ты сам их туда запихнешь. Они вполне себе могут быть так же раскиданы по разным файлам и лежать каждый рядом со своими моделями. Плюс с самописными мапингами тоже можно извратиться и запихнуть их все в один файл.
>>3322747
>MapZalupaToGovno
Ну так используй экстеншены с дженериками и у тебя все методы так же и будут называться Map как и у автомаппера.
и пох кто что думает.
Теперь я хочу, чтобы текст в ToggleButton был другого цвета. Я уже привык, что просто задание Foreground ничего не даст — цвет в ToggleButton по прежнему будет красным.
Затем я в ContentPresenter меняю TextElement.Foreground, и теперь это тоже не работает. Почему?
>Нет ничего хуже чем бегать по всему коду и искать все эти методы MapZalupaToGovno
Хуже только удерживать в памяти, какое свойство маппится явно, какое не явно, а какое через аттрибут игнорируется.
Ебать, конечно, с автомаппером можно ад сотврить, потом в строну отскочить и смотреть как олег с ним ебётся
Чтобы переопределить стиль текстблока, стиль кнопки тоже должен переопределять дефолтный стиль, т.е.:
> x:Key="{x:Type ToggleButton}"
Почему стиль со строковым ключом не переопределяет дефолтный - хз, но нам точно известно, что такой стиль - это новый экземпляр.
в ContentPresenter же. когда ты пишешь PropertyName="" это значит явное задание
Я чату гпт задал этот вопрос и он тоже меня понял наоборот. Я НЕ хочу переопределить то, что задано в ContentPresenter явно. Я хочу при помощи ContentPresenter изменить базовый стиль TextBlock.
Если ты посмотришь на этот >>3323064 стиль, то я хочу видеть внутри кнопки текст цвета фуксии, но у меня почему-то он остается красным.
>>3323139
Не работает. Если я напишу пикрилейтед в ресурсах условного окна, то переопределится стиль для текстблоков по умолчанию, но не затронет другие контролы (чего я и хочу добиться).
Но если я абсолютно ту же строку добавлю куда нибудь в отдельный словарь ресурсов, то у меня нахуй все контролы игнорируют собственные значения Foreground.
я вижу у тебя x:Key для стиля текстблока
он не должен автоматом применяться к текстблокам
но я не вижу где бы ты его использовал явно.
>я вижу у тебя x:Key для стиля текстблока
>он не должен автоматом применяться к текстблокам
Если у тебя ключ строковый, типа
> x:Key="TextBlockStyle"
то создается новый экземпляр стиля. В дальнейшем тебе придется явно его применять
> Style="{StaticResource TextBlockStyle}"
Если ты в ключе стиля указываешь тип целевого контрола
> x:Key="{x:Type TextBlock}"
то НЕ создается новый экземпляр стиля, а переопределяется дефолтный стиль. В дальнейшем, где бы не создавался текстблок, он автоматом будет использовать этот стиль.
Но проблема в том, что это влияет вообще на все остальные стили. К примеру, ты переопределил цвет текстблока на красный. А в своей кнопке указал Foreground="Yellow", так вот текст все равно будет красным.
Как с этим бороться - хз, кроме пары костылей.
>то НЕ создается новый экземпляр стиля, а переопределяется дефолтный стиль
я эту магию не знаю. этот x:Key не нужен, ну может там экземпляр где то экономится. все равно решарпер дропнет это указание потом
я не понял зачем ты переопределяешь шаблон toggleкнопки только для цвета
вообще там сам черт ногу сломит в этих стилях, но вот тебе 2 варианта (в зависимости от того что там за контент)
>этот x:Key не нужен
Я думал без ключа нельзя добавлять в словарь. Раньше постоянно выдавало ошибку.
>я не понял зачем ты переопределяешь шаблон toggleкнопки только для цвета
Самый частый случай, возможно это не очень дальновидно.
> но вот тебе 2 варианта
Про это я знаю, но как будто бы это костыль.
Поэтому пишу на Rider, чтобы не вендерлочиться. Тут все по-человечески, и IDE не пытается делать абстракции над своим функционалом, прямо чувствуешь, как развиваешься в познании устройства экосистемы .NET. Кстати, на днях Rider стал бесплатным для некоммерческого использования
https://www.opennet.ru/opennews/art.shtml?num=62233
> Но проблема в том, что это влияет вообще на все остальные стили. К примеру, ты переопределил цвет текстблока на красный. А в своей кнопке указал Foreground="Yellow", так вот текст все равно будет красным.
Так не должно быть. Наследование свойств родительского элемента имеет более высокий приоритет, чем свойства в стиле. По крайней мере во всех современных xaml фреймворках именно так.
Когда в райдер завезут нормальную многооконность с возможностью группировать вкладки в пределах одного окна?
>Наследование свойств родительского элемента имеет более высокий приоритет, чем свойства в стиле.
Контент контрола это не совсем дочерний элемент, иначе бы бэкграунд условного грида влиял на бэкграунд элементов внутри этого грида.
Но все равно мне кажется, что это версия впф какая-то ебанутая. У меня из-за этого переопределения возникают аномалии. К примеру, переопределенный стиль текстблока должен подхватиться радиокнопкой. Но я тестил два списка, абсолютно идентичных по структуре, кроме источника итемов. И в одном списке дефолтный стиль подхватывается, а в другом — нет. Причем привязка контента идет к свойству string. Я голову сломал почему так. Привязываешься к другому свойству и все норм.
Или, вот, к примеру, я создал кнопки стиль с дефолтным бэкграундом, добавил триггер перекраски бэкграунда при наведении курсора. Потом создаю кнопку, применяю этот стиль, а затем беру и меняю бэкграунд. У меня просто перестает отрабатывать смена цвета при наведении курсора.
Да и TextElement.Foreground в контент презентере вроде как должен был переопределить дефолтный цвет контента.
То ли я давно не работал с ВПФ и у меня искаженны представления о работе с ним, то ли раньше такого не было.
Я надеюсь ты за деньги за барина потеешь. А то он на херу тебя вертит, запрещает тебе все, кидает на купленные лицензии, а ты забесплатно ему ножки целуешь.
Вот пикрил 1 — абсолютно два одинаковых ItemsControl, биндятся к двум разным экземплярам одного класса. Стиль TextBlock переопределен на светло-серый. Само свойство Name итема имеет тип string.
На пикрил 2 — как эти два списка выглядят. Дефолтный стиль подхватился только для второго ItemsControl, а первый отображает не переопределенный стиль TextBlock.
У красноглазых все еще триггер на мягких, хотя когда мс говнил в 90е половина в то время еще не родилась. Вторая половина до сих пор в криокамере думая, что дотнет это только про винду.
1. Как ты привяжешь форгарунд стиля к форгарунду темплейта? У тебя темплейт биндинг в этом случае не работает.
2. Если данные о цвете находятся в другом словаре (вряд ли ты будешь хардкорить цвет), то придется юзать DynamicResource, а его запрещено юзать конкретно в этом месте.
>Как ты привяжешь форгарунд стиля к форгарунду темплейта?
через TargetName
Возможно дело в том, что в первом случае у тебя две кнопки в одной группе, и триггерры переопределяют цвет.
Зачем рисковать ради того, чтобы пара анальников порадовалась сахарку?
Мы у себя пишем под астру. Там официально тольео .Net6.
Если случается какая-нибудь хуета, то мы идем и ебем поддержку астры и они её решают.
Нам ничто не мешает накатить 7-й и выше, но в случае каких-либо проблем ебать будут уже нас.
>Почему тырпрайза бояться\стесняются\стремаются писать микросервисы на STS версиях .NET. В чем проблема?
Есть такая проблема в дотнете, что его нужно обновлять ровно в определённый момент. И делать это нужно обязательно, в целях гигиены. На мой взгляд, это выход новой ЛТС.
Но его проёбывают все, а потом накопительный эффект срабатывает.
Плюс, у дотнетчиков есть блядская привычка игнорировать преимущества платформы и тащить в код гордиев узел из нугет зависимостей, когда автофак, abp.volo, mongodb и динамические прокси castle сплетаются в бешеном танце таким образом, что разбор этого говна занимает 5-24 месяцев.
тут естесственно никакой дотнет не обновишь. На моей прошлой работе сидели на Framework 4.5.2 + windows server потому что вовремя не обновились, а потом уже поздно было.
Такая хуйня решается двумя способами, либо рубить этот узел нахуй, либо последовательно, выверяя каждый шаг решать через техдолг.
У нас все тормозит внутренний фреймворк блять. Почему-то каждый банк считает себя самым умным и начинает писать свои велосипеды.
Fluentvalidation? Нахуй надо сделаем свою реализацию и пахую что им пользуются 800кк проектов, есть гигатонны документации и решены и добавлены все возможные хотелки.
Маппер? Да не мы не будем использовать библиотеки и напишем свой.
Я даже видел попытки написать свою ORM, свои системы конфигурации поверх, а то и вместо .NET. Видел как люди писали ебучий редис, точнее копипастили блять его исходники, но немного меняя под свои шизобредни.
Естественно все эти говноебы необходимо поддерживать и если стандартные пакеты обновляют под новый дотНЕТ почти сразу после выхода, то времени обновлять копроворк тупо нет, надо делать фичи. При этом невозможно обновить конечный проект из-за зависимости от копроворка.
Особо видел ебанутую хуйню. Поцоны не использовали свойства, точнее использовали, но писали им геттер и сеттер, отдельными методами. Это тип для правильной архетуктуры и ограничений доступа и вот это вот все. Я задал вопрос знают ли они что такое свойства в С#, как они работают что означают надписи get set в их объявление, во что они компилируются и почему их возможно объявить в интерфейсе. Ответ был что-то в стиле "мням пук".
И это делали не какие-то джуны, сениоры и техлиды крупного банка, завсегдатые докладчики разных конференций, люди которые у меня на собеседование спрашивали какие книги я читаю по профессии.
Мы на новые версии в течении двух-трёх месяцев переходим, как только команда платформы под нее свои пакеты выпустит. Мы любим свеженький сахарок от M$.
Мимо-из-озона
Как поднять себя в глазах работодателя если до этогу писал всякую хуйню типо регеров, парсеров, брутеров, чекеров, тг ботов, игровых ботов с пиксель хантом. Не буду же я ему рассказывать как админки wp сканил, да и все остальное как то не солидно, чисто 1 функцию софт выполнял без особых наворотов.
Мб надо какой то проект написать что бы показать, только вот хуй знает какой, todo кажется какой то хренью.
>Маппер? Да не мы не будем использовать библиотеки и напишем свой.
Ну, вы долбоёбы, автомаппер вообще не надо использовать на чём-то большем чем пет проект, а вы сами в это говно лезете и ещё и хуже делаете. Фу, блядь, автомапер говно ебаное
Вот только тесты обошёл стороной.
Но всю эту хуергу учить это я еще 2 года буду
Всегда его пользую. Какие альтернативы ты предлагаешь? По 50 методов MapGovnoToMocha? Ну вот иди нахуй с такими предложениями, искать концы таких маппингов потом отдельный квест, особенно когда мудак забывает прописать новые свойства в них.
Автомаппер можно настроить так что он будет требовать явный маппинг всех свойств поэтому забыть что-то или не прописать будет невозможно на уровне построения схем.
Ну и у нас же эра микрозалуп, там всегда не больше 10-20 маппингов. Но тут можно и не использовать либы и писать руками, а вот когда их штук 300 то тут только централизованые схемы онли потому что по другому ебанешься всем этим управлять
>Ну вот иди нахуй с такими предложениями, искать концы таких маппингов потом отдельный квест.
Так говоришь, как будто автомаппер не усугубляет эту проблему. С ним вообще найти чего-то становится нереально, буквально приходится на бумажку выписывать маппинги, и тестами их закрывать. Вот, вероятно, ты им пользуешься по правильному. Но на моей практике 7 из десяти разрабов там полную хуету разводят, что хоть стой, хоть падай.
> Какие альтернативы ты предлагаешь?
хотя бы мапперли. Но не уебанский автомаппер, который уже лет 10 ненавидят и каждый год выходит по 3-5 статей, где у людей жопу порвало от того, как НЕ НАДО использовать АМ.
> особенно когда мудак забывает прописать новые свойства в них.
Init-only свойства делаешь и в хуй не дуешь. Компайл тайм сейфети
>Init-only свойства делаешь и в хуй не дуешь. Компайл тайм сейфети
двачую адвоката. сразу найдешь все места где нужно добавить. fail-fast рулит.
> Init-only свойства делаешь и в хуй не дуешь. Компайл тайм сейфети
Как это поможет избежать ошибок маппинга?
Не понимаю о чем ты, использую взломанную версию. Обновления скачиваю через vрn. С барином не пересекаюсь. Какая барину разница, что я использую его ide или нет? IDE - это просто инструмент.
Приведу аналогию. Допустим, кто-то сделал молоток и ты его используешь, строя баню. Внезапно, вы поссорились с мастром, который сделал этот молоток. Выбросишь ли ты теперь этот молоток? По-моему это глупо
Microsoft с его VS - это тоже западный барин, и тоже исполняет санкции
Даже, наверно, не так.
Вы поссорились с мастером, но тебе нравятся инструменты, которые он делает. Идешь на базар и ищешь, продает ли кто-то из людей (но не этот мастер) молоток, который сделал этот мастер. Покупаешь и используешь
Группы типо, как в Chromium браузерах? Такого не нашел.
Или ты про такую группировку (пик 2)? Она имеется (пик 3)
Даже создатель автомаппера не советует пользоваться автомаппером, если кроме случаев перегонки простых моделей в такие же простые без логики. В крайнем случае сложного в простое.
Но в большинстве случаев все начинают туда пихать и валидацию и бизнеслогики, в итоге чего получается неповоротливое неподдерживаемое нечто на тысячи строк в одном файле.
>Поэтому пишу на Rider, чтобы не вендерлочиться.
По моему райдер и решарпер в довесок к нему, как раз и есть дичайший вендорлок. Кучу раз встречал достаточно опытных разрабов которые в тех случаях когда приходится работать без него становятся беспомощными. В то же время слезть с того же VS и переключися на VSCode или тот же райдер ни у кого не вызывает проблем (ну кроме у совсем нубасов)
>Microsoft с его VS - это тоже западный барин, и тоже исполняет санкции
Между Microsoft и Джетбрейнсом есть небольшая разница.
1. IDE и софт не приоритетные направления для MS и они могут вполне забивать хуй в них на регуляторов в этом направлении, пока выполняют их в более приоритетных и масштабных (те же облака или корпоративка). Плюс майки сами по себе достаточно крупные, чтобы при необходимости прогибать решения в свою сторону. Для джетбрейнсов же это основная область деятельности, поэтому они и трясутся так, что выполняют все требования, плюс они по сути никто на большом рынке.
2. Макрософт базируется в США где во многих областях применим русский принцип про компенсацию строгости законов необязательностью их исполнения. Джетбрейнсы же находятся в европе, где вся эта регуляторка сильно ебанутая и там власти с упорством фашиков будут следить за исполнением всех этих санкций и законов, даже если это наносит явный вред им же.
3. Майкрософт прекрасно умеет в захват рынка и они прекрасно понимают, что вся эта хуета когда-нибудь кончится и когда они вернутся, то здесь будет куча новых и старых разрабов, которые намного лояльнее будут отностися к их IDE и к ним самим, чем к райдеру. А это важнее чем сиюминутные (в рамках их бизнеса) выгоды/потери от запретов.
Но да, никто не отменяет того варианта, что майки тоже могут в любой момент ебануться и перекрыть доступы к их продуктам.
>Microsoft с его VS - это тоже западный барин, и тоже исполняет санкции
Еще забыл добавить пункт, что джетбрайнс судя по высказываниям их представителей в публичном пространстве - идейные, а майкрософт интересуют только деньги. Что в данной случае добавляет им очков.
>Как это поможет избежать ошибок маппинга?
А откуда возьмутся ошибки маппинга, если ты не используешь Automapper?
Не надо героически бороться с проблемой, которую ты сам себе не создавал
Ты не прописал маппинг новых свойств. Теперь у тебя сыпытся ошибки из БД из-за null. Все это на проде. Твои действия?
если при добавления свойства что должно быть в бд не проверить хоть раз реально ли туда попадают данные - ну это нужно уметь.
А маппинг между всякими дтошками - ну просто не скомпилится код пока маппинг не пропишешь.
> Ты не прописал маппинг новых свойств. Теперь у тебя сыпытся ошибки из БД из-за null. Все это на проде. Твои действия?
А ты мастер перекладывать с больной головы на здоровую.
> если при добавления свойства что должно быть в бд не проверить хоть раз реально ли туда попадают данные - ну это нужно уметь.
Я же не тестер, чтобы что-то там проверять
> Ты не прописал маппинг новых свойств
Выкидываю автомаппер нахуй
> если при добавления свойства что должно быть в бд не проверить хоть раз реально ли туда попадают данные - ну это нужно уметь
Так а зачем если automapper просто обрушит приложение в момент запуска или попытки мапинга, что словят тесты.
Я не понимаю почему ты упорно хочешь писать маппинги руками и несёшь какую-то хуйню про выдуманые тобой же проблемы. Хочешь тратить по 2ч на тестирование кода и маппингов вместо автоматизации флаг тебе в жопу.
> Твои действия?
Собрать митинг, объяснять на пальцах КОНВЕНЦИИ, как правильно писать под автомаппер
> ты упорно хочешь писать маппинги руками
Ты так говоришь, как будто автомаппер эту проблему как-то решает.
Да ну нахуй это говно
https://www.reddit.com/r/dotnet/comments/sd5r4z/i_hate_automapper/
Знакомишься с тяночкой-мидлом/синькой. Все что ей там нужно где надо сладенько делаешь. Намекаешь, что хочешь в АйТи но не знаешь как. Она тебе все устроит.
Базарю. Сам так вкатился и половина друзей. Пока всякие задроты чет там по собесам ходили, чет там учили, какие-то стеки-хуеки. Я уже был сеньером с 5 годами опыта, 4 тяночка сказала приписать в резюме, а то несолидно будет.
Надо понимать, короче, что АйТи это же в первую очередь ЛЮДИ. Вот. Начни с тяночки айтишницы.
Единственное, если вдруг окажется мужик начальником - придется тяжело двигаться по карьерной лестнице, если ты, ну ты понял. Так что наводи справки о конторе куда пристраивать будут и если ты не готов - лучше искать другую тяночку и другую контору, где тяночка будет в руководителях. Но если, как говориться, у тебя бекенд рабочий и вообще ты не против погонять gRPC через свой шлюз - то все вполне может сложиться и в конторе где мужик руководитель.
>Но всю эту хуергу учить это я еще 2 года буду
Если опыта нет, то выучи самое главное:
дотнет - не сишарп, а именно дотнет, как эта технология изнутри устроена (Рихтер)
алгоритмы, сложность, О-нотации, хеш-таблицы, красно-чёрные деревья и всё такое
SOLID, Паттерны проектирования, DDD, паттерны проектирования микросервисной архитектуры (оутбоксы и прочее)
многопоточное и асинхронное программирование. Примитивы синхронизации потоков
SQL - транзакции, уровни изоляции, планирование схемы бд, нормализация-денормализация
Почему? Ты предоставил дерево знаний сеньёра. Тут похуй вообще, знаешь ли ты раббит, редис, фреймворки тестирования, сигналр, хенгфаер, кубер и прочее, от тебя как от джуна этого не требуется. То, что я написал - это база: дотнет, алгоритмы, паттерны, многопоточка и SQL, всё остальное - наживное
Как всегда школьный роадмап.
Сделаем асп.нет снова не масштабируемым.
Про Постгресс и SQL Server понравилось, SMM отдел одобряет.
да, ты крутой разраб.
задача: нам нужно выводить возраст пользователя
ты - добавил поле, ни разу не запускал, никуда не смотрел и сразу на прод
Но мы как нибудь по старинке - ХОТЬ РАЗ ЗАПУСТИМ ПРОВЕРИТЬ что добавленный код делает что надо.
>>3324034
>Я не понимаю почему ты упорно
тут двач и потому не видно - но с тобой спорят 2 оппонента. ну просто чтобы ты знал.
Впрочем, аргументы то одинаковые, а именно
>ты упорно хочешь писать маппинги руками
Неверно. Не хочу писать маппинги тайной магией. Написать можно явно руками (нет это не так долго как ты думаешь) или сгенерить всякими там мапстерами вроде.
>выдуманые тобой же проблемы
неявность маппинга - не выдуманная проблема.
>обрушит приложение в момент запуска или попытки мапинга, что словят тесты
>Хочешь тратить по 2ч на тестирование кода и маппингов
с required init код даже не скомпилится. и никакие тесты не словят ибо НЕ НАДО. И подправить маппинги явно не сильно хуже чем "оно как то само".
Microsoft активно переписывает отдельные части своих программных продуктов на Rust — более производительной и безопасной альтернативе С#. Портал MSPowerUser заметил на сайте компании вакансию для главного архитектора ПО Microsoft 365: он возглавит новую команду специалистов, которые перепишут с C# на Rust серверный код облачной платформы.
Даже мелкософт отказались от своего поделия лол.
о жавист забежал с протухшим говном.
уже давно напихали в ротешник им, но видимо наелись не все.
>ХОТЬ РАЗ ЗАПУСТИМ ПРОВЕРИТЬ
Ты ведь знаешь что есть проекты которые нельзя проверить руками или там слишком сложная логика чтобы её повторить.
Ты пишешь обычно юниты и на них орентируешься.
Ещё раз. Зачем тебе ебаться если можно поставить автомаппер и не иметь проблем?
>неявность маппинга - не выдуманная проблема.
Вообще считаю автомаперщиков какой-то отдельной кастой цыган, которые в бедных районах заводятся и начинают героином торговать. Все вокруг их ненавидят, но сделать ничего не могут.
>Ты пишешь обычно юниты и на них орентируешься.
ты уж определись проверяешь ли ты работоспособность нового кода или сразу в прод. А то ты прыгаешь со стула на стул.
>и не иметь проблем?
и иметь проблемы с автомаппером )))
и ты так и не пояснил каких таких проблем. (ну кроме того что ручками писать маппинги надо - ну так это не всем минус. ЯВНОСТЬ оно как бы плюс, required не даст тебе ничего упустить)
> если можно поставить автомаппер и не иметь проблем?
Я им раньше активно пользовался, потом разочаровался. Оказалось, он никаких проблем не решает, но усложняет чтение кода и рефакторинг.
А мне не нравится сомневаться в коде
Поэтому, обычно не поддерживаю автомаппинг, и местами переписываю на более простой подход.
Как результат добавляются гарантии компилятора, в том числе на безопасную работу с null. Начинает корректно работать подсветка сеттеров свойств, поиск кода, статический анализ.
Рефакторинг кода становится уверенный. Всегда можно удалить, переименовать свойство, изменить его тип.
Я никогда не понимал, зачем отказываться от сильных сторон С# и менять статику на динамику, зачем менять гарантии компилятора на ошибки в рантайме.
Автомаппер для меня это какой-то подход из лохматых десятых годов. Сейчас же разработка изменилась, и меня он скорее отталкивает чем привлекает. Тем более, что у АМ высокий порог вхождения, накладывающий свои требования на качество кода.
И судя по моему опыту он далеко не на всех проектах применим.
Посоветуйте нейросеть, которой скормить эту пикчу без СМС и регистрации, чтобы перерисовала в стиле?
Да и вообще, нахожу идею автомаппинга противоречивой.
Если в коде необходимо маппить множество одинаковых классов, то скорее всего проблема в слоях, вероятно перемудрили.
А если необходимо маппить разные классы, то достоинства автомаппера пропадают
Чаще всего необходимо преобразовать входное ДТО в объект или наоборот объект в одну из 10 разных ДТО под разные цели.
Также этот баран упорно игнорирует что я отключаю неявный маппинг и включаю требование чтобы все поля бы указаны явно.
Маппить приходится, когда у тебя DDD. В большинстве DDD у тебя есть какая-нибудь сущность которая ну вот центральная, у нее 100500 свойств. Иногда вообще доходит до того, что эта сущность не влезает в ограничения СУБД на число колонок.
Так вот. С точки зрения домена - эта сущность должна оставаться такой. Но с точки зрения этого же домена - прилетают какие-то промежуточные хуйни.
Ну, давай я для примера что-то просоте. Допустим что-то по автоматизации завода. Вот есть устройство. У него есть серийный номер. Номер на складе. Есть статус. Есть дата последней поверки, дата следующей поверки. Производитель. Версия прошивки. Протокол. Канал связи. Качество связи. Координаты жпс. Координаты глонас. Уровень сигнала. Шлюз через который оно подключено. Дата выхода на связь. Статус тревоги. И еще дохуя всего разного.
Вот. И клиент хочет чтобы это устройство как сущность - всем этим обладало.
Но в рамках вашей хуютки - с этой сущностью так и эдак надо взаимодействовать и от всей этой хуйни брать только часть. Штука которая опрашивает - хочет просто по id узнать, пора ли это устройство попробовать опросить. Штука которая обновляет прошивку - хочет только номер прошивки и тип устройства. И т.д. И у вас появляется дохуя моделей промежуточных, которые надо маппить.
Это я не к автомапперу, если что. А к тому что ну вот так вот случается, что часто в системе появляется такая сущность, которая дохуя всего имеет и ее хуй ты разобьешь, потому что никому это нахуй не надо в первую очередь, а во-вторую, что разбивая ты получишь связи 1 к 1, а это хуево и нахуй не всралось.
Это та статья где евангелисты раста обосрались. В общем, наверное в том году маркетологи увидели вакансии в 365 о расте, купили на левом сайте статью и начали носиться по всему инету, пока представитель того 365 сказал (топ коммент на редите) что они не являются мягкими и что там просто вакансии каких-то перделок.
Все что нужно знать про маркетинг раста, самого любимого языка (сколько там его любят? Лет 6 уже наверно)
жалко что джава превратилась в кобол.
Есть Blazor WA стандартное приложение в ней тестовая страница Counter
Код
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
Значение меняется после каждого нажатия, и вот вопрос, по выходу из метода не явно вызывается метод StateHasChanged() ? Или как Блазор узнаёт что пора обновить данные на странице?
Также как реакт. У него в памяти хранится полное дерево страницы и он её постоянно сравнивает с новым.
Ну да жпт чат рассказал. И сказал что StateHasChanged() вызывается не явно. Правильно?
А обновление страницы может случится пока метод еще до конца выполнен? К примеру запущен другой метод в цикле и он меняет страницу.
Либо проверка изменений идет всегда даже когда в приложении ничего не происходит?
Вот с этим совсем не понятно.
> я отключаю неявный маппинг и включаю требование чтобы все поля бы указаны явно.
На мой взгляд, это обнуляет всю идею.
Либо АМ по нормальному использовать (требование на одинаковые имена и типы свойств на всех слоях, никаких .AfterMap, все свойства маппятся неявно, КОНВЕНЦИИ), либо отказываться от автомаппинга.
>Маппить приходится, когда у тебя DDD. В большинстве DDD у тебя есть какая-нибудь сущность которая ну вот центральная, у нее 100500 свойств.
>Ну, давай я для примера что-то просоте. Допустим что-то по автоматизации завода. Вот есть устройство. У него есть серийный номер. Номер на складе. Есть статус.
Надо в БД положить модель ЗАВОД и написать на него микросервис. А автомаппер будет всё автоматически делать
В теории нет, но ObservableCollection не реагирует на изменение данных внутри другойколлекции, поэтому лучше использовать CollectionViewSource с группировкой данных по нужным полям.
чем тип, от которого НЕ ожидается необходимости следить за изменениями отличается от числа 42?
Через год?
Я шарп за две недели выучил. Правда это в ковидный год было, когда кругом шиза прогрессировала, все сидели по домам и делать было решительно нехуй.
От ABP.Volo на проекте требовался только базовый класс для DDD репозиториев МонгоДб. (забегая вперёд, в конце остался базовый класс на 300 строчек и экстеншены на 100 строк, чтобы его зарегистрировать в DI)
Чтобы инжектить этот базовый репозиторий, на проекте требовались динамические прокси, автофак, около 40 нугетов от самого ABP.Volo, и около 20 пакетов не связанных библиотек наподобие RestSharp, каких-то кешей и сериализаций всякой хуйни.
То есть, ты хочешь просто использовать класс, но в отрыве от фреймворка он не работает по двум причинам:
- фреймворк динамически перехватывает все вызовы собственных классов (sic!) и пытается вызывать их в контексте UnitOfWork, от которого напрямую зависит.
- Зависимости класса установить крайне трудно, потому что они ЛЕНИВО инжектятся в свойства (а может и не инжектятся)
Ну ладно. Плохое, тяжёлое, переусложнённое, но в целом работало довольно долго.
Так зачем я это делал? Потому ABP.Volo нельзя было обновлять ввиду ломающих изменений. Как следствие из-за него невозможно было обновить версию дотнета с 3.1. Так же заметил вторую неприятную особенность воло - разработчики часто решают, что они знают КАК ЛУЧШЕ и подменяют функциональность стандартного фреймворка. А ещё часть кода Volo написана в стандартных неймспейсах дотнета. Например, используешь метод из System.Collections.Generic, но на практике оказывается, что он не из стандартной библиотеки, а это кастомный код, написанный на рефлексии.
Удалял в несколько заходов, несколько раз заходил в тупик, потом откатывался до исходного состояния.
В итоге, остался очень доволен. Я получил контролируемый и предсказуемый ванильный asp.net core на базовом di контейнере. Любопытным бонусом было то, что наше приложение стало расходовать ровно на 100 мегабайт меньше оперативки. Ещё приятным бонусом стало то, что из автодополнения в редакторе IDE пропали случайные неймспейсы
В следующей версии буду обновлять сам дотнет до восьмого. Так же понял, что сама идея использования фреймворков всея руси мне чужда.
>разработчики часто решают, что они знают КАК ЛУЧШЕ и подменяют функциональность стандартного фреймворка.
Я бы за такое убивал. Попытки переписать .NET всегда выглядят как пиздец и робатают через жопу.
>3.1
Ебать тут проект проще с 0 написать.
Не нужен. Стандартный майковский DI давно уже умеет почти все, что нужно. Случаи когда было бы оправдано применение какого-либор стороннего контейнера исчезающе малы.
Я даже больше скажу, очень часто это вообще редфлаг, если кто-то без достаточного основания пытается протащить в проект такие вещи. Т.к. очень часто это либо просто синдром утенка, либо нежелание/неумение человека осваивать новые вещи и идти в ногу со временем.
Вон сейчас на хабре нашел свежую статью за прошлый месяц, где чувак на полном серьезе пишет вот такое:
>Одна из самых крутых фич в Autofac – это управление жизненным циклом объектов.
и показывает использования автофака на примере ASP.NET шаблона для .NetCore3.1.
Это, блять, в 2024-м году-то когда уже 9-й вышел, ну не пиздец ли.
>. Стандартный майковский DI давно уже умеет почти все, что нужно
юморист. майковский умеет только самый базовый базис начального уровня.
Некоторым этого хватает, например мне, но отрицать что он не умеет почти нихрена просто тупо. Ну то есть вообще нихрена. Ок, завезли keyed....ну и всё. Хрен с ними, с inject свойствами, но декораторы сколько еще будут делаться через костыли? А это ведь самые базовые вещи.
>на примере ASP.NET шаблона для .NetCore3.1
так а автофак тут причем? не вина автофака и других DI, что майки влепили свой DI в асп, тем самым вынудив лепить другие DI костыльным способом, что мало кому хочется. От этого автофак не стал хуже и майкоDI не стал лучше. ДЕФОЛТНЫЙ НЕ ЗНАЧИТ ЛУЧШИЙ - а значит ДЕФОЛТНЫЙ.
>ДЕФОЛТНЫЙ
И это заебись. Значит его поддержка будет вечной, а интеграция в сам фреймворк на уровне который невозможно повторить.
какая поддержка? он практически ничего не умеет и не развивается.
>на уровне который невозможно повторить
до асп.нет коре не было никакой возможности "повторять"
просто эти решения обладали "фатальным недостатком"
>но декораторы сколько еще будут делаться через костыли?
Ну хуй знает, что там сложного. Один раз написал экстеншен с использованием ActivatorUtilities.CreateFactory и потом используешь везде стандартные
services.AddScoped<IService, Service>();
services.Decorate<IService, ServiceDecorator>();
Для начала объясни зачем это. А то выглядит как классическая XY problem.
>А то выглядит как классическая XY problem
Наверно оно и есть.
Но я так пытаюсь освоить всю эту хуйню - пробуя писать другую хуйню.
В объявлении класса добавь where TKey : notnull. А словарь должен быть типа Dictionary<TKey, TValue?>, чтобы можно было default как значение пихнуть
Переписол. Лучше, но не совсем.
>А словарь должен быть типа Dictionary<TKey, TValue?>, чтобы можно было default как значение пихнуть
Так я не пихаю в словарь.
KeyValuePair<TKey, TValue?> везде юзай. У тебя для ссылочного типа default==null. Значит KeyValuePair должно позволять nullable значения содержать, значит тип значения должен быть TValue?
>умеет всё что нужно
>написал экстеншен
ну ты понял.
Я конечно бы взял scrutor, но и это костыли.
и это только одна функциональность из расширенных.
фикс
"одна функциональность из расширенных." - из базовых вернее. ибо у скрутора 3.7к звезд и 239 форков.Ну не хотят люди чет экстеншены писать на "никому не нужную и не базовую фичу"
>и это только одна функциональность из расширенных.
Да заебала уже эта расширенная функциональность в DI контейнерах.
У нас как-то потребность возникла переползти с автофака на более производительное решение. В итоге контейнер писали сами, с нуля, а каждая специфичная фича автофака нам поперёк горла встала.
Я сам автофак люблю, но на боевое решение предпочитаю брать решение с минимальным функционалом, но максимально совместимое с другими контейнерами.
По сути, от контейнера нужна потокобезопасность, скоупы и три вида лайвтаймов
От контейнера надо чтобы он в класс прокинул объект нужного типа. Больше нихуя не нужно никаких там функций и фич. Просто блять взять и просто прокинуть.
> автофака на более производительное решение
ну так переподзай на те решения что используют кодогенерацию. Они такие же - мало что умеют. Чего ты стесняешься.
А насчет расширенного... key фича вообще идет в разрез "правильным техникам", но ее впилили. А нужные всем декораторы, лол, они нужны даже тебе - их не впилили.
>>3326827
прокидывание прокидывание рознь. одному классу принимающему ILogger хочу подкинуть свой логгер? как? конечно ручным пердолингом. Не сложно, но ручное.
Ты пэйфон-девелопер, что-ли? Я вообще тотальный минимум не назвал, без которого просто это не работает.
Мимо сеньёр, который 4 месяца жизни въебал на это
Вот я делал какую-то базовую библиотеку. Ну, допустим MyApp.Application. Там определены базовые интерфейсы-типы и вся фигня.
Вот какая-то другая библиотека(Допустим MyApp.Infrastructure) использовала оттуда что-то.
Вот я решил что надо какой-то тип расширить. Добавил пару свойств-методов. Пересобрал базовую. Ту что использовала - не менял ника.
Надо ли мне пересобирать библиотеку которая использовала старую версию типа? Или если я только расширяю - все будет оки?
Просто вроде по логике - если только расширял - все должно быть ок. Но я помню как игрался с AssemblyLoadContext - и там вообще одни и те же типы между контекстами воспринимались как разные.
Че по этому поводу читать-курить?
Создай тестовый проект и проверь сам. Заодно нам расскажешь.
>Надо ли мне пересобирать библиотеку которая использовала старую версию типа
Надо. Иначе заебешься потом при сборке ловить "Package downgrade detected..." в неожиданных местах.
>Надо ли мне пересобирать библиотеку которая использовала старую версию типа?
Вообще, в идеале, надо просто пользоваться инфраструктурой msbuild, которая сама разрешает зависимости.
Судя по твоим словам, у тебя какой-то особенный случай. Рассказывай со всеми подробностями свою проблему с самого начала.
Кто тебе такую задачу дал? Они хотят от тебя избавиться.
Ну. Собственно, че рассказывать? Я хочу плагины. Плагины, ессно - не будут я каждый раз пересобирать. Они на то и плагины, их подгрузили и погнали. Если каждый раз надо полностью пересобирать - то я просто могу напрямую их рефами подкинуть и тогда нахуй оно и не нужно вовсе.
Но плагины же должны как-то с основной фигней работать? Должны. Вот им интерфейс, пусть встраиваются.
Но через какое-то время же интерфейс я расширю. И если плагин кто-то сделал, я не хочу чтобы этот чел ебал себе мозги, что типа бля, интерфейс пидорас поменял, мне теперь надо пересобрать всю хуйню, куда-то залить и все такое. Когда чел решит что ему надо что-то допилить в плагине - пусть тогда и пересобирает под новый интерфейс. А в остальном - было бы заебись, если его плагин бы работал как раньше, даже если я расширил интерфейс.
Нихуя непонятно че ты имеешь ввиду и что за шизобред несешь. Ну так впиши новые методы с реализацией по умолчанию и все.
Если есть реализация по умолчанию, то зачем мне интерфейс тогда? Тогда можно сделать класс какой-то уже нормальный.
А так - что непонятно?
Есть IPlugin, Есть IHostApplication. П
лагин - простой.
Хост - будет расширяться, и берется плагином, чтобы иметь доступ к остальному приложению и, собственно - встраивться или дергать какие-то ну совсем общие функции, типа дай мне окно выбора файла, или еще чет, что всем может быть нужно.
Ну. А плагины, как уже сказал - на то и плагины. Я написал его и забил. Один раз собрал, проверил, положил куда-то и если надо - докидываю к основному приложении. В идеале - он должен работать пока базовый интерфейс не поменяется настолько что уже несовместим. Но тут-то он совместим получается, просто новые методы добавились, старые ни сигнатуру ничего не изменили.
class HightScoreList
{
private List<int> ScoreList;
public HightScoreList ( List<int> scoreList)
{
this.ScoreList = scoreList;
}
public List<int> Scores() => ScoreList;
public int Latest() => ScoreList.Last();
public int TopScore() => ScoreList.Max();
public List<int> TopThree() => ScoreList.OrderByDescending(score => score).Take(3).ToList();
Честно говоря х.з. почему ты вообще такие вопросы задаешь, если все это проверяется экспериментально.
>private List<int> ScoreList;
>this.ScoreList = scoreList;
Ты по устаревшим книжкам учишься. Так уже давно никто не пишет.
Потому что по одним моим экспериментам - ок. А по другим - не ок. И понять, это я делаю что-то не так в других случаях, или поведение не гарантированно просто экспериментом я не в состоянии. Тут нужно спеки читать, как там CLR со всей этой хуйней работает, как работают эти ебаные домены-хуймены, лоад-контексты короче, дофига всего.
А я просто хочу плагины и беспокоюсь...
>А я просто хочу плагины
Ну сорян, чел. Тебе уже сказали, что плагины - это нихуя не просто, поэтому по любому придется
>"спеки читать, как там CLR со всей этой хуйней работает, как работают эти ебаные домены-хуймены, лоад-контексты короче, дофига всего"
PS. Я как-то работал на проекте с плагинами. Причем там можно было подключать не только шарповые, но js плагины. Но с тех пор уже три года прошло и я благополучно всё это нахрен позабывал, да и касался я того функционала краешком только.
И вообще, что за пиздец? Почему у тебя в сервисах модель?
Потому что в моем понимании - модель это какой-нибудь сервис... Еще со времен WPF.
UserListViewModel, моделью принимает UserService. Не одного же пользователя мне в целую вью-модель запихивать.
Я просто не хочу каждую вью-модель руками в DI пихать, и тем-более руками создавать. Затрахаешься потом следить за всей этой хурмой.
>UserListViewModel, моделью принимает UserService. Не одного же пользователя мне в целую вью-модель запихивать.
Если планируешь менять свойства пользователя, то именно что для каждого пользователя свою вьюшку. Иначе просто в модели представления страницы получаешь сервис пользователей и из него этих пользователей запрашиваешь. Но это будет именно сервис, а не модель
Я вот например делаю так (пик)
>>3327818
Я бы согласился на самом деле, если бы рядом со мной не сидел сеньер-помидор, который считает что этот ваш DI придумали пидорасы и гомосеки, и все надо через статические классы делать... А через них дохуя чет выходит делать если еще и лоулевельные сущности надо в вью-модели и им еще и модели доставлять...
>Потому что в моем понимании - модель это какой-нибудь сервис
Твоё понимание хуйня. Модель это модель, класс без логики для хранения данных. Есть ViewModel это модель твеого View там пишут логику кнопочек и прочей залупы, туда же прокидывают сервисы.
Смотри что у тебя должно быть в голове.
>я неявно куда-то инжекчу типы
>я написал хуйню
>я удалил хуйню
> Твоё понимание хуйня. Модель это модель, класс без логики для хранения данных.
Модель вполне может содержать логику, как бы не спорили с этим любители вынести всё что можно в сервисы.
> Модель это модель, класс без логики для хранения данных
И каким фигом тогда ты обновишь значение в БД этой модели? Из вью-модели в БД полезешь? Совсем тю-тю? Или у тебя приложение уровня - открыли, закрыли, потеряли все состояние?
Суть. Ты либо сервисы прямо во вью-модель инжектишь, либо делаешь рич-модель. Рич модель - хуйня, потому что быстро жиреет. Потом ты с ней не совладаешь. Я уже посидел на жавовских проектах, где были фанаты рич моделей и больше не хочу.
Варианты с магическими евент-басами, которые мне сообщение во вью-модель пришлют что что-то там обновилось и надо обновить вью-модель - идут нахуй, потому что флоу в крупном приложении превращается в неуправляемое фиг пойми что.
> И каким фигом тогда ты обновишь значение в БД этой модели?
При помощи сервиса конечно.
Обновил свойства в вм -> смапил вм а модель -> в сервисе обновил данные БД.
Первый вариант - вообще не вариант а обоссаное говно. Вью-модель гвоздями прибита к модели и сервис-провайдеру. Работать просто не будет потому что модели магическим образом не появляются из контейнера. Модели появляются из сервисов, репозиториев, но не из DI. Так же, куски контейнера во вью-моделях редко бывают оправданными
Второй ещё более менее реалистично выглядит, но он умалчивает все детали
Собес вообще странный был, проходил всего лишь 30 минут. Спросили про join'ы и индексы, stringbuilder, list<T>, hashcode и ооп. Ни асихронщины, ни треды, ни ef core, ни asp.net core, ни паттерны. Хотя вакансия была на мидла, думал будут гонять по всем темам.
Но боюсь, что не справлюсь с изучением кода, ведь там большой 8-летний проект. Сложно ли происходит онбординг?
Создать из существующего листа. Например, обернуть существующий private лист в readonly для пользователя.
Через AsReadOnly(). В отличии от IReadOnly интерфейса, нельзя будет задаункастить обратно к листу. В прочем, кому не похуй.
Этот метод аллоцирует новый массива под список и копирует его.
>В прочем, кому не похуй.
Я когда проходил тестовое задание, написал геттер, который возвращал ReadOnly словарь через конструктор ReadOnlyDictionary. Мне сделали замечание, мол данный способ аллоцирует лишнюю память. Ну вот мне стало интересно, есть ли способ это сделать без тупого приведения к интерфейсу. Использовать Span'ы?
>Ну вот мне стало интересно, есть ли способ это сделать без тупого приведения к интерфейсу
Приведение единственный способ сделать это без аллокации памяти ну и да. В ответ на такие вопросы надо спрашивать нахуя они пишут на С# если им нужно память экономить, пусть тогда на С++ конструкторы переноса пишут и прочую залупу.
Экономисты сука которые пишут ебаную лапшу чтобы выиграть 1Мб памяти. Помню джун начал выебываться что я написал двойной цикл а это же N² можно было nlogn. Пришлось ему популярно объяснить что моё решение занимает 6 строк кода 2 из которых объявления циклов, а его решение это написать 30 строк кода и все это ради экономии времени на массиве в максимум 100 элементов в красный день.
Потом кстати написал бенчмарки и выяснилось что из-за предварительной сортировки данных NlogN в 4 раза медленнее N² на целевых размерах.
Люди забывают иногда что O нотации имеют ввиду бесконечные наборы данных, а в реальности на мелких наборах иногда даже N³ быстрее хитрых еба алгоритмов. Тут тоже самое, возможно и есть какие-то варианты без приведения к интрфейсу, но в реальности нахуй это никому не надо и является скорее эзотерической фичей которую никто не делал специально.
>топ 1 язык (на данный момент) по созданию десктоп приложений?
Да. Правда сами десктоп приложения практически мертвы и мало кому нужны.
>>3328558
>вкатунам легко найти работу в рф?
Нет, сложно.
>Сложно ли происходит онбординг?
Зависит от конторы. Где-то тебе будут попку вытирать все три месяца объясняя каждый пук, а где-то просто бросят в воду без всякого онбординга и прикажут грести фичи на прод, срочно-срочно.
Из советов. Первым делом изучай базу знаний. Получай доступ в конфлюенс, редмайн, джиру, репы и т.д., любую хуйню в которой хранится информация и изучай то, что там есть. У меня были случаи когда я приходил на проект и меня все уверяли, что доков нет и понять как работает система можно только ковыряясь в коде. И через пару часов копания в кофлю, я находил полноценную документацию в которой были описаны все ньюансы и детали. При этом это даже не легаси, проекту было всего года 3, на относительно свежем стеке. Просто постепенно успела вся команда обновиться, а новенькие полагались исключительно на слова тех, кто был до них и им лень было поднять зад и поискать инфу.
>>3328512
Не пизди, ничего он не аллоцирует.
значит уже не "ничего"
а так несколько миллионов миллионов "ничего" и уже "чего"
Я начал изучать VBA еще с CorelDraw и Rhinoceros. Потом перешел на VB, а потом на C#. В какой-то момент я смотрел доки и получал советы на C#, при этом сам писал на VB. Там отличия незначительные, в основном касающиеся синтаксического сахара. Ты даже можешь один проект или либу сделать на VB, и подцепить ее в другой проект на C#.
Интересного в шарпе ничего нет, просто он популярнее.
>VB, а потом на C#
Ну как бы выбор для тебя очевиден. Просто как думаю знания c# будет как то по солиднее выглядеть в резюме
Если ты захочешь устроиться в шарашкину контору, то можешь выпендриваться знаниями солидного языка. В остальных случаях от тебя ожидают результат, а не способ. Мне ИТТ мозги проели насмешками над бейсиком, но какой толк от шарпа, если мне негде его применить в своей области? Это уже потом рино и корел начали поддерживать шарп, а так бы я продолжил сидеть на бейсике.
Ты должен идти по наименьшему сопротивлению. Если ты вообще нулевой, а твое твое приложение больше дружит с VB и есть куча примеров, на которых можно учиться, то лучше учить VB. Зная VB, перейти на C# — дело одной недели. Синтаксис это не самое страшное, он тебе не поможет. Для каждого приложения придется учить свой api. Зная как писать для одного приложения, ты обосрешься в другом. C# в Unity это не обычный шарп, там своя атмосфера. Тоже самое с C++, в связке с UnrealEngine он вообще другой.
Поэтому не парься, учи базу на любом языке, потом постепенно сам поймешь куда двигаться.
Скоро нюки полетят, и двигаться придётся к ближайшим складкам местности.
Чего?
А не проще один интерфейс реализовать для разных платформ?
>в результирующей сборке будут все варианты и пользователь библиотеки будет линковать только один этот файл?
Нет, только тот что нужен.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives
Это инструкции для компилятора, в билд то что не нужно просто не пойдёт.
Таких зарплат больше не будет. Пакистанец берёт 2000 и не ебёт мозги микросервисами.
Я поэтому из европы свалил, они там оптимизировались знатно
Таблетки шиз, или сразу нахуй в /b где таким ебанькам самое место.
В проекте можно выбирать какие платформы поддерживает сборка, в зависимости от них по макросам будет разруливаться что откуда брать.
>Таких зарплат больше не будет.
Уже нахожу варианты на +-5.
У меня маленький налог, своя недвига, я не в дорогой/налоговой Германии/Франции/Англии. Так что меня не передемпингуешь.
Но серьёзно, в каком направлении развиваться? Мышинное обучение?
Сап шарписты.
Вопрос такой, как определить, что я уже владею языком и можно переходить к изучения следующего?
Начал изучать с 2019 года, прошёл несколько курсов и прочитал много книг, создал около десятка маленьких игр, одну выпустил в стор.
Никогда не работал на дядю, коммерческие приложения не создавал.
Могу придумать алгоритм или решить несложную задачу, из ООП использую только инкапсуляцию, очень редко наследование.
Думаю освоить java или python. Работаю не в айти сфере, программирую, для хобби.
>Вопрос такой, как определить, что я уже владею языком и можно переходить к изучения следующего?
Пожалуйста, проходи мимо, изучай что-нибудь для дебилов типо пейфона
>Никогда не работал на дядю, коммерческие приложения не создавал.
и не надо тебе этого, проходи мимо.
> python. Работаю не в айти сфере, программирую, для хобби.
Вот этой пластмассовой хуйнёй и займись, в дотнет не лезь. Чувствуй себя настоящим программистом на пейфоне.
Ну, по сути прикольный у тебя проект, если такое написал и нравится - учи базу, обязательно работу найдёшь, но не сразу
>Пожалуйста, проходи мимо, изучай что-нибудь для дебилов
>и не надо тебе этого, проходи мимо.
Наверное я сам решу проходить мне или нет.
>типо пейфона
Это что-то на эльфийском?
Здесь задан простой вопрос. Вот я, владею этим и вот этим, этого достаточно, чтобы идти дальше в изучении языков?
Что я ожидал.
>Да, достаточно, но можно освоить то-то и то...
>Нет, этого недостаточно, потому что...
А вот фразы
>Вот этой пластмассовой хуйнёй...
Никак не способствуют в понимании ответа на поставленный мною вопрос.
>Наверное я сам решу проходить мне или нет.
Нет, за тебя будут решать такие люди как я, которые будут тебя собеседовать. Тебе дотнет не нужен, ты очень тупой
> Вопрос такой, как определить, что я уже владею языком и можно переходить к изучения следующего?
Ок. Вот тебе список вопросов.
Без гугла и GPT ответь на них.
1. В чем отличия Task от Thread?
2. Как сделать возможным использование await для собственного класса?
3. Чем будет отличаться вызов Foo(ref someObject) от Foo(someObject)?
4. В чем отличие сборки мусора для объекта реализующего финализатор явно от объекта не реализующего его?
5. В чем отличие:
```
var a = [1,2,3,4,5].Where(x=>x>3);
```
от
```
var a = Array.FindAll([1,2,3,4,5], (x) => x > 3);
```
6. Можно ли делать вот так:
```
Dictionary<string, object> myMap = new()
{
["Key1"] = 1,
["Key2"] = 2,
};
foreach(var it in myMap.Keys)
{
myMap[it.ToString()] = myMap[it];
}
```
7. Как выделить объект на стеке?
8. Что произойдет:
```
Action action = () => {};
for(int i = 0; i < 10; i++){
action += () => Console.WriteLine(i);
}
action();
```
9. Дан код:
```
public static Foo(){
Console.WriteLine("Hello from Foo");
}
```
Как не модифицируя метод Foo сделать так, чтобы при его вызове вывелось "Hello from Bar"?
10. Чему будет равно: byte a = 254 + 255 + 256 + 257 >> 10 | 64; При условии, что в проекте отключена проверка на переполнение?
2 зачем знать это без гугла? это не каждодневное. большинству это нужно 0 раз в жизни
7 можно с помощью магии сконструировать объект класса на стеке. какой вопрос - такой и ответ.
9 на какой версии дотнета?
10 битовая магия. сишник что ле?
Чем дженерик отличается от шаблона класса и почему эта разница важна?
1. Thread - ресурс операционной системы, который позволяет выполнять код параллельно. Task - высокоуровневая абстракция над thread, которая работает с пулом потоков, который создает CLR.
2. Указать в сигнатуре метода ключевое слово async ??
3. В первом случае передастся сама ссылка в метод, во втором - скопируется в метод.
4. При явном объявлении деконструктора можно явно указать, какие объекты нужно уничтожить. Например, из неуправляемой кучи при работе с файловой системой, драйверами и соединениями.
5. Первое - ленивая обработка, вторая делает это сразу при вызове метода.
6. Не, словарь выкинет ошибку, что ты суешь одинаковый объект.
7. stackalloc, но требует включение возможности небезопасного выполнения кода. Или можно использовать span, если работаем с коллекцией.
8. Выведет 9 или 10 раз цифру 10. Привет, замыкание.
9. Наследование?
10. Ну это уже нюхание пердежа. Такое я считать не буду.
Что такое шаблон класса, лол? Сам выдумал этот термин? Ну немудрено, что все валятся.
>Ну это уже нюхание пердежа. Такое я считать не буду.
Там 80% поста это нюхание пердежа.
я не автор теста, поэтому только часть ибо вычислять код в голове влом
1 Таска НЕ абстракция над thread. Это просто абстракция.
2 реализовать GetAwaiter + INotifyCompletion
4 что делать внутри финализатора это уже дело второе. А первое - что объекты с финализатором не будут скушаны сразу же, а позволят выполнится финализаторам (причем в другом потоке)
7 думаю тут вообще про структуры
9 наследовать статический метод? шарп вам не это. а жаль
Зачем ты челику загадки загадываешь? Он же очевидно ВЫУЧИЛ дотнет не написав на нём ровно нихуя, а теперь хочет ВЫУЧИТЬ что-то следующее?
Типо, я бы вообще в ебало за такое бил. Ну выучи ты информатику, если интересно, как разные технологии работают. Нахуя язык учить, если пользоваться не собираешься? Нахуя тратить свое время и время уважаемых донов? Я тут вообще пришёл сюда ваших мамок обсуждать.
Ебать, неуважение. Сука, блядь, ппоридж вонючий, настроение мне испортил. Пойду в котлин-тред спрошу, что у них с ебалом
Когда ты тупой вкатун лучше молчать
https://www.ibm.com/docs/en/i/7.3?topic=only-class-templates-c
Так без точки и есть опенсорс. Можешь хоть сейчас пойти предложить свои коммиты в репу. Есть даже челы которые так попали к ним на работу.
Но знаешь в чем проблема? Ты слишком тупорылый чтобы выдать туда что-то дельное.
Ну и какой же ответ?
Ты у шарписта спрашиваешь про C++ные темплейты? Очередной интервьюер-долбоёб?
Почитав соседние посты - пиздец тут у местных "невкатунов" чсв.
Нет, он из тех долбоёбов, которые утверждают, что все настоящие программисты обязаны знать C++.
>наследовать статический метод? шарп вам не это. а жаль
Точно. Совсем забыл. Тогда использовать паттерн декоратор тоже не получится?
>2 реализовать GetAwaiter + INotifyCompletion
Ну тут я совсем вопроса не понял. Что это значит?
Алсо хотел уточнить по поводу сборщика мусора. Dispose стоит применять только при работе с idisposable управляемыми данными. Но разработчик может и забыть использовать его. Почему бы не сделать финализатор, где будем вызывать этот dispose, или вовсе переместим всю функцию в финализатор?
>Алсо хотел уточнить по поводу сборщика мусора. Dispose стоит применять только при работе с idisposable управляемыми данными. Но разработчик может и забыть использовать его. Почему бы не сделать финализатор, где будем вызывать этот dispose, или вовсе переместим всю функцию в финализатор?
Потому что разные задачи.
Dispose нужен для "ручного" освобождения ресурсов - хоть x.Dispose(), хоть через using. Логика простая - ты вызываешь Dispose() в основном классе, а дальше он сам освобождает ресурсы, включая неуправляемый или вызов других IDisposable. Финализатор же нужен для освобождения ресурсов во время сборки мусора. А сборщик мусора не гарантирует что объект удалится сразу.
>Почему бы не сделать финализатор, где будем вызывать этот dispose
Тащем-та так и рекомендуется делать. У нас на проекте код даже не сбилдится если ты реализуешь IDisposable не по комбинированному шаблону.
Нет больших русофобов, чем российские эмигранты. Ведь надо же оправдывать в своих глазах эмиграцию
>Тогда использовать паттерн декоратор тоже не получится?
ну вообще в шарпе сделали кое какие интерфейсы для статиков, а также всякие там сорсгенераторы с AOP, но что хочет автор вопроса - хз
>Ну тут я совсем вопроса не понял. Что это значит?
это значит что можно сделать awaitable не только разные там Task/ValueTask
https://devblogs.microsoft.com/pfxteam/await-anything/
сложно сказать зачем это нужно. У меня сделано 2 класса хелпера где оно нужно - потерять контекст синхронизации и найти его
и чтобы продолжение после этого await исполнялось либо без контекста синхронизации, либо с ним.
короче образно
...UI поток
await DetachFromSyncContext()
...тут уже работает пул
await RedirectToUIThread()
...и снова UI поток
>Почему бы не сделать финализатор, где будем вызывать этот dispose
и это будет костыль. потому что весь idisposable паттерн хрень ибо не решает сам по себе проблему "забыл". А вот нечего забывать. поэтому "да здравствуют лайфтаймы"
>сложно сказать зачем это нужно.
Незачем.
>У меня сделано 2 класса хелпера где оно нужно - потерять контекст синхронизации и найти его
На какой хуйне ты пишешь что тебе приходится свои костыли под синхронизацию писать. Не, серьёзно, это зачем?
>На какой хуйне ты пишешь что тебе приходится свои костыли
десктоп же.
и это не костыли для синхронизации. Это альтернативный сахар вместо всяких там DispatcherHelper
Имея бэкграунд разработки на другом языке, тем более ООП, в шарпы ты вкатишься быстро.
>Финализатор же нужен для освобождения ресурсов во время сборки мусора
А можно пример таких ресурсов? Какие ресурсы может потребоваться освобождать когда-то в каком-то потоке?
Извините, я тупой вопрос задал. Отличный пример таких ресурсов - хохлы
Дотнет порвал всех даже c реалокацией листа и без ValueTask
Круто, чо. Только когда еще на 9-м поработать можно будет. Тут хоть на 8-й бы пересесть.
не особо нужно. пихают всякую дрянь, а банальные AsyncReaderWriterLock за охулиард лет не дождемся
Перекатываюсь в C#, иду на джуновскую вакансию через пол года и в хуй не дую (т.е. нихера не делаю, кроме как фиксить опечатки в коде).
Мнение?
https://2ch.hk/pr/res/3332445.html
https://2ch.hk/pr/res/3332445.html
https://2ch.hk/pr/res/3332445.html
https://2ch.hk/pr/res/3332445.html
https://2ch.hk/pr/res/3332445.html
сам ты херня. компоуз няшка
с корутинами ты прав - таски на 10 порядков проще хоть и требуют async/await, да и плагина под андроид студи как под идеа нету чтобы стектрейс правильно видеть
с гредлом в точку. ломается на ровном месте и хрен пойми
>Мнение?
ну шарп не такой выразительный как котлин. так что если ты не ремесленник будет тебе немного жопаболь
>ну шарп не такой выразительный как котлин
Что за категория такая, "выразительность"?
Почему её используют только в контексте котлина? Это точно не слово из маркетингового буклетика, которое не означает ничего?
