Приятного общения ИТТ.
Главные темы - IReadOnlyList, Enum и BackingField
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
Прошлый тред: >>3332445 (OP)
https://learn.microsoft.com/ru-ru/dotnet/fundamentals/networking/overview
Но там опять таки тисипи/айпи. А мне, я так понимаю, нужно ловить все входящие езернет-кдры и из них выбирать нужные, и также в эзернет отправлять согласно тому протоколу свои кадры. Повторюсь, никаких тисипи/айпи.
И судя из того что на тему работы напрямую с зернетом на C# ничего негуглится, у меня, как у ньюфажины, складывается впечатление что это и не возможно. Подтвердите что это так или скажите где смотреть.
Тебе нужен С/С++ и уровень ядра. Сишарп - это про асинхронные пуки в кафку.
То есть никак? Хорошо. Тогда если на С/С++ скомпилировать библиотеку и потом её подключить к C#, прокатит?
Нужна интеграция с CI/CD
Запись видео сценариев
Не знаю, как к нему подступиться. Думаю выбрать Selenium и использовать какую-то программу, например ffmpeg. Но боюсь, что могут возникнуть проблемы с linux и докером.
Можете подсказать, что лучше использовать?
Для диплома надо было брать самую простую тему, а не интересную. Потом 20 раз пожалеешь.
Если он планирует дальше учиться надо брать какую-то тему для дальнейшего развития в кандидатскую.
>Если он планирует дальше учиться надо брать какую-то тему для дальнейшего развития в кандидатскую.
Ну и будет такое же дрочево с дипломом. Плюс к моменту завершения кандидатской тема моржет оказаться уже неактуальной (особенно в айти-то). Для кандидатской нужна тема с реальной работы решающая реальную проблему. Ну или решающая реальную теоретическую проблему, но это тоже не уровень диплома.
>ема моржет оказаться уже неактуальной (особенно в айти-то).
Как вы заебали. Ваши фреймворки не имеют блять никакого отношения к Информационым технологиям.
Если твоя кандидатка это не говно из допы её актуальность будет ВЕЧНОЙ. Кнут пишет свой труд уже 60 лет и первый том актуален как никогда. В ИТ за 70 лет ничего особо не изменилось в базовых вещах. Все твои фреймворки и подходы типо ДДД и аджаил созданы 30 лет назад.
Так у него браузерный кал, самое дно в программинге.
>>3347713
Проиграл, а дохтурскую ты на пехепе собрался защищать?
Максимум что можно сделать из шарпа это дергать winapi для такой низкоуровневой работы с сетью но это такой жуткий гемор что лучше сразу плюсы брать, ибо дергание winapi из шарпа - это пиздец. Из вариков только WinDivert смотреть, мб там есть врапперы для шарпа, но наверняка не знаю Если речь идет о Линуксе то вообще пизда, лучше сразу брать scapy из пистона
Братан, ты пиздец взял, целый microsoft свой playwright 3 года дрочит чтобы сайты кросс-платформенно тестить а ты решил соло это для диплома сделать? Лучше ебашь CRUD-ы если еще можешь поменять тему или в целях работы заранее уточни что-то чтобы снизить градус амбициозности
он может сделать обвязку над playwright
как над тем же селениумом.
никто не ожидает что он свой селениум напишет
а что то типа "я нажал на кнопку оно тестируется, красиво отчеты рисует"
>Если речь идет о Линуксе
О винде.
>WinDivert смотреть
Я нуфаг и даже не представляю что это такое.
>дергать winapi для такой низкоуровневой работы с сетью но это такой жуткий гемор что лучше сразу плюсы брать
Поясни кратко в чём там принципиальная разница .
>>3348245
Ну из выбора у меня была унылая машинка на притоне и друга муть, завязанная на математике и робототехнике. Это самая интересная тема была и близкая ко мне.
У меня вопрос, как все это сделать. Как записывать экран? Я знаю, что в Selenium можно делать скриншоты headless браузера. Думаю, склеить их вместе, например, с помощью ffmpeg. Как это будет работать в github actions, докере и етс? Просто не хочу, чтобы случилось так, чтобы весь труд пошел насмарку, когда выяснится, что это не работает где-то.
А нахуя ты это спрашиваешь у продуктовых разработчиков, которые с этой поебенью целыми днями ебутся?
Я вот пришел сюда твою мамку хуесосить и отдыхать душой, а не за студентов дипломы писать.
Посмотри сорцы Selenoid, они такое делают. Вроде как стримят видео из браузера подключённого к виртуальному дисплею (или из самого виртуального дисплея я хз) через ffmpeg.
либо они не срабатывают на вопросительном знаке:
some?.object.Should().Be(false);
либо стреляют с NRE, что не информативно.
И вообще, все эти билдеры и закосы под английский язык нахожу уебанскими.
ну чисто по приколу, так для себя кидает человек ресурсов, что такого?
Подскажите, только начинаю изучать программирование, думаю связаться и начать "Kotlin", норм варик?
pls pls
>И вообще, все эти билдеры и закосы под английский язык нахожу уебанскими.
вот вот. программисту проще читать код (банально мозг отформатирован на чтение именно кода), а эта англоязычная херота она для тестеров придумана, а не для нормальных людей
Если тебе нужен выразительный язык - смотри в сторону котлина.
Всё остальное есть в c#
NUnit мне не нравится. Это комбайн всё-в-одном. А еще в нём нельзя управлять жизненным циклом самого теста/тестового класса/сборки.
В принципе сейчас в этом плане xunit единственный, который по нормальному устроен. Он модульный и состояние по умолчанию не переносит из теста в тест
Беда с обновлением компонентов(server):
Есть две ссылки на одну страницу, в ссылке передается Id. Компонент отображает таблицу с данными, отбирая их по Id. Если тыкать по разным ссылкам с другими компонентами, чередуя их - то компонент таблицы обновляется нормально. Но если открывать один компонент таблицы по ссылкам с разными Id, то отображается только таблица, которую открыли первой. Повторное открытие страницы с компонентом с другим Id не обновляет данные. statehaschanged не помогает.
Смотрю я этот TUnit
> Property injection
нахуя?
> Dependency injection support
нахуя?
> Native AOT / Trimmed Single File application support
ну тысячах на ста юнит тестах, вероятно, будет полезно
> Parallel by default, with mechanisms ...
круто, конечно, но это для очень высокоранговых разрабов
> Hooks before and after
годная штука по идее, но, вероятно, если есть необходимость гонять хуки - то тесты спроектированы неправильно
Ну шустрее немного. Но ввиду того, что они поддерживают только восьмой фреймворк - без вариантов, пересаживаться на него не имеет большого смысла
> только восьмой фреймворк - без вариантов
плохо быть тобой.
а зачем это всё - узнаем по отзывам когда оно выйдет. без тулинга оно не нужно. Да и релиза первого не было.
И какая адресация, чел? Ты понимаешь, что IP - это считай базовая база, поверх которой все остальное работает?
Или у тебя взаимодействие в духе - вот провод подключен я по нему нулики-единицы гоняю?
Если есть адресация - значит будет IP - стек. А значит берешь сокет, ручками собираешь пакет и погнали.
Если ее нет - у тебя будет ком-порт и ты пишешь-читаешь как из файла.
Все. Не тупи.
>Ты понимаешь, что IP - это считай базовая база, поверх которой все остальное работает?
Вот так да, даже и такие бывают...
Малыш, ты что-нибудь про МАС-адреса слышал?
Ой, ну не начинай.
Я на 146% уверен, что чел просто неправильно понял задачу и потому лезет куда не надо.
Учитывая мой опыт работы с заводами - там Ethernet'ом называют свою библиотеку для работы с тем самым TCP/UDP, дальше оборачивают это в свой HDLC-лайк или Modbus-лайк протокол. Никто там не лезет в залупу. Потому что надо железки продавать, а не изобретать велосипеды. А железки сейчас покупают из принципа - я тут самые дешевые купил, там еще дешевые купил они должны все подружиться, если это не дружится с остальным нормально - идет нахуй.
А когда в нее лезут - зовут тех кто шарит, а не чела, который такие вопросы задает.
Если ему реально надо - пусть берет питон, у питона дохуя пакетов для работы хоть с маком, хоть с хуяком.
> плохо быть тобой.
Я свои проекты перевёл на восьмёрку этой осенью, с версии 3.1.
Но мои коллеги буквально клали хуй около 4 лет на обновление. И таких проектов много.
Буквально люди не понимают, что "окончание поддержки" фреймворка - это буквально окончание поддержки в том числе и сообществом.
Знаю проект, который не хотели обновлять с фреймворка 4.5.2 и даже попытались "переписать на микросервисы". Правда, получилась хуйня и они просто понаписали кучу синхронизаторов вокруг старого проекта, и в итоге всё равно пришлось переписывать основной проект на дотнеткор+докер.
А разработчикам tunit ничего не мешает буквально выставить 2 числа в проекте, чтобы подарить возможность его использовать значительному количеству разрабов.
А один факт поддержки только последнего фреймворка как бы намекает на уровень авторов.
И как вишенка на торте, разработчик tunit повторил ошибку nunit и вкорячил уродливые nunit-подобные ассёрты непосредственно в запускалку тестов.
Это чтобы разрабы сразу подключили fluent-assertions, передрались и друг за другом начали ассерты переписывать на "правильные".
Я чем больше смотрю на внутреннюю архитектуру xunit - тем больше охуеваю с того, какой он классный. Взять хоть IDisposable
И ещё одна вишенка на торте, там утырок не поддерживает не асинхронные тесты.
Там даже ассёрты возвращают таски
[Test]
public async Task MyTest()
{
await Assert.That(1).IsEqualTo(3);
}
Да говно там из пальца высосанное, которое только долбоёбам заходит, которые кичатся знанием английского кичатся.
price.Assert()!.Is!.That()?.Equals["to"]?(1);
Я помню, был один еблан, он думал, что код на английском языке пишет. Ему ответили, что он на c# пишет.
>А один факт поддержки только последнего фреймворка как бы намекает на уровень авторов.
намекает на желание быть "на острие", а не поддерживать устаревшее говно.
как пользователь софта - я бы осудил, как программист - понимаю, ибо сам такой.
хз о чем ты. tunit, похоже, имеет только fluent подобные assert
и обычных не имеет (что лично для меня плохо - я пишу код, а не свитки)
Я о том, что nunit включает в себя ассёрты с очень специфичным синтаксисом, и отключить их невозможно.
Большая часть из них объявлены устаревшими и поэтому там постоянно ассерты переписывают
А ещё часто на проекты с нюнит с тестами подклчюают дополнительные тестовые фреймворки и начинается переписывание переписанного
так то он, как и все, любит ДЕНЕЖКУ
а в твоем фшарпе где денежка то
Литерали говно без задач. F# появился 20 лет назад и до сих пор нигде не используется.
ну сам язык не говно, а весьма более менее, хотя "они убили немерле, сволочи"
но применить его на фоне существования шарпа мало кому есть куда ибо мало кто понимает зачем оно куда и почему
и проще написать на шарпе, чем изучать новые материи.
таким образом - без задач.
Кто деньги ищет, тот всегда найдет. В F# есть ДУША! Душа .NET платформы. На этом языке можно писать большие проекты без ебли с нагромождённостью C#. Ну, а деньги последуют.
>немерле
Лол, кто-то еще помнит эту хуйню. На рсдн полтора шиза топили за эту польскую поделку, форсили патерн матчинг как не в себя. В итоге матч добавили в сишарп, оказалось нечитаемым говном, которое никто не использует.
лол. сила немерле это макросы. они вон даже в расте есть
в шарпе же "ну поззззяяязяяя ну добавьте это хотя бы через сто тысяч миллионов лет"
Макросы не нужны. С ними каждый проект превращается в непонятную хуйню.
сделать так и без макросов можно. тот же кодоген хотя бы тоже работает неявно.
так что не нужно искать черную кошку
Такой, как для Python - чтобы на лету проверял форматирование на соответствие стандарту и подсвечивал проблемные места с рекомендацией по исправлению.
>Вполне нормальный синтаксис.
согласен?.Вполне()?.Нормальный(x => Синтаксис())!
Дохера всего, но этим никто не пользуется. В дотнете нет таких проблем
Два варианта.
- .editorconfig
- stylecop
Можно как вместе использовать, так и по отдельности.
class myass
{
public char A;
}
Мне нужно создать динамический список из таких объектов. Чтобы самому с этим делом не ебаться использую коллекцию
List<myass> Asses = new List<myass>();
Могу добавлять туда объекты, всё пучком.
А теперь мне надо создать динамический список таких коллекций. Хотелось бы для этого тоже использовать коллекцию. Как бы коллекция коллекций. И вот тут я чёт затупил, на уровне синтаксиса не понимаю как это должно выглядеть. Вкиньте пример хоть что ли.
var listOfListOfMyAsses = new List<List<myass>>();
listOfListOfMyAsses.Add(new()); // добавляем первый список
listOfListOfMyAsses.Add(new()); // добавляем второй список
var list1 = listOfListOfMyAsses[0]; // первый список
var list2 = listOfListOfMyAsses[1]; // второй список
Хочу вот так теперь в шарпах.
Как сделать, чтобы студия по умолчанию так же делала?
Я знаю, но не скажу. Не хочу чтобы мудацкий K&R кто-нибудь тащил в мои шарпы.
Мне хочется чтобы не было отступов внутри неймспейса и класса. Плюс - модификаторы доступа на отдельной строке.
Типа вот так:
namsepace Foo;
class Bar {
public
void Buzz();
}
>линтер
Именно линтера нет, у нас другие категории. >>3350696
>Мне хочется чтобы не было отступов внутри неймспейса и класса.
внутри неймспейса и так не будет отступа, если использовать file scoped namespace
внутри класса - боюсь, тебе придётся самом поискать, как это делается. Мы обычно пользуемся настройками по умолчанию
https://github.com/mfakane/rawinput-sharp/blob/master/RawInput.Sharp.SimpleExample
Про WinAPI лучше спрашивать у байтоёбов, они в соседнем треде сидят.
>А когда в нее лезут - зовут тех кто шарит, а не чела, который такие вопросы задает.
Анон, у тебя какое-то неправильное впечатление по отношению к заводам сложилось. Да и не завод у меня, а КБ военка Никто никого звать не будет, если темой занимаешься ты - тебя и заставят пердолится, и будут заставлять пока не сделаешь. Так что у меня вариантов нет.
>>3351203
Это в котором?
Не работает твоя хуита. В частности подчёркивает пустые скобочки, и ещё чо-то было, не помню.
listOfListOfMyAsses.Add(new());
В общем сам разобрался. Учись салага.
Ебать ты пидармот вырвиглазный. Все блять пятнисто-цветастое как приход нарколыги под лсд или очко павлина. Не удивительно чты тупорылый овощ ведь в башке насрано вместо мозгов нахуй!
Вы учите друг друга, как объекти в список добавлять?
А ничего, что в 2к24 году такой хуйнёй никто не занимается, потому что это ответственность автомаппера?
Хочу укатиться к вам с пыха, есть смысл влезать в эту авантюру или по деньгам/вакансиям шарпа все сейчас плохо в рф? Меня заебло перекатываться по проектам с написанием магазинов дилд для ИП Оленян.
Иди в бигтех, там толкового пхпшника с радостью заберут и переучат на говноланг
Зачем тебе полумертвый шарп
хуй знает, что более полумертво, голэнг или c#. Сейчас все пишут на автомаппере
Почему полумертвый? Я наоборот только пару лет назад стал о нем слышать в среде разработчиков. До этого дотнет считался зашкваром для пользователей виндовса.
Когда дотнет считался зашкваром?
Дотнет хорош тем, что он не категоричный. В нём нет отбитых установок и мантр типо "ВСЁ ДОЛЖНО ДЕЛАТЬСЯ ОДНИМ СПОСОБОМ" или "ВСЁ ЕСТЬ ФУНЦИЯ" или "ООП ЭТО ВЫСШЕЕ ЗЛО" и прочей хуеты наподобие "БАТАРЕЙКИ ВКЛЮЧЕНЫ"
Дотнет в этом плане просто предоставляет языки и возможности писать программы в каком хочешь стиле. Он ненавязчивый и приятный. За то его и любим
На дотнете не осталось чистого бекенда, один сраный фулстек у нищебродов.
Щас бы в 2025 доверять каждому спорному утверждению на дваче.
> NUnit мне не нравится.
Что именно не нравится?
Xunit уже научился разбивать именованные кейсы по разным элементам в обозревателе тестов?
Даже количество тестов не умеет считать, пиздец убожество.
>Что именно не нравится?
NUnit громоздкий комбайн, там раз в 40 больше кода, чем в xUnit и MSTest вместе взятых. Куча неймспейсов, всякого мусора. Он некорректно обрабатывает жизненный цикл тестов, переиспользует поля класса и это не настраивается.
Ну и в NUnit уебанский нетипобезопасный синтаксис ассертов, который выкинуть нельзя, и работает он как говно.
Кто будет писать вот такое:
Assert.That(1. Is().IsGreaterThan(x => x.To(1))).
если можно писать вот такое:
True(x>2);
Почитай исходный код обоих. XUnit писался после NUnit, с учётом всех ошибок. Он внутри крайне логичен и прост. NUnit же выглядит как переусложнённое хуй пойми что.
Чего их ненавидеть-то?
Мы с одним разрабом поспорили. Он сказал, что запилит сложную фичу только по тестам, ни разу не запуская проект.
И ведь не обманул, чертяка.
Я с тех пор начал относиться к тестам по другома. Просто представь, что результат отладки проекта остаётся лежать внутри проекта и автоматически запустится когда какой-то хуй полезет в код уже реализованной фичи.
Люблю юниты, но когда они в меру. Ненавижу дрочь на процент покрытия.
> Assert.That(1. Is().IsGreaterThan(x => x.To(1))).
Франкентшейн какой-то, ты маМорозко ошибся. Смотри пик.
Как по мне, такой синтаксис охуенный и удобный. В таком варианте у тебя не возникает мысли каким аргументом идёт expected, а каким actual.
> Он некорректно обрабатывает жизненный цикл тестов
Приведи пример, что ты под этим имеешь ввиду.
>Франкентшейн какой-то, ты маМорозко ошибся. Смотри пик.
Вижу на скрине уродливый набор слов
> В таком варианте у тебя не возникает мысли каким аргументом идёт expected, а каким actual
Всем похуй. В нормальных фреймворках давно уже забили хyй на это педантичное недоразумение и поменяли слова actual/expected на left/right.
Но NUNIT-выблядки высосали из пальца проблему, понаписали каких-то синтаксисов на несколько десятков тысяч строк и в приказном порядке задепрекейтили всё, что было ранее.
Чего там удобного - я xyй знает. Только почему-то в других фреймворках это "удобство" не стали затаскивать.
> Он некорректно обрабатывает жизненный цикл тестов
Там за каким-то xyем сделали общее состояние тестов внутри одного класса. А надо чтобы настраивалось. Скопипастили с java [Setup] и [TearDown], которые в принципе ничего не меняют, но сами по себе уродливое говно, вызванное ограничениями джавы и внутренним устройством Junit.
Когда я увидел, как в xUnit не стали eбать мозг атрибутами и сделали конструктор-диспоз, а так же возможность полностью настраивать жизненный цикл тестов - я на nunit стал смотреть просто как на какое-то недоразумение. xUnit разработали с чистого листа те же самыe люди, что делали NUnit, кстати, не забывай.
>Как по мне, такой синтаксис охуенный и удобный
как по тебе
эти (модульные) тесты пишут и ЧИТАЮТ программисты
а программистам привычно читать именно код, а не вот эту англохрень.
еще можно понять всякие ShouldBe в названиях тестов потому что их могут гонять всякие гуманитарии, но в теле модульного теста это нахрен не нужно
> кто-нибудь работал на проектах с DDD?
С какой его частью?
Как всегда же
достоинства для одного является недостатком для другого.
Вопрос выбора стула во всей красе.
пример медиатр
киллер-фича - нет прямой связи между отправителем и подписчиком
фатальный недостаток - нет прямой связи между отправителем и подписчиком
таким образом речь говорящего о плюсах будет всегда предвзята. (впрочем и о минусах тоже)
не буду сегодня мандеть про медиатр, всё-таки новый год на носу
>Мы с одним разрабом поспорили. Он сказал, что запилит сложную фичу только по тестам, ни разу не запуская проект.
>
>И ведь не обманул, чертяка.
Только наебал он тебя похоже. Либо он глубоко в контексте был либо результат был тупо подогнан к тестам (чем собственно и плох TDD).
> Всем похуй. В нормальных фреймворках давно уже забили хyй на это педантичное недоразумение и поменяли слова actual/expected на left/right.
В нормальных это в каких?
В xunit сигнатура метода выглядит так:
void Equal<T>(T expected, T actual)
И если перепутать, то в обозревателе тестов они тоже будут перепутаны. Так что не пизди.
> Скопипастили с java [Setup] и [TearDown],
Ну и чем это на практике отличается? Ничем.
Пикрелейтед.
Концептуально xunit с конструктором и дизпозом выглядит интереснее, но на практике разницы нет.
> Но NUNIT-выблядки высосали
Это поэтому сейчас в 3-ий xunit, спустя 10+ лет высосали TestContext? Ведь изначально НИНУЖНО.
А так, что в nunit, что в xunit косяков предостаточно.
Но косяки xunit для меня критичнее, поэтому использую nunit.
3 версию xunit надо погонять детальнее, но сомневаюсь, что там что-то глобально изменилось.
>>3352230
> еще можно понять всякие ShouldBe в названиях тестов потому что их могут гонять всякие гуманитарии, но в теле модульного теста это нахрен не нужно
И? В чём претензия-то? У nunit тесты прекрасно читаются, даже гуманитарии могут. Смотри:
Утверждение.Что(результат, Действительно.БольшеЧем(2));
А вот залупа в виде ShouldBe не нужна.
>Утверждение.Что(результат, Действительно.БольшеЧем(2));
Идиотизм от гуманитариев
Почему ты код в самом приложении так не пишешь?
Не торопись, подумай)
> Почему ты код в самом приложении так не пишешь?
Ты дурачок? Не путай мягкое с тёплым.
не путаю. мы говорим про модульные тесты, тело которых пишет и читает программист
Так зачем он изворачивается для гуманитариев?
чтобы гуманитарий мог прочитать Assert?
Простите, а остальная часть, там где получается expected, она тоже написана в стиле "Я.Люблю.Тупо.Выражаться"? или все же там банальный код, который гуманитарий не поймет? А если еще и фикстуру сюда добавить, то вообще у него мозг взорвется
А поэтому вопрос тот же - ЗАЧЕМ ЗАМЕНЯТЬ КОД СЛОВЕСНОЙ ЕБАЛОЙ? и почему у защитника этого говна подорвался пукан когда его спросили "а почему ты везде так не пишешь?"?
Ты дурачок. Нормальные люди пишут Assert.GreaterThan(result,2) и оставляют комментарий почему 2, если там что-то неочевидно. Долбоебы срут монадами в стиле Утверждение.Что(результат, Действительно.БольшеЧем(2)) ведь это же необычно выглядит мам ну смотри.
>Концептуально xunit с конструктором и дизпозом выглядит интереснее, но на практике разницы нет.
https://xunit.net/docs/shared-context . Разница на практике огромная. Как в NUnit делать, чтобы у тест-класса не было общего состояния в полях? никак?
>И если перепутать
нихуя принципиально не сломается
> А так, что в nunit, что в xunit косяков предостаточно
я не понял, какие там косяки, xunit простой как палка, там буквально нечему ломаться
> В чём претензия-то?
ВТом.Утвержедение(говно, Оно.Как.Читается(говно))
> Нормальные люди
> оставляют комментарий
комментарии надо удалять сразу как видишь и по пальцам палочкой бить дурачкам, которые их пытаются поддерживать
>Assert.GreaterThan(result,2)
Проверить что 2 больше чем результат или наоборот?
Просто импортируешь статический класс Assert и пишешь:
True(result > 2);
Equal(2, result)
И всё. Два метода по сути нужно, всё остальное - это происки дьявола
На элегантном английском
Assert.That(collection, It.That.Is().Should(have => have.At(x => x.Least).Single().Equal[item]))
Сори за офтоп, но:
Я новенький, не ебите.
Вкатываюсь в айтишечку, в моем городе вакансий очень мало, поэтому если меня развернут то выбора особо не будет.
Поэтому спрашиваю - насколько типичны дистанционные собесы у контор в мск для людей без опыта?
Т.е. во первых насколько распространены дистанционные собесы вообще?
во вторых какие шансы есть у чела без опыта на релокейт в мск?
Ебать у тебя каша в голове. Доебался до гуманитариев. Основной разговор-то не об этом был.
>>3352708
Разница настолько огромна, что у них примеры из документации не комплируются.
> stack.Dispose();
> нихуя принципиально не сломается
Ты точно в этом уверен? Сходи проверь, а потом пизди.
> ВТом.Утвержедение(говно, Оно.Как.Читается(говно))
Разница в синтаксисе, не более.
Кому-то хуи, а кому-то пики.
>>3352744
Неиронично охуенно выглядит))))
>Разница в синтаксисе, не более.
В xUnit библиотека ассёртов опциональна. Подключай какую хочешь, хоть nunit.
В NUnit ассёрты встроены. Половина из них задепрекейчана
Вот и вся разница
> В xUnit библиотека ассёртов опциональна. Подключай какую хочешь, хоть nunit.
Это каким образом? оО
> В NUnit ассёрты встроены. Половина из них задепрекейчана
У них 2 модели: классическая и на основе ограничений. С 3 версии модель ограничений стала основной. Так что не понимаю о чём ты.
https://docs.nunit.org/articles/nunit/writing-tests/assertions/assertions.html
>Доебался до гуманитариев
а до кого еще.
все эти should be пошли из за того, что кое кто, кто не программист, решил читать красивые английские фразочки в интеграционном тестировании
Так что к НАЗВАНИЯМ тестов не придируюсь. Придираюсь к телу теста, где КОДЕР пишет поэму непонятно нахера
ты так и не ответил ЗАЧЕМ.
>Неиронично охуенно выглядит))))
ааа, все понятно. ебанутая (с)
тогда вопрос снят
https://xunit.net/docs/nuget-packages
То, что в xUnit библиотека ассертов опциональна - это в документации описано.
Подключить нютиновские ассерты теоретически можно, но придётся затащить весь комбайн. Это никому не нужно, потому что nunit уебанский
>У них 2 модели: классическая и на основе ограничений. С 3 версии модель ограничений стала основной. Так что не понимаю о чём ты.
У них одна модель. Та, которая называется классической моделью объявлена устаревшей и не поддерживается. Вместе с тем весь пользовательский код (в моём случае 50 000 тестов) так же объявлен устаревшим.
Собственно это и есть основная моча в ебало разработчикам нюнит. Они не спросив пользователей в обязательном порядке перевели всё на новые весьма специфические ассерты наплевав на существующий код.
А МНЕ ОНИ НЕ НРАВЯТСЯ, Я СЧИТАЮ, ЧТО У НИХ СИНТАКСИС ГОВНО
>Т.е. во первых насколько распространены дистанционные собесы вообще?
Сейчас почти все собесы удаленные. Даже там где работа фултайм офис, скрининг и первый тех.собес проводят удаленно.
Собесы в офисе первый признак говноконторы.
Новичков тоже собесят преимущественно удаленно, для них сложно просто на собес попасть как таковой.
>>3352802
>во вторых какие шансы есть у чела без опыта на релокейт в мск?
Практически никаких. Только удаленка. Хотя в теории ты можешь устроиться сначала удаленно и потом своим ходом двинуть в МСК, но з.п. тебе все равно оставят региональную.
>все эти should be пошли из за того, что кое кто, кто не программист, решил читать красивые английские фразочки в интеграционном тестировании
У нас бизнес-аналитик постоянно лезет в код и пытается писать по нему спеки. Ему кучу раз говорили, чтобы не маялся хуйней и тупо смотрел в сваггер где есть вся документация и модели, но ему все равно надо повыебываться и показать, как он умеет читать код.
>бизнес-аналитик
Это же специальный гуманитарий, который описание тасок в джире заполняет, зачем ему вообще лезть в код?
Очевидно же, что они путают системного и бизнес-аналитика.
>>3353011
Он типа универсальный и бизнес и системный. Только вот даже системному аналитику нехуй в коде делать.
Кто вам долбоебам мешал постепенно от них уйти? Каждый раз как код правишь штук 100 быстро передалал.
Я за день 2000 тестов менял.
>Кто вам долбоебам мешал постепенно от них уйти?
единогласно решили уйти на xUnit. Так дешевле. Никто не выразил желания переписывать тесты на новый мусорный синтаксис
Спасибо, очень полезная инфа.
А насколько охотно берут на удаленку без опыта? Там требования для джуна без опыта будут выше?
Без опыта вообще не берут. Напиши в резюме два года опыта в местном ООО SmartBestWay, никто же не проверит.
>Там требования для джуна без опыта будут выше?
Требования сейчас для всех заоблачные. Даже если ты сам Хейльсберг, то с очень большой вероятностью завалишь собес на .net разраба.
>А насколько охотно берут на удаленку без опыта?
Очень неохотно. Только если прям очень хорошо себя на собесе покажешь, но обычно без опыта до него трудно добраться.
Нарабатывай опыт любыми путями. Если учишься в шараге - корешиьс с преподами и выбивай у них любую практику. Или кооперируйся с сокурсниками и мутите вместе какие-нибудь сервисы (да хоть сраных чат ботов).
Еще могу дать совет помимо джуновских вакансий откликаться на мидловые, особенное если там есть открытое тестовое (естественно его нужно сделать качественно перед откликом). Просто по опыту на такие позиции людей ищут с меньшим количеством выебонов на собесе, т.к. тут нужны просто рабочие лошадки которые будут работать работу. У меня так товарищ с околонулевым опытом залетел (понятно, что зарплата у него по итогу была джуновской, а не той что в вакансии указана для мидла)
Можешь еще завести себе карманную it-херочку, тогда будешь в курсе всех вакансий и возможность, чтобы твое резюме подсунули на них в обход фильтров.
Спасибо.
То есть нужно почти 100% иметь в резюме личные проекты? Я в целом так и думал, но свободного времени у меня полно так что это не проблема.
>it-херочку
Это что?
>>3353248
То есть опыт не обязательно должен быть рабочим и личные проекты это тоже опыт, да?
>То есть опыт не обязательно должен быть рабочим и личные проекты это тоже опыт, да?
Есть, типа, две категории. Просто опыт разработки и опыт коммерческой разработки. Первое это любая разработка хоть чего и хоть как. Вторая подразумевает разработку чего-то, что потом будет продано за деньги или принесет любую другую прибыль. Там уже учитывается работа в комманде, знание различных этапов разработки, понятия сроков, задач, всякой хуйни вроде водопадов, agile, scrum и т.д.
Если в вакансии прямо написано, что-нибдуь вроде "опыт коммерческой разработки N лет", то вероятнее всего там ты со своими личными проектами не проканаешь. Только если это будет, что-то крутое попенсорсное, что хотя бы в своей нише известно.
>>3353251
>Это что?
It-рекрутер.
>>3353251
>То есть нужно почти 100% иметь в резюме личные проекты?
Голое резюме сейчас нафиг никому не нужно, т.к. за время любой учебы можно спокойно сделать пару-тройку проектов, либо поучаствовать в какой-либо практике. Если у тебя такого нет, то значит ты во время учебы хуи пинал и будешь не интересен.
>Вторая подразумевает разработку чего-то, что потом будет продано за деньги или принесет любую другую прибыль.
Могу ли я сказать что у меня есть опыт коммерческой разработки если я писал людям за деньги их софт по заказу?
Регеры, парсеры, тг боты, еще всякая хуйня типо получение писем с почт по imap, парсинг и отправка данных по апи в ии. Твиттор и CRM не писал.
>Твиттор и CRM не писал.
кто CRM не писал, тот красот не видал
Бэкендером быть охуенно. Никакой тебе верстки, никакого js, никакого ебучего xaml-а. Выкинул наружу api и похуй кто там и как с ним трахаться будет. А сам сидишь, спокойно возишься с мидлварями и хостед сервисами и довольно урчишь.
>contosopizza
Бля, у меня на руках полураспиленный монолит, его обратно собирать или дальше распиливать?
Еще говорили, что не хотят регистрации прописывать в контейнере.
Я сейчас работаю на проекте без медиатра. Пишу команды и квери, всё резолвится само, регистрации через атрибуты. В конструкторах контроллеров до 4-5 зависимостей.
Проблем не вижу. Код получается классный.
Неужели медиатр-бляди не решают никаких конкретных проблем?
Взял проект небольшой, 1 страничное приложение с полем ввода и кнопкой. А я хуй знает маиу хуи я только сосольки и блазор писал.
Нужно за сутки научится.
>>3354666
Сорян не уточнил.
Виндовс.
Собственно там манипуляции с текстом проводить. Ниче сложного, но так как я не шарю нихуя в этих все формочках авалониях хуениях и прочем впф нет мауи то для меня немножко сложно.
я знаю. поэтому повторяю свой совет чтобы увидеть насколько все эти мауи ХРЕНЬ
Спорить не буду.
Но у меня нет времени.
Надо выбрать что то максимально простое.
На слуху авалония. Мб её?
Ну тогда бери винформы, проще винформ нет вообще ничего. Ты же ставишь во главу угла простоту, а не удобство, расширяемость, поддерживаемость.
Не ну не так шоб прям на столько проще.
Я все таки из актуальных хочу выбрать чо то
WPF и то проще лол
сам слез с формсов на впф и как то попробовал на формсах - нихрена не помню и не вижу смысол
Медиатор бляди выросли из блядей для которых CS это страшно и вообще книги дядюшки Боба они старые, а в ИТ все меняется часто.
Они искрене верят что под зависимостями имеют ввиду именно прямые зависимости поэтому для них медиатор их устраняет. Было у тебя 8 внедрений стало 3, значит устранили 5 зависимостей.
Я пытался объяснить что зависимости просто стали неявные и скрытые от глаз, те 5 классов все ещё влияют на работу текущего, мне даже сказали что понимают это но так КОД ЧИЩЕ.
Это буквально такой новый сорт разрабов, что ужасно от тренни до лидов, им главное что зависимостей нет явно или код выглядит чисто.
Оже самое кстати модные ДДД. Я сижу на архетектурной секции и задаю логичный вопрос. Почему сущность сама управляет сменой статусов модели. На что получаю ответ что это же агрегат. Дальше я наваливаю логичные варианты
1) кто в таком случае должен писать историю смены статуса(в широком смысле вообще вести аудит)
2) если понадобится сделать уведомления. Это тоже будет делать агрегат? Вообще кто должен обслуживать всю попутную логику которая будет сверху?
3) эта хуйня явным образом нарушает S принцип. Entity это класс ответственный за представление данных реляционой базы в объектах предметной области. Возложение на него ответственности за управление статусной моделью сущности это нарушение SOLID.
В результате диспута меня мягко послали нахуй сказав что я просто неверно толкую термин responsibility, а первые два пункта не находятся в скоупе задач на спринт.
Вообще Аджайл раковая опухоль ИТ. Нам необходимо сделать грузовик, все знают что нужен 8 осный грузовик с бочкой для бензина, но мы начинаем не с создания рамы ходовой, а с багги. Так можно сразу показать результаты. Да клиенту нахуй не нужен ни багги, ни кабриолет, ни микроавтобус, ни грузовик с 4 колесами. Ему нужен бензовоз блять с 8 осями и нет не надо ему ничего показывать. Надо чтобы он подписался под ТЗ на бензовоз с 8 осями и если посреди монтажа кузова ему захочется сделать 10 осей мы шлем его нахуй и требуем ещё денег и увеличиваем сроки.
>Неужели медиатр-бляди не решают никаких конкретных проблем?
Не решают. Это просто модьненько и позволяет тонкие контроллеры писать. Ну и да, в пайплайн можно всякое добавить еще вроде валидации. Удобно.
Но ничего такого нового и прямо необходимого медиатр не дает.
>Entity это класс ответственный за представление данных реляционой базы в объектах предметной области.
Ентити это не агрегат. Агрегат это толстая модель. То что там в реальном мире все все путают это не проблема ДДД.
Проблема ддд в том что плюсы НЕ перевешивают бубен вприсядку
Либо волчара напиздевший в резюме. Либо (судя по тому что 3-е января) студент, проебавший сессию и договорившийся с преподом на последний шанс досдать лабы после праздников.
Ну тогда ты демпингатор/штрейхбрекер хуев.
Это даже хорошо. Вот сейчас обосрешься и на одного заказчика понимающего, что за "дешево и быстро" можно получить только хуй на блюде станет больше.
>То что там в реальном мире все все путают это не проблема ДДД.
Да, блядь, никто не может до конца понять DDD до конца. Это не не то протокол, не то секта. Там ключевых понятий более двадцати, думаешь про одно, 19 в уме надо держать.
Я не видел ни одного разработчика, который до конца бы понимал DDD. А те, кто понимают - не практикуют разработку, а ведут курсы на нереалистичных примерах.
Я, если честно, предпочёл бы калёным железом эти слова выжечь и начать всё с начала.
Если все не могут правильно понять какую-то штуку, то это не проблема людей, а проблема штуки.
У ДДД есть очевидная проблема. Все эти понятия слишком размытые и зависят от каких-то эфимерных признаков.
>КОД ЧИЩЕ.
Ебать, там такой говнокодище получается, где хуй разберёт где начало, а где конец.
>>3354735
> позволяет тонкие контроллеры писать
а что-то мешает писать тонкие контроллеры без медиатора?
> модненько
нихуя себе модненько, 10 лет назад таким говном занимались, зачем повторять ошибки - хз.
> мычание долбоёба
иди пиши на пиши на пейфоне. Дотнет оставь, это не для таких ебланов как ты
50$ за одностраничное приложение с 2мя полями ввода и 1 кнопкой и логикой на очистку файла это дёшево?
Да. Это 3-4 часа работы или примерно 12 баксов в час. 2100 в месяц
>Это 3-4 часа работы
Ну у меня было бы так если бы это было консолька
А так это 2 дня)
>2100 в месяц
Ну 2к в месяц, мало штоли?
Ну это ты бы взял 150$ но не всего могут выбирать че и за сколько им делать.
>а код писать для души
Я бы рад конечно так делать но для этого надо сначала получать деньги)
дык получай. на заводе вон токарей не хватает.
а фриланс зло
Меня? Это ты жалуешься что не просто денежку дают, а и код писать надо
Вообще говоря да - так и есть. В ддд есть интересные концепции, но в целом оно скорее полезно тем, что у тебя должно быть в голове, когда ты пишешь код, а не про сам код.
На деле совсем отдельный домен со всей бизнес логикой нахуй не нужен.
>У ДДД есть очевидная проблема.
Еще одна проблема ДДД, то, что под ней должна быть охуенная аналитика, с четкой и вылизанной спецификацией. Что встречается почти никогда.
>Я, если честно, предпочёл бы калёным железом эти слова выжечь и начать всё с начала.
В 2025 году разработка ушла в облака, там ДДД нахуй не нужен. Пока ты будешь собирать агрегат агрегатов с 20 сервисов шобы было ДДД, конкуренты прокинут джейсончик и зарабортают все деньги. ДДД остался в каких-то древних учетных системах из 90-х, сейчас никто так не пишет.
Ага, выходит, суть облачного подхода в том, чтобы по-быстрому наговнякать приложуху как получится и будь что будет, а учётные системы больше никому не нужны, ведь учитывать надо только количество деняк на карточке.
Суть облачного подхода в распределенных данных и распределенных транзакциях. В ДДД все красиво, пока все данные лежат рядом в одной бесконечной памяти, тогда можно наворачивать агрегаты агрегатов и выделять слои слоев. Как только встает вопрос "кто откатывает транзакцию", ДДД пукает и обмякает.
Яндекс-облаком пользуемся. Его скопипастили с амазона, но у амазона интерфейс делали долбоёбы. После AWS, консоль яндекс кажется каким-то космическим и суперсовременным.
> Мда, в шарпохуйне я не могу передать this в базовый конструктор, пиздец...
Потому что ты долбоёб. Базовый конструктора вызывается раньше чем дочерний. Чего ты там передавать собрался?
Дотнет не для тебя, если ты такие тупые мысли выдаёшь. Иди программируй на пейфоне. Ну или на котлине, если тебе нужен выразительный язык. Но в дотнет не лезь
>передать this в базовый конструктор
Нахуй не нужно.
Ебани protected метод инициализации в базовом классе принимающий нужный объект и сохраняющий его в какойм-нибудь поле. И передавай через него this в конструкторе потомка.
Покажи, где тебя трогали питонисты, а то вижу, что они не дают тебе покоя, весь тред своих протыков вспоминаешь.
>Как только встает вопрос "кто откатывает транзакцию", ДДД пукает и обмякает.
Так в облаках не должно быть транзакции. Необходимо строить систему на основе ассинхроных моделей и сообщений с событиями. Либо иметь единый сервис оркестратор который знает про бизнес процесс и как им управлять.
>Так в облаках не должно быть транзакции. Необходимо строить систему на основе асинхроных моделей и сообщений с событиями.
Это надо угадать как-то или между строк прочитать? А как понять, где заканчивается ДДД и начинаются паттерны микросервисной архитектуры?
> Либо иметь единый сервис оркестратор который знает про бизнес процесс и как им управлять.
Нанять пару архитекторов, чтобы в гамаках лежали и кафку обсуждали.
>Это надо угадать как-то или между строк прочитать? А как понять, где заканчивается ДДД и начинаются паттерны микросервисной архитектуры?
Я вообще противник ДДД и идеи что нужны какие-то агрегаты и объекты которые сами себя меняют.
Моё ИМХО что ДДД вообще противоречит микросервисам.
реально писать микропенисы в функциональном стиле с реббитом и событиями? Я просто пытался много раз понять ДДД - и каждый раз как в первый раз.
Чтобы понять ддд надо внимательно книжку прочитать. ДДД это про взаимодействие архитектора (аналитика) с заказчиком, в целях выработать общее представление о автоматизируемом процессе. Вся суть ддд в универсальном языке, или как в ддд это называется юбиквити лангуаге, который вырабатывается в результате брейншторминга на территории заказчика с его персоналом. Домены это часть этого представления.
Не путай ДДД с луковичными и гексогональными архитетурами. ДДД это не архитектура, которую кодомакак единолично у себя в голове создает. Это средство взаимодействия с заказчиком
>>3355446
Какая-то хуйня.
Суть распределённых транзакций в том, чтобы по максимуму их избегать. Распределённые системы и транзакции нихуя разработку не ускоряют, что за хуйня. Это как раз Вася с монолитом джейсонов накидает быстрее.
Проблема что весь этот язык не работает. Система типов или модулей вообще может не отражать реальные объекты и процессы. Часто бизнес сущности и процессы имеют эмерджентную природу.
Программисты вообще не должны завязываться на модели бизнеса и тем более общаться с заказчиками. В 100% случаев это приведёт к тому что вместо требований получается "скрытое решение" когда заказчик пытается пропихнуть свои идеи реализации.
Задача разработки это моделирование целевых процессов и их автоматизация. При этом то как это происходит может вообще не исходить из бизнеса.
Если делать по ДДД завод машин мы по Комон лэнгвидж и общению с заказчиками будем проектировать антропоморфных работов с развитым ИИ.
Как только у тебя появляется вторая бд, у тебя появляются распределенные транзакции. И ты их никак не избежишь.
> Вся суть ддд в...
ну например.
Но смею заметить, что каждый следующий умник рассказывает про DDD что-то своё.
Один пиздит про агрегаты, другой про ограниченные контексты, третиий про события, четвёртый про MediatR и Automapper Да, мне один долбоёб и правда пытался доказать, что DDD это CQRS, который невозможен без медиатра
Может, хватит уже?
Зачем слушать всех если можно эванса открыть и посмотреть. Там в основном вода про менеджмент, а не как писать код
>Зачем слушать всех
Чтобы понимать о чём они говорят. А говорят разное, но слова одни и те же
С чего бы? Наличие необходимости в полной консинстентности данных это проблемы архетуктуры. Ты получается разбил какую-то сущность на разные БД, это ошибка.
Если что-то должно быть сохранено в рамках одной транзакции, то это должно принадлежат одному сервису. Либо ты трясун шизофреник и на самом деле тебе нет нужды производить операцию целиком.
Чел, ты какую-то хуйню джуновскую пишешь, если ты ещё и автор вот этой хуйни >>3355555 - твоя цена это 70к максимум.
>>3355555 (You) - твоя цена это 70к максимум
Ну поплачь ещё.
ДДД это хуйня из под коня и признак долбоеской организации разработки.
Ну это неудивительно, я видел достаточно таких долбоёбов которых мы увольняли очень быстро.
Считаю, что ДДД не существует в природе. Каждый понимает под ДДД свое видение разработки, но толком внятно описать его не может. Вообще все эти идеологии, паттерны, методологии, стили и приемы разработки могут называться одинаково, но по факту от проекта к проекту будут представлять из себя разные вещи, а порой и вовсе противоположные по смыслу. Надо приходить на конкретный проект и вникать в него, чтобы понять, что именно там подразумевали под ДДД его авторы. На моем текущем проекте тоже гордо говорят, что у нас ДДД используется, а по сути все ДДД заключается в том, что мы дто, ентити и репозитории кладем не в три папочки, а у каждой сущности есть своя отдельная папочка, где лежат связанные с ней репозитории и ентини. Мне лид затирал, что именно это и есть ДДД по его мнению. А мне в целом похуй, раз это назвали ДДД, то пусть оно и будет так называться у нас на проекте.
Сижу читаю "Чистый код", охуенная книжка
Чистый код - это такой сборник разговоров в курилке, где скуфы с 20+ годами опыта обсуждают, как же они заебались. Джунам это непонятно и неактуально.
>итеративной, пошаговой гибкой разработки
Только это не делает никто.
Задача.
Необходима машина красного цвета.
1) Мы пока сделали МВП в виде велосипеда
2) знаете времени на переделку нет мы взяли два велосипеда и сварили их.
3) долго думали и в итоге вокруг велосипедов сварили каркас кузова
4) вставили двигатель и кпп. Ручка переключения правда находится за спиной водителя поэтому мы сделали тросик и переключение в стиле мотоциклов
5) спустя долгое время мы все же смогли приделать рулевой механизм от настоящего автомобиля
6) доделали кузов приматав его стяжками.
Как это делают нормальные люди.
1)
1.1) вот рама вашего автомобиля и колеса
1.2) вот кузов
2)
2.1) мы установили двигатель, кпп и рулевое управление
2.2) вот кузов уже проходит финальную полировку
2.3) вот отделка салона
3) мы завершили монтаж кузова на раму
4) завершили отделку салона.
В результате итерации не должно быть готово продукта. Невозможно собрать машину чтобы на каждом этапе на ней можно было ездить.
Также невозможно делать качественный код когда от тебя требуется чтобы можно было уже тыкать.
Гибкость это миф. Система всегда будет расчитана на какие-то границы сверх которых выйти нельзя. Всегда будут фичи которые мы будем делать 3 месяца и не можем показать никакой результат кроме "мы работаем".
Если у вас бизнес меняется каждый месяц, то возможно у вас хуевый бизнес и нет никаких тактических и стратегических планов.
И главное. Дураку пол работы не показывают.
>знаете времени на переделку нет
это у вас нет. А у нормальных людей берется бумажка на увольнение, на ней жирным пишется "технический долг", бумажкой оборачивается кулак и этим кулаком по ебалу тех, у которых что то там горит
А далее либо время появляется, либо бумажка разворачивается на подпись
Бумажка ВСЕГДА разворачивается на подпись. После подписания нанимают тех, кто не будет отказываться делать задачи по непонятным кабану причинам. Кабану похуй, работа и так и так стоит, деньги платятся непонятно за что.
> кто не будет отказываться делать задачи по непонятным кабану причинам
тебе то что. ведь не тебе потом трахаться с этим франкенштейном и при этом быть виноватым.
А если причины, как ты говоришь, нипанимат, то и жпо настанет этому проекту (примеров множество), но это же будет не твоя проблема
если сложная жизненная ситуация, ну тянешь резину до жпо
но попутно ищешь другую работу
но не стоит так доводить себя. Рецепт успеха прост - всегда будь богатым и красивым.
ну а если без шуток, то когда начинается ебала с техническим долгом и никто этого не понимает, то значит настала пора походить за забором
хотя...там всегда полезно бродить. Это ведь только кажется что "да кому я нужен - вон сколько за забором ходят". Ходят конечно, но не все нормальные.
>Я сижу на архетектурной секции и задаю логичный вопрос. Почему сущность сама управляет сменой статусов модели. На что получаю ответ что это же агрегат
Вас шарпистов на собесах ебут такой хуйней? Это даже хуже литкода, ей-богу. Хорошо, что я укатился в Go и у нас на все эти паттерны-хуяттерны кладется хуй. Но зато многопоточку спрашивают всегда и везде.
а причем тут вообще шарп к подобным темам.
в любом развитом языке (а не примитиве для написания микросервисов) возникают вопросы архитектуры
По очень простой причине - язык позволяет писать БОЛЬШИЕ проекты.
а удел го - микросервисы.
> Хорошо, что я укатился в Go
Ну и за какими ссаными тряпками ты приполз в этот тред?
В сишарпе тоже. Это какой-то шиз навсегда застрял в 1995 году, потерялся среди абстрактных фабрик.
>Необходима машина красного цвета.
>Мы пока сделали МВП в виде велосипеда
Нахуя? переделывай
> Вас шарпистов на собесах ебут такой хуйней?
шарпистов - нет. медиатро-автомапперисты ебут друг-дружку тамими вопросами. Это низшая каста опущеных, с ним запрещено даже джунам и юнити-девам разговаривать
Я не про собеседование. Я сумел убедить людей что нужно проводить секцию планирования архетуктуры. Ажно 3ч выделили.
Хз о чем ты. Но ты молодец
В чем то убедилт- в менеджеры тебя. И пиздить розгами
У нас задача проходит этап
1) оценка разрабом. Очень верхнеуровнево.
2) потом все собираемся на планирование и даём оценку. Также пишем небольшие детали.
ВСЁ задача идёт в спринт.
Я смог убедить всех что для некоторых задач необходимо прям 2-3 дня выделить на архитектуру, продумывание как оно потом может развиваться и заложить это. Ну короче страшное нарушение принципа Аджайл "хуяк хуяк и на демо".
Вот в результате таких предложений родился этап когда разрабы обсуждают результаты проектирования.
Иными словами, добавил больше созвонов богу созвонов. Управленец от бога, хуле. Умные люди придумали аджайл, но всегда найдется шиз с окр, которому надо все заранее распланировать на сто лет вперед.
>Умные люди придумали аджайл,
И выкинули такие не нужные вещи как
1) архетуктура проекта
2) проектировачное решение
3) планирование проекта
4) документация
5) чёткие требования на разработку
6) критерии приёмки
Аджаил и гибкость миф. Нахуй не нужно иметь возможность каждые 2 недели менять проект. Если заказчик не может нормально сформулировать цели фичи или описать её это сложная и большая проблема, скорее всего он сам не понимает что ему необходимо и нужно не бежать код писать, а разобраться в его ситуации и предложить решение.
Я не понимаю почему мы не должны заложить в проект фичу из роад мапа на год. То что она будет в ноябре не значит что мы не должны ещё в феврале по другому делать фичи с прицелом что в ноябре мы планируем делать то-то.
С началом практики архетуктуры и проектирования мои коллеги сами говорят что им стало проще понимать наши сервисы, какие изменения вносятся, как это влияет на код. Также оказалось очень удобно иметь полную схему классов и сервисного взаимодействия которые я сделал и актуализировал все бизнес процессы в конфле до актуальных.
По итогам мы завели 30 задач на исправление дефектов. Аналитки нашли ошибки в работе системы при анализе диаграмм и схем процессов. QA говорят мне спасибо за наличие полной документации по взаимодействиям сервисов и даже за диаграммы классов и БД.
Даже скорость разработки немного выросла, стабильно 4СП в спринт. Ведь теперь мы при планирование смотрим схемы и архетуктуру и сразу видим некоторые проблемы.
Аджаил не работает когда тебе нужно долго и методично делать крупный проект. Я вообще не вижу никакой необходимости в гибкости, я вижу проблемы с коммуникациях когда аналитик бежит исполнять любые пуки заказчика не пытаясь выяснить у него реальные необходимости бизнеса.
Вангую у вас попильный госпроект, от которого заказчик не может отказаться. В условиях конкурентного рынка вас бы уже давно сожрали конкуренты с этими вашими согласованиями согласований.
Проблема в том, что заказчик сам толком не знает, что ему надо. Аналитик - это не боженька, он тоже ошибается. Аджайл позволяет подстраиваться под эти условия, ваша дубовая совковая с запахом НИИ методология - нет.
>> 1) Мы пока сделали МВП в виде велосипеда
С нулеовй хуйню сделали.
Могли бы сделать кресло, руль, педали и рычаг переключения, поставить на телегу, которая на этапе MVP толкается "руками", а дальше весь ручной труд автоматизировать, но это сложно, ведь хочется просто насрать в код
>> Возложение на него ответственности за управление статусной моделью сущности это нарушение SOLID.
Чисто эпирически, я вывел что класть в сущность статусную модель это путь в ад, если тебе кажется флоу будет примитвным на 3 статуса, тебе пизда, потому что дальше добавятся статусы и еще дохуя условий\прав для смены этих статусов.
Надо сразу пилить флоу-менеджер который берет сущность и сам разруливает ее статус, в нем же и аудит пишется (сервисом аудита)
Для меня ДДД это возможность выделить сущности на этапе проектирования, чтобы не ебаться потом самому сочинять все это.
>флоу-менеджер
Вы встречаете в коде класс GenericEntityInteractionDomainFlowManagerServiceBase
Ваши действия?
Переименовываю в AbstractGenericEntityInteractionDomainFlowManagerServiceBaseBean
Добавляю в резюме строку Solution Architect
Кстати, интересный вопрос, почему существенная часть любителей этой наебки для гоев не смогли усвоить из нее самое важное - что все это дерьмо надо нормально называть?
Посоветуйте лучшую книгу по ООП и паттернам с примерами на языке Си-решетка. Чтоб прям преисполниться после изучения. Можно и не книгу, но вряд ли лучше книг что-то есть.
>пик
Пиздец конечно. Я-то думал что хоть тырпрайзные джавошарписты зарабатывают нормальные деньги, а нет. Даже в этой сфере работают за три куска. А еще кто-то собрался в РФ индусов завозить, какой индус со знанием ингриша пойдет работать за такие копейки.
>книгу по ООП и паттернам
Ты опоздал на 30 лет. В 2025 году IService возвращает лист дтошек, а синглтон - один из вариантов регистрации в DI.
Принципы, паттерны и методики гибкой разработки на языке C#. — Символ-Плюс, 2011.
>>3358933
Пчел, если ты не понимаешь паттерны - это не означает, что их не понимают другие. Нормальный код он всегда немножечко ооп, но без этого блядства и разгула, который раньше делали
>но без этого блядства и разгула, который раньше делали
Так то что ты слишком тупой чтобы понимать зачем так делают твоя проблема.
Невозможно легко сделать сложные вещи.
> Невозможно легко сделать сложные вещи.
а если пару раз подумать - возможно.
Сначала делаешь базу, а остальное всё прикладывается как по волшебству.
Сначала делаешь базу:
Выкидываешь автомаппер - код становится менее хрупким и лучше читается.
Выкидываешь MediatR - код становится устойчивым и однонаправленным.
Выкидываешь все комментарии нахуй, - и как-то просторнее и проще работать становится.
Потом как по волшебству код вокруг начинает писаться проще и быстрее
> понимать зачем так делают
Потом выкидываешь DDD и начинаешь писать "вот как есть". И даже как-то стыдно становится, что 5 лет на хуйню потратил
Ну хули, учи новые паттерны. По новой книжке. А лучше в тик-токе
Есть какие-то причины хейтить книжки дяди боба, или ты ебало завалишь и помолчишь?
https://www.computerenhance.com/p/clean-code-horrible-performance
( https://habr.com/ru/companies/sportmaster_lab/articles/728880/ )
https://habr.com/ru/articles/208454/
Это так, навскидку.
Остальное сам найдешь.
Если ты не читал обсуждаемую книгу и сказать тебе нечего - то лучше ебало всё-таки завалить
>хабр
Спасибо мне мнение людей даже без профильного образования по теме нахуй не упало.
Это базовая база. Мнение людей без образования в сфере о которой они пишут вообще не важно. Особенно когда очередной 2летний сенька пытается критиковать профессора университета и просто человека с опытом больше чем эта сопля на свете жила.
У Мартина опыт в инфоцыганстве, в программировании опыта нет. Ты сам себя обоссал, джунишка.
Мартин про себя пишет что 50 лет попыта. Трудовую конечно не показывает..
если долбоебы не понимают что "КАЖДОЙ ЗАДАЧЕ - СВОЙ ИНСТРУМЕНТ", то это проблема долбоебов.
Если в приоритете стоит перфоманс, то только имбецил будет пихать паттерны ради паттернов.
Однако чаще всего во главе угла стоит ясность и расширяемость решения. И там преждевременная оптимизация зло - банально все может быть выброшено или переделано.
твиттер был написан на руби с рельсами. результат все знают.
вк был на похапэ написан. результат все знают
а долбоебы могут сколько угодно писать оптимизированные быстрые решения, но только вот рынку они могут быть уже не нужны ибо "дорога ложка к обеду"
>твиттер был написан на руби с рельсами. результат все знают.
>вк был на похапэ написан. результат все знают
А потом они были с 0 полностью переписаны.
>А потом они были с 0 полностью переписаны.
Ты верно заметил - ПОТОМ!!!!! только сначала оно выстрелило. Получило признание и хайлоад, что понадобилось что то с этим делать.
Конечно всякие там паттерны нужно изучать через призму используемого ЯП, а также не забывать что паттерны это не только организация кода, а намного больше для коммуникации.
Но основные принципы написания расширяемого кода все же следует соблюдать - иначе вместо расширяемости будешь постоянно переписывать. А если еще и оптимизировать заранее, то может внуки проект и допишут....только кому он нужен будет уже хз.
У тебя ошибка восприятия. Были десятки и сотни клонов и других альтернатив. Важнее не быстро выйти на рынок, а убедить людей что пользоваться надо твоей залупой, а не конкурента.
Тем более что ты понятия не имеешь про качество кода этих систем и писали их не говношлепы типо тебя, а как раз гики которые любили дрочить на ассемблерные вставки.
>а убедить людей что пользоваться надо твоей залупой, а не конкурента.
Это уже дела маркетолухов. У программиста же другая задача - БЫСТРО РОЖАТЬ ФИЧИ которые нужны.
потому что ОТСУТСТВИЕ ФИЧИ как то не работает как привлекающий фактор.
и маркетолухам просто нечем убеждать людей "у нас лучше потому что у нас вот".
Так что скорость разработки проекта важнее скорости выполнения кода.
>не имеешь про качество кода этих систем
с этим не спорю, но все же RoR задавал архитектуру, да такую что щас куча фреймворков ее стырили себе (и асп.нет) не исключение.
там не "щас мы набросаем на батниках проект, на крон повесим и пойдем бухать".
кун 22 лвл tg : @linkijis
> БЫСТРО РОЖАТЬ ФИЧИ
Справедливости ради, быстро рожать фичи в аду фабрик абстрактных билдеров стратегий тоже сложно.
Но чистый код - это, напоминаю, не про то, чтобы адок создавать, а скорее наоборот
В рельсах нет абстрактных фабрик билдеров. Рельсы с точки зрения аспнетов это один сплошной антипаттерн. Все что в пыхе жаве дотнете считается антипаттерном в рельсах является паттерном и наоборот. Монки патчинг, наследование, названия методов из одного слова, генерация кода в рантайме и пр
С тех пор, как стало принято наследоваться не более одного раза от абстрактного класса.
>наследование
>антипаттерн
С появлением Automapper наследование стало ненужно.
Как-бэ эт совсем скорапчены процессы.
Обычно такие вы хотя бы какую-то роадмапу делаете.
И итерации бьются по этой роадмапе.
Так и заказчик, в широком смысле, и команда понимают что ожидается когда.
И выходит таки что-то в духе того что этот >>3358324 анон описал, но при этом - все видят, что процесс идет и если команда не проебывается - доверие есть, т.к. идут по этой роадмапе. А если в процессе - заказчик решает что ему надо чтобы красная машина еще в подводную лодку превращалась - есть возможность свернуть рано, а не: БЛЯ, ИДИТЕ НАХУЙ, МЫ МАШИНУ КРАССНУЮ ДЕЛАЛИ, РЯЯЯЯ, РЯЯЯЯЯЯЯЯЯ. Плюс - если шли нормально - то и вопросов будет мало, почему теперь добавить торпеды и погружение - занимает столько времени.
Бизнесу таки в первую очередь не скорость важна, а предсказуемость. Оба варианта которые ты написал - непредсказуемы нихуя. Не важно сколько они времени занимают и что там по фичам.
>антипаттерн
Да вообще все антипаттерн. Что в мозгу вкатунца не умещается, то значит и не нужно. Хуяк хуяк и погнали на продакшн, главное что за спринт успели и показали результаты. Я один хуй через 2 года уволиться планирую, а вы ебитесь потом сами.
>Бизнесу таки в первую очередь не скорость важна, а предсказуемость
Но сектанты гибкой разработки и аджаила свято верят что необходимо как можно быстрее показать результат чтобы бизнес мог внести правки и оценить промежуточные работы.
Все идеи гибкой разработки крутятся вокруг идеи что мы делаем хуй знает что, а проблема что с уровня атомарных фич мы перешли на попытки в таком стиле реализовать целые компоненты системы.
В целом лучше не браться за работу у людей которые не понимают что хотят.
Я вот ремонт делал. Нанял бригаду и дал им 200 страниц планов, схем, чертежей, списки материалов и номера красок, схему электрики и растоновки мебели. И как же было тяжело их отучить звать меня смотреть или спросить что-то, каждый раз я им говорил что видел конечный результат на рендерах, я видел образцы всех красок и материалов. Вот чертежи и схемы, делайте все по ним. Не надо менять звать и спрашивать где ставить розетки, выключатели и какую краску купить.
С тех пор как стало понятно, что наследование - это сложно, и в реальности - тебе чаще нужен только интерфейс, а не вся эта вот фигня с наследованием.
Так в реальности разработчикам никто не дает 200 страниц каких-то схем и прочего.
Тебе говорят: Надо автоматизировать завод.
Че автоматизировать? Да хз, неэффективно чет. Давайте, автоматизируйте.
А продажник такой: Ой, конечно, все сделам, дайте деняк только!
И тут две ветки.
1. В конторе все плохо с процессами. Разработчики по своему разумению что-то там изучают и что-то делают. В результате - результат непредсказуем от слова совсем.
2. Процессы таки есть. Но неясности все еще дохуя. Начинается попытка разобраться, что ж там таки надо автоматизировать. Сначала аудит процессов предприятия. Выявления мест узких. Выяснение с разработчиками - а что в этом мы можем таки сделать. Планирование. И т.д.
В реальности - не бывает практически такого, чтобы заказчик ПО пришел такой: Вот вам все что нужно для работы - работайте. Может быть в военке разве что.
>Так в реальности разработчикам никто не дает 200 страниц каких-то схем и прочего.
>Тебе говорят: Надо автоматизировать завод.
Раньше давали. Раньше прикинь делали документацию по процессам, диаграммы взаимодействия. Потом архитекторы писали кучу схем, документации технического толка, думали какие технологии и ЯЗЫК выбрать. Потом писалалось проектировачное решение, схемы классов, модулей. Потом все это разбивали на задаче и планировали трудозатраты.
И только спустя 1-2 месяца разрабы писали код по уже готовой системе.
Естественно эти процессы могли идти параллельно и пока программисты набирают код, архитекторы пишут новые части системы.
Сейчас за обосаные 300к от тебя надо быть разработчиком, архитектором, техписцом, аналитиком и ещё немножко разбираться в бизнес области. Отсюда и проблемы когда карьерный путь разработчика почему-то идёт в менеджеры, ну просто всех уровней технических специалистов выше старшего разраба просто не существует.
>С тех пор как стало понятно, что наследование - это сложно
Ты из тех категоричных сеньоров-два-года? Твой способ переиспользовать код ОБЪЕКТИВНО ЛУЧШЕ? Ебать, я угораю с вас, бледей
Переиспользованием "драгоценного" кода озабочены джунишки-короткие-штанишки. Реальная польза от переиспользования есть только в UI компонентах, да и там если логику от представления плохо отделить, то начинается сильно связанный говнокод - aka наследование.
Ну, то есть, ты просто копи-пастишь, а корректный код не осилил и осуждаешь
Причем тут связаность и наследование. Ты вообще понимаешь термины которые пишешь?
Вот тебе христоматийный пример наследования.
У нас есть разные виды отпусков, нам необходимо чтобы в целом их логика была довольно общей, да и структура. Там незначительно отличаются возможные даты, логика вычисления количества дней.
Поэтому мы создаём абстрактный класс отпуска, от него будут наследоваться все сущности разных видов отпусков.
Также создаём абстрактный класс операции который реализует общую логику и через абстрактные методы требует реализовать специфичные вещи.
Теперь опиши мне пожалуйста свою систему.
Коректного говнокода не бывает. Все многоуровневое наследование сводится к микроменеджменту копипасты - результатом чего становится запутывание кода, которое с каждым потомком становится все запутаннее.
Всегда когда дерево наследований, то по нему бегаешь и думаешь как изменение отразится на других элементах этого дерева. А нужно ли, чтобы столько кода было зависимым? У него реально одинаковые причины для изменений? Или ты просто занимаешься бесконечным рефакторингом потому что сам все запутал?
Например для одного потомка тебе стало нужно одно поведение метода базового класса, а для другого другое. Ведь ты же не будешь создавать похожие методы у базового класса при необходимости, а отрефакторишь еще одним слоем наследования?
Если у тебя есть действительно полезный большой кусок логики, то он выностится в сервис и используется через композицию.
Когда у тебя композиция, то ты в любом элементе можешь заменить конкретный сервис на другую реализацию и это никак не отразится на других элементах композиции, которые зависят от того же интерфейса.
>У нас есть разные виды отпусков, нам необходимо чтобы в целом их логика была довольно общей, да и структура. Там незначительно отличаются возможные даты, логика вычисления количества дней.
Делаешь один класс, в него передаешь стратегию расчета. Нахуй тебе наследоваться тут?
>Например для одного потомка тебе стало нужно одно поведение метода базового класса, а для другого другое. Ведь ты же не будешь создавать похожие методы у базового класса при необходимости, а отрефакторишь еще одним слоем наследования?
Даже не совсем так. Тут ты можешь еще поменять реализации этого метода у самих потомков. Но у потомков могут быть свои потомки которые захотят базовую реализацию. или другие методы будут требовать базовую реализацию. метода. Назуя такие головоломки...
Вы оба несёте какую-то хуйню. Не могут потомки требовать разной базовой логики своего предка иначе у тебя в предка протеает специфичная логика.
У меня ощущение что вы просто не понимаете как и для чего используется наследование и как выносят специфичную логику и базовую общую.
Ну или вы те шизофреники из-за которых в С# было решено отказаться от множественного наследования. Я такое видел в С++ когда люди Кошку от Транспорт и Животное наследуют потому что надо логику движения добавить.
Не перебарщивай просто и норм будет. Если тебя заебали с глубоким наследованием - это не причина хейтить наследование в общем случае.
Для каждого инструмента есть своё место (кроме Automapper, это говно из жопы).
>когда настолько боишься скопипастить код, что даже в простых задачах высираешь иерархии насследования
>Я такое видел в С++ когда люди Кошку от Транспорт и Животное наследуют потому что надо логику движения добавить.
Как же вы заебали со своими реалистичными примерами
нахуя тебе иерархии? глубоко не наследуйся и не еби мозги
Спроси это у шиза, который для расчета отпусков собрался писать иерархию наследования.
Ясно. Теперь мы перешли от наследования к наследованию на пол шишечки от абстрактного хуя..
А потом приходит сенька с улицы и спрашивает почему тут final, что за самомнение у писавшего...
>собрался писать иерархию наследования
Вроде он написал, и у него всё норм. Это ты кривишь ебало от слова наследование без какой-либо мотивации.
Это как если сказать ФУНКЦИИ ГОВНО, ИХ НЕЛЬЗЯ ПИСАТЬ.
Еще раз тебе лупню объясняю. Читай книжки про разные подходы программирования, бери самое адекватное из них.
Хабр не читай, там инфоцыгане категоричные срут своими "ПОЧЕМУ ООП БЕЗНАЖЁЖНО УСТАРЕЛО И НУЖНО ПЕРЕХОДИТЬ НА АОП"
Так а ты-то можешь кейс привести, кроме UI-элементов для библиотеки GUI, где глубокое наследование не будет говном-то?
Я вот могу привести кучу случаев когда обосрамсы из-за этого или говнодизайн. Потому что я сам в бытность джуном-мидлом ну очень сильно любил наследование.
>кроме UI-элементов для библиотеки GUI
так а чего ты сразу то так.
видимо мой урок в прошлых тредах усвоили
так ответ тот же - КАЖДОЙ ЗАДАЧЕ СВОЙ ИНСТРУМЕНТ (подход)
причем этот гуи может быть и компонентный подход к асп.нет (примерная аналогия виджеты)
Смотря что пишем. Если его можно убрать, то вполне себе. Даже полезно потому что заставляет задуматься, а почему кто-то решил что его нельзя наследовать.
Но вот за такую хуйню без чёткой необходимости в библиотеке надо бить по голове.
> Потому что я сам в бытность джуном-мидлом ну очень сильно любил наследование.
то есть, ты сам долбоёб, и на своём примере всех осуждаешь. А как ты понял, что бы перестал быть джуном-мидлом?
Сам так решил или тебя короновали?
Так я и не спорю что есть таки места, где наследование ОК.
А есть места, где и все статик-классами все ебануть ОК.
А где-то и синлтон классический не хуже будет чем DI'ешный.
А еще ансейфом шлифануть иногда тоже бывает неплохо.
А когда-то и лучше будет ручками SQL запрос написать, вместо того чтобы на ОРМ полагаться.
Иногда и воскрешать объекты - не такая плохая практика.
А если дальше - переписать все на си или фортран - тоже может быть хорошей идеей иногда, срсли.
Только вот как-бэ. Если мы говорим про кейсы как тут >>3360037 оно там нахуй не уперлось.
А дальше начинается уже включаться реальная практика. И мы видим, что в обычном крудостроении и формошлепстве, которым 99,(9)% сидящих тута занимаются - оно нахуй не уперлось, а проблем от него в конечном итоге будет больше, чем сразу без него.
Не, ну я понимаю, кому-то надо чтобы понять - собрать самому все грабли.
>>3360161
Твою маму спросил, няша.
> Даже полезно потому что заставляет задуматься, а почему кто-то решил что его нельзя наследовать.
В "своём" коде нет технических причин, почему класс нельзя наследовать. В библиотечном - другое дело, там это нужно чтобы пользователи инкапсуляцию не поломали.
я все классы помечаю как sealed, так код читается быстрее.
Лет 20 уже. Наследование часто сильно всё усложняет, когда у тебя куски реализации одного и того же раскиданы по куче мест, а из-за переопределений далеко не всегда очевидно, какой конкретно метод вызывается.
Рекомендуется вместо наследования использовать композицию.
Аутомаппер зло и не нужен. Лучше лишний раз написать маппинги руками, чем огребать из-за всей этой неочевидной магии.
Всё начинается просто, когда у тебя почти одинаковые классы друг на друга замапленны. Потом ты из нескольких объектов один собираешь. Затем правила всё усложняются, а в итоге у тебя прямо в конфигурации маппингов куча бизнес-логики, обращение к микросервису и запрос в БД.
>куски реализации одного и того же раскиданы по куче мест,
Ещё раз. То что ты не можешь нормально спроектровать систему твоя проблема.
Композиция не может быть заменой наследования потому что они выражают абсолютно разные понятия. Ты бы это знал если бы хотя бы пытался получить нормальное образование по ИТ.
Композиция это "состоит из"
Наследование это "является этим"
Ты не можешь заметить одно другим.
>еще раз
Дохуя Высотский? Эх раз да и еще раз..
Сам ты не разбираешься. Сейчас же время дивесити. Хочешь быть уткой - просто крякай. Например голенг тот самый диверсити язык. А жабошарпы с номинальной типизацией это устаревщие традици с генеалогическими древами, где вырожденцы хвалятся тем, что они потомки князей, а по факту бухают и ебутся со шлюхами как простые работяги. Только бухло подороже и шлюхи послаще...
Если ты не понял то нихуя уже не очевидно что многоуровневое наследование нужно для написания сложных вещей. Кубер написан без этих наследований.
Наледование просто притащили вместе с номинальной типизацией как инородную хуйню в программирование, а как с толком использовать это инфу не придумали.
Пролезать в интерфейсы можно без наследования и явной имплементации. Делегировать поведение можно без наследования, через композицию.
https://drive.google.com/file/d/1-DV7IA1pD6jd7OMAxhEDQdlQmW9Y913K/view
Это доки по игре на моногейме с очень подробным описанием кода на C#.
Сама игра https://icefish-software.itch.io/arid-arnold
>>куски реализации одного и того же раскиданы по куче мест,
>Ещё раз. То что ты не можешь нормально спроектровать систему твоя проблема.
Я могу нормально спроектировать систему без наследования. Занимаюсь этим уже много лет, кучу всего написал.
>Композиция не может быть заменой наследования потому что они выражают абсолютно разные понятия. Ты бы это знал если бы хотя бы пытался получить нормальное образование по ИТ.
У меня степень магистра, чувак. Я в универе успел пописать языках на 15, и ни в одном из них отказ от использования наследования (там, где оно есть) ничего не усложняет.
>Композиция это "состоит из"
>Наследование это "является этим"
>Ты не можешь заметить одно другим.
Является -- это реализация интерфейса. В случае наследования это зачастую совсем не работает. Как пример -- напиши мне иерархию из параллелограмма, прямоугольника, ромба и квадрата с конструкторами с заданием сторон/углов и, к примеру, свойством возвращающим площадь. И ты сразу поймёшь, что наследование -- это совсем не "является".
>Делегировать поведение можно без наследования, через композицию
Причём тут делегирование поведения и наследование. Что за хуйню ты блять несешь.
>Аутомаппер зло и не нужен.
По сути, ручное присваивание это смердящий ЗАПАХ КОДА и оно должно быть запрещено, так же как вызов NEW.
По сути, согласно правилу бинарных зависимостей, в конструкторе должно быть только 2 зависимости, IMapper и IMediator.
Окей.
Ты можешь спроектировать.
Давай, объясняй на пальцах, от кого я должен наследоваться?
>>3360234
>Я в универе успел пописать языках на 15
Это не аргумент. Хоть я сейчас пишу в основном только на C#, я тоже могу насчитать ещё 5 языков на которых я писал, но это не значит что я их знаю. Вон как я выше написал, кто-то и по 20 лет пишет на C# никогда не использовать некоторые его фичи, а потом используют это как аргумент своей правоте.
мимо бомбануло ещё с комментов вчерашнего поста на Reddit
>Сейчас за обосаные 300к от тебя надо быть разработчиком, архитектором, техписцом, аналитиком и ещё немножко разбираться в бизнес области
Буквально суть моей работы. У нас и тестеры немного системные аналитики и разбираются в бизнесе, короче весело живем.
На днях мидл пришел, тоже говорил что медиатр говно, не ответил нормально почти ни на один вопрос, это ты был?
Кстати почему медитр говно? Ты же буквально в один файл кладешь запрос+хэндлер. А в вызове явно указан запрос и все это ищется использованием по ссылкам.
Немного сложнее становится только когда речь про нотификации заходит, но такие фичи никто не юзает почти.
Даже если не использовать ECS в реальном проекте будут компоненты использоваться, в один класс Unit будут добавлены 2-3 компонента - Attack, Cast и возможно HP.
То есть опять композиция вместо наследования. Игры кстати посложнее крадошлепства в плане логики, и как раз там не используют такие сложные иерархии.
А кто такой "фичей" как наследование не пользовался в языке никогда? Наоборот этого в каждом легасном проекте как говна за баней.
> от кого я должен наследоваться
От NPC, ясен хуй, ты же предыдущих двоих NPC от NPC унаследовал
>Кстати почему медитр говно?
Потому что он никаких проблем не решает
> Ты же буквально в один файл кладешь запрос+хэндлер
А какая проблема-то была?
Почему не инжектят IServiceProvider?
Почему не кладут интерфейс и реализацию в один файл?
Я в частности не люблю медиатр, потому что с дженериками заебался. И навигация по коду как в болоте
> Почему не инжектят IServiceProvider?
Почему? Я инжекчу в фабрики
>Почему не кладут интерфейс и реализацию в один файл?
Я кладу. Я бы и без интерфейсов обошелся если честно, они же тоже никакую проблему не решают, если у тебя только один класс который его реализует (и в 90% так и есть)
Так что и медиатр не нужен, и интерфейсы не нужны. Кайфово. Автомаппер все проблемы решает.
как твой автомаппер решит проблему тестирования если ты уберешь интерфейсы?
>Почему? Я инжекчу в фабрики
Ну логично. Но я к тому, что инжектить медиатр в контроллеры или сервисы это примерно такое же самое, что и инжектить туда IServiceProvider.
Это значит терять контроль над зависимостями, а это ну такое себе.
Не слушай долбоёбов. У тебя проблема в том, что ты написал псевдокод и нельзя сказать решение в общем случае. Если у тебя есть общий интерфейс для всех NPC, реализация которого возможна под все типы NPC, то добавляй уровень абстракции и делай так, чтобы путём композиции можно было объединить ваириора и мага.
А зачем мне для тестов ложить интерфейс и реализацию в разные файлы? То-то же.
>А зачем мне для тестов ложить интерфейс и реализацию в разные файлы?
Ну ты же файл тестируешь
Я это не пытаюсь авторитетом задавить, я это сказал исключительно на попытку выставить меня новичком.
В принципе ты прав, но не в данном случае. Меня в том же универе учили ООП, вся эта поебень с "является", "уточнение", "подмножество" и вымученными примерами сущностей человек - студент, человек - препод с методами прочитатьЛекцию() и сдатьЗачёт(). Я вполне могу и с наследованием систему спроектировать, но сознательно выбираю проектировать без наследования.
Я ещё и стараюсь, чтобы классы с логикой не имели состояния, чтобы не ебаться с лайфскоупом и тред сэйфти.
Вопрос был не про класс и интерфейс в одном файле, а про наличие интерфейсов вообще.
Как ты класс в юнит тесте мокать будешь? Там вызовы методов можно замокать только если они виртуальные, а это большая редкость.
>поебень с "является", "уточнение", "подмножество" и вымученными примерами сущностей человек - студент, человек - препод с методами прочитатьЛекцию() и сдатьЗачёт().
Ну значит ты просто тупой. Это не вымученые примеры, ожидается чтобы даже дебил понял, но ты вот не смог.
СдатьЗачет методом класса быть не может это сложный процесс. Метод класса Студент это ДатьЗачетку(), ПолучитьУчебник().
Ты не понимаешь просто что твои попытки не использовать наследование приводят к говно коду который невозможно будет рефакторить. А не можешь понять потому что тупой и не осилил понять и осознать зачем и когда применяется тот или иной подход. Тебе нравится делать что-то, ты и делаешь это везде и похуй что ты гвозди отверткой забиваешь.
.NET целиком построен на сложном и развесистом наследование, использование интерфейсов это наследование(интерфейсы это абстрактные классы с точки зрения приложения), любой стандартный класс это потом 3-5 классов. Весь LINQ и система коллекций это наследование и правильное использование нужных типов.
Абсолютно все крупные приложения что ты можешь вообразить содержать огромные схемы классов и имеют глубину наследования вплоть до 10 уровней.
Даже банальная авторегистрация зависимостей или их вызов основаны на наследование и получение потомков.
>имеют глубину наследования вплоть до 10 уровней.
А некоторые и по 3 конфигурации автомаппера!
Когда последний раз вы использовали goto?
Ты прямо как Петрович с завода, считающий что никто кроме тебя не понимает как гайки крутить. Ух все тупые..
Да. Наследование и композиция это два разных инструмента. Но тут в треде усираются что наследование нужно для переиспользования кода. Как раз для переиспользования наследование не нужно, а нужна композиция. Все паттерны про это.
Наследование остается для работы полиморфизма. Просто так жабошарпы да и много другие языки работают, что нужно наследоваться чтобы работал полиморфизм для сабкласов.
А там где в паттернах используется наследование, оно там не для переиспользования кода, а именно для того чтобы принцип подстановки Лисков работал. Например простой паттерн декоратор.
В пет проекте, 16.12.2024. Ебало в норме, мать жива.
Вообще я заметил что я пользовался им раз 20, зачастую для скипа какого-то кода (где из разных мест метода нужно прыгнуть в его конец где нужно выполнить ещё какой-то код (что-то типа early exit, но только в следующую часть метода)). Где-то можно было обойтись (например, на методы разделить и т.д.). Я нейтрально отношусь к goto, так что, хочу - использую, хочу - не использую (единственное "правило" - прыжки только вперед метода).
Единственное правило - с ним лучше чем без него
И плевать куда прыгать
Goto добавляет выразительности. Стараюсь использовать его как можно чаще.
В 2020-м. Но там язык был такой, что ветвление или циклы можно было организовать только в виде IF <cond> GOTO <label> и никак иначе.
В шарпе только один раз в switch-е и то по приколу, чтобы товарища подъебнуть.
Всё охуенно
Программировать любой дурак может
Ты попробуй деньги заработать
>.NET целиком построен на сложном и развесистом наследование, использование интерфейсов это наследование(интерфейсы это абстрактные классы с точки зрения приложения),
Нет. У интерфейсов нет реализаций, это ключевое отличие.
>любой стандартный класс это потом 3-5 классов. Весь LINQ и система коллекций это наследование и правильное использование нужных типов.
Linq - это методы расширения, повешенные на IEnumerable<T>, никакого наследования там нет.
>Даже банальная авторегистрация зависимостей или их вызов основаны на наследование и получение потомков.
Реализация наследованием не является.
Итак, где иерархия из параллелограмма, прямоугольника, ромба и квадрата?
Не можешь в множественное наследование? Ну давай хотя бы квадрат и прямоугольник.
>Нет. У интерфейсов нет реализаций, это ключевое отличие.
Default interface members?
>Linq - это методы расширения, повешенные на IEnumerable<T>, никакого наследования там нет.
Мне кажется, что он говорит про внутренности реализации.
>Реализация наследованием не является.
А я бы сказал что это ограниченная форма наследования.
>Нет. У интерфейсов нет реализаций, это ключевое отличие
Во-первых, есть. Во-вторых, интерфейс это не изобретение С# а паттерн такой. В других языках он буквально делается через абстрактные классы.
Конкретно в С# это сахар и реализации философии множественого наследования только для поведения, а не структуры. Они выделены отдельно чтобы запретить множественое наследование классов. В IL коде нет никакой разницы нследовал ты абстрактный класс или интерфейс.
>Default interface members?
Это не наследование. Можешь рефлексией проверить, там у объекта не будет этого метода.
>А я бы сказал что это ограниченная форма наследования.
Моя конкретная претензия к наследованию заключается в возможности переопределения методов и свойств, что ещё ухудшается тем, что в шарпе они бывают виртуальные и нет.
>>3361596
>Во-вторых, интерфейс это не изобретение С# а паттерн такой. В других языках он буквально делается через абстрактные классы.
В других это в каких? В крестах, лол? Это не пример для подражания.
>Конкретно в С# это сахар и реализации философии множественого наследования только для поведения, а не структуры.
См. выше мою претензию к наследованию.
Ты писал приложение на современном кроссплатформенном дотнет-коре, а требуется запускать его на дотнет-фреймворке-для-винды пятнадцатиледней давности.
3.5 фреймворк поддерживается до 2029 года. В принципе, ты можешь попробовать под него переписать, но будет скорее всего сложно, что-то сравнимое с попытками работать на windows-xp.
Так же рассмотри вариант обновить фреймворк до 4.8 на целевых машинах. Сама разработка будет значительно проще. Или у тебя ограничения?
https://en.wikipedia.org/wiki/.NET_Framework_version_history
>См. выше мою претензию к наследованию.
Нет, никаких ограничений. Просто хотел, чтобы программка запускалась везде без дополнительных танцев с установками. До версии 4.8 обновить без проблем.
Возможно, тебе подойдет self-contained публикация приложения - тогда совсем не будешь зависеть от установленных на целевой машине фреймворков.
Но вырастет размер приложения, так как в релиз будут включены все зависимости и исполняемая среда.
Понял, не судьба значит. Я тогда уж на питончике наваяю с pyinstaller. Плюсом кроссплатформенность появится.
Че ты как баба со своими окошками. Делай CLI и не еби мозг.
>pyinstaller
Пробовал я этот ваш pyinstaller, заебался, так ничего и не заработало
>Плюсом кроссплатформенность появится.
ты как то определись для винды или кросс
а то прыгаешь со стула на стул.
знаешь питон - ваяй на питоне. какая разница то
в обоих случаях это будет self-contained
https://www.reddit.com/r/dotnet/comments/1i17jm0/fluentassertions_becomes_paid_software_for/
Мнение?
Как меня бесит опенсор, как я ненавижу контрибьюторов, сука, просто пиздец. Особенно контрибьтеров в опенсорс, охуеть вообще. Сука. Коммитят тут, радуются. Скоро за каждый юзинг платить будете, бляди!
Ура, больше не будут везде тащить эту шизу для гуманитариев.
Похуй, я этим говном не пользуюсь. Это вообще шиза, вместо простого assert(x>2) писать ебаное сочинение "как я провел тесты".
Для винды, но я думал сделать штатными средствами, чтобы без установки всяких допов было.
FluentAssertions очень спорное, пользуюсь им только потому что хотел своих разрабов привлечь к написанию тестов потому что они дуреют с прикормки билдеров и синтаксисов.
Сам таким говном никогда бы не стал пользоваться. Потому что xUnit идеален:
True(expected);
>Кстати почему медитр говно?
Вся идея Медиатра разваливается нахуй на первом POST запросе с query-параметром и телом. Начинаешь хуярить слои и копировать одинаковые классы.
Я с этой хуйнёй проебался несколько лет, потом понял, что MediatR что это буквально охуенный способ запретить себе писать обычные методы с названиями и параметрами и нахуярить семислойную матрёшку, где у тебя 3-5 абсолютно одинаковых типов только для того, чтобы что оправдать бестолковость использования автомаппера?
или нахуя?
>Ждём, когда автомаппер платный станет
Automapper.Generators платный вышел, так же как Automapper.Async
>но я думал сделать штатными средствами
ну так делай
self-contained для дотнета куда более штатный чем pyinstaller для питона
а делают то же самое.
Я нашел, что можно компилировать csc.exe из папки с фреймворком. Попробую в один файл загнать и интерфейс, и логику во славу Нерзула.
Вообще никаких проблем не замечал. Медиатр хорошо структуру задает, особенно учитывая что никто в треде не знает ни ддд, ни гексы, ни чистую.
Я хз как вы код пишете. Вернее почему хз, я видел как вы пишете, от медиатора точно хуже не станет.
>я видел как вы пишете
неа. не видел.
>от медиатора точно хуже не станет
добавит лишний уровень косвенности там где и без нее норм.
вот я не пишу на асп. но вот читаем на мсдн
"контроллер ASP.NET Core отправляет команду в конвейер команд MediatR, чтобы они попали в соответствующий обработчик."
а этот "соответствующий обработчик" совсем никак нельзя просто прямо вызвать что ли?
Ах да, тогда ведь нельзя будет навесить всякие там бехавиорсы, которые быстро создадут "хрен пойми что где куда и зачем вызывается" и понадобится особо кое что делать вприсядку чтобы во всем этом был хоть какой то порядок.
>Медиатр хорошо структуру задает
Только если используется не более чем в одном слое приложения и если это приложение архитектурно заточено под собственный протокол.
Во всех остальных случаях медиатр - мусор.
> особенно учитывая что никто в треде не знает ни ддд, ни гексы, ни чистую.
Каким боком Медиатр относится к ДДД, восьмиугольнику или чистой архитектуре? Боллее того, Медиатр ломает чистую архитектуру потому что все команды приходится складывать в один слой, который пухнет
>Я хз как вы код пишете. Вернее почему хз, я видел как вы пишете, от медиатора точно хуже не станет.
Чел, я был свидетелем того, как один хуй с помощью медиатра из сервиса на 5000 строк раздул недифференцируемый Уроборос без начала и конца.
Оставьте пожалуйста это говно в 2016 году
> особенно учитывая что никто в треде не знает ни ддд, ни гексы, ни чистую.
Из всего этого только чистая реальная тема.
ДДД это чистое инфоцыганство. Гексогоналка вообще хуй пойми что, никто не знает о чем это только могут нести хуйню из промо буклетов для говноедов.
>а этот "соответствующий обработчик" совсем никак нельзя просто прямо вызвать что ли?
Гуманитарии попали в программирование. Они пишут код, как книги по философии: из простой идее высирают 20 томов графомании. Медиатр, автомапер, Should().Be().Equal().To().Value().Of(2) вместо assert(x==2) - это все признаки гуманитарных долбоебов.
> Should().Be().Equal().To().Value().Of(2)
🤩🤩🤩
Обожаю Fluent синтксис. Когда пишу так, как будто на родном английском говорю. И всё сразу понятно!
>Медиатр, автомапер
Говорят, в Asp.NET core 10 включат свою версию Автомаппера. Джеймс Монтемагно пишет, что это добавит выразительности и необходимо для новой встроенное реализации медиатра.
код ВНЕ тестов тоже так пишешь?
Нет? а что же ты такой двуличный, пишешь непонятные закорючки вместо англотекста?
код чужих проектов и либ. пытаясь разобраться в устройстве
код стандартной библиотеки (открой хоть хешсет исходник и познавай) - там тоже много разного
кодить не надо. просто чужие приемы и такой "аааа, круто придумано".
>Таненбаум
чему ученый генетик из биошока сможет его научить
Код надо писать, а не дрочить очередей талмуд. Придумай себе какой-нибудь проект и пили.
а вот и нет. код нужно ЧИТАТЬ. не порти ньюфага своими глупостями
Читать чужой код надо только корпоративным рабам, а свободным господам стартаперам код надо писать.
>код надо писать.
ГОВНОкод разве что.
ну да, можно. заказчки код не читают. сам потом жрешь свое говно
>код ВНЕ тестов тоже так пишешь?
Да, чтобы коллегам легче читать было на флуенте. Так выразительней. У нас все это экспрешшен. Есть правило, не более чем одна точка с запятой на метод.
выходит что стандартная библиотека говнокод?
код асп.нет говнокод?
кот того же медиатра говнокод?
хули ты тогда шарпист, если в шарпе только говнокод?
у тебя синдром утенка
ты увидел свой код и подумал что он идеал
тебе уже ничем не помочь.
>кот того же медиатра говнокод?
Да, там 300 строк по идее должно быть, но он раздут до каких-то невменяемых размеров.
по какой идее
велосипед? ну велосипед может да. а если делать "по красоте", то строчечки размножаются
чем тебе не угодило наличие котика.
впрочем, никто не заставляет пользоваться ни медиатром ни котиком
> не заставляет пользоваться медиатром
Помню, как я первый раз после своего джунства после трёх лет ебли с автомаппер+медиатр попал на проект, где ребята не грели себе мозг, а просто писали код на C#.
Я до этого думал, что занимаюсь DDD, чистой архитектурой и cqrs, и что вокруг меня умные люди, а оказалось, что занимался я говном, а вокруг меня были долбоёбы с синдромом архитектора.
Спустя время узнал, что челики, от которых я ушёл просто перестали справляться и их проект развалился к хуям. Туда им и дорога
Единственная проблема автомаппера это рефлексия. В остальном это чистое спасение.
У тебя похоже никогда не было необходимо поддерживать статические классы на 8000 строк с описанием мапингов системы. Я ебал рот бля, это учитывая что у одной сущности могло быть до 10 ДТО.
есть решения которые генерят маппинги в компил тайм
в результате получается код который можно пощупать
что тебе автомаппер этот.
>У тебя похоже никогда не было необходимо поддерживать статические классы на 8000 строк с описанием мапингов системы.
Автомаппер как-то решает эту проблему?
Типа - вот сделал я модельку. Чел такой - ой, а я у себя сделаю модельку модельки уже для представления. А потом свой сервис для работы со своими модельками. А сверху - сделаю уже вью-модельку.
В результате, моделька базовая - реактивная, но ее вокруг оборачивает другая реактивная моделька, которая просто прокидывает что-то в обе стороны. Сверху это в сервис оборачивается. Потом - уже вью-модель берет сервис...
А где-то через год - у вас баг с тем что что-то задублировалось и ебись как хочешь - ищи где хочешь. На каком уровне обосрамс - хуй знает, потому что писать же руками проперти - зашквар, пусть будет кодогенерация через MVVM-тулкит) Я ебал в сраку того кто придумал что это удобно. Надеюсь он сдохнет и его так же никто не найдет потом, как невозможно что-то найти с этим говном автосгенерированным Я шучу конечно, ебал я в сраку себя, за то что такой беспозвоночный и не смог отстоять ненужность этой хуйни
Короче. Пришел к выводу, что лучший подход - это идти по тому же пути что и клиент-сервер. Ядро системы - сорт оф сервер. Никакого состояния не хранит, просто принимает команды, запросы - отдает по "протоколу". То что на визуале - нихай складывает себе в какой хочет стейт и как хочет ебется.
Ну тут проблема очевидно в том, что деление ответственности должно быть не по слоям, а по фичам.
Без реального сервера ты просто создашь себе проблем и через год придешь переписывать обратно
Потому что это всегда сорта стульев
Та блин. В чем стулья? Я просто хочу чтобы не возникало 2-3-10 мест где разные состояния и надо их синхронизировать.
Отлаживать это - пизда. Тут юзера изменили. Там он еще не синхронизирвался. Тут - уже, что-то произошло, потекло говно по трубам.
Что значит синхронизировался. Ты пишешь десктоп софт или что?
> Ты пишешь десктоп софт или что
А что еще пишут с MVVM?
> Что значит синхронизировался
Ну. Вот у тебя есть где-то в слое приложения ApplicationState.
В нем CurrentUser.
Этот стейт - реактивный. При этом - синглтрон.
Далее на уровне представления - у тебя есть вью-модель. CurrentUserAvtarPanelViewModel.
Разработчик этой части - решил что ему не хочется просто стейт брать, он хочет сделать свой CurrentUserVisualModel и свой CurrentUserVisualService. И уже сервис такой - берет из стейта, перекладывает CurrentUser'а в свой CurrentUserVisual.
Теперь. Какой говняк происходит. На уровне приложения - говняк, надо разлогиниться. Визуальной части надо получить изменение. И уже у себя изменить. Далее, если визуальная часть изменяется - она должна опять через всю цепочку дать знать ApplicationState что там юзера переименовали или картинку ему поменяли.
Это через год превращается в ебаный цирк.
>А что еще пишут с MVVM?
кто знает. вон Razor Pages например
может блазороведы блазорят блазорки по эмвивиэмному
>На уровне приложения - говняк, надо разлогиниться. Визуальной части надо получить изменение. И уже у себя изменить. Далее, если визуальная часть изменяется - она должна опять через всю цепочку дать знать ApplicationState что там юзера переименовали или картинку ему поменяли.
не уловил сути проблемы. то есть я понимаю задачу, но не твою проблему
> не уловил сути проблемы
Проблема в том, что нет центрального источника истины.
Так понятно?
В обычном жс-фронте, у тебя обычно есть какой-то единый стейт. Он - твой альфа и омега. Все остальные компоненты - лезут в него, смотрят что там. Далее в зависимости от технологии - как-то могут модифицировать, напрямую, через хуки-хуюки, через команды, да поебать. Суть в том что реальный стейт - один. Если тебе надо посмотреть что происходит - ты берешь компонент, берешь стейт. Сравниваешь. Обычно связь такая: Компонент - стейт. Все. Изолировать какую-то пробему - просто.
В ситуации же которую я описал - у тебя стейтов несколько на нескольких слоях. Какой правильный - хуй его знает.
Особнно охуенно, когда визуальный стейт - взял, и обновил себя заранее, не дожидаясь что на уровне приложения, а приложение кинуло ValidationException которое улетело в пустоту, и типа - вот кнопку нажал, что-то загорелось, должен следующую нажать, нихуя не происходит. Иди ищи. А приложение-то не кинет изменения состояния, чтобы визуальный стейт синхронизировался теперь, ведь изменения не произошло. Вот теперь у вас два состояния, одно визуальное, одно на уровне ниже.
И единственное решение которое я вижу - все состояние должно уехать на "визуальный" уровень. А то что ниже - только выполнять команды и в базу писать. Все.
>взял, и обновил себя заранее
что обновил заранее? зачем ты обновляешь заранее? сначала ты выделяешь дополнительный "локальный" стейт чтобы через него работать как то его синхронизируя, а потом жалуешься что оно дескать может быть не синхронно.
>у тебя стейтов несколько на нескольких слоях
у тебя
ты плодишь стейты, хотя они и так есть.
модель - стейт
вьюмодели - визуальный стейт.
Ты либо модифицируешь визуальный стейт, либо, если это касается модели - уже передаешь задачу модели
Каждый отвечает за свою часть - какая еще синхронизация нужна
теперь попробуем понять что ты там понаписал
>И уже сервис такой - берет из стейта, перекладывает CurrentUser'а в свой CurrentUserVisual
ммм. ну обычное дело. чай визуальная модель и модель часто не совпадают.
>Визуальной части надо получить изменение. И уже у себя изменить
ну получила и изменила. чем это отличается от твоего жс фронта где подписаны на какой то там стейт, реагируют меняются, но еще одного "сабстейта" не плодят
>Далее, если визуальная часть изменяется - она должна опять через всю цепочку дать знать ApplicationState что там юзера переименовали или картинку ему поменяли.
так устроен MVVM, но опять хз в чем проблема кроме того что вьюмодель посередине между GUI и моделью стоит?
реально не понимаю твою проблему
>возникало 2-3-10 мест где разные состояния и надо их синхронизировать
ключевое СИНХРОНИЗИРОВАТЬ. Непонятно что такое "синхронизировать".
>Тут юзера изменили. Там он еще не синхронизирвался
непонятно где "там".
ты банальное "эй юзерсервис сохрани юзера" заменяешь на " я положу в список, а далее механизм синхронизации уведомит кого то в модели и засинкает изменения"?
в общем я нипанимат что ты хочешь наворотить и зачем.
А ты чего не сделаешь единое состояние, которое переживает все вью-модельки? А вью-модельки создадутся поверх него и подпишутся на его события?
Выглядит как будто у тебя основная логика уехала на вью-модельный уровень, а уровень репозиториев у тебя слабый.
Ещё вопрос. А чего вы на экране рисуете? Что-то сложное?
Хочу вкатиться в мышиное обучение. Без змеи никак?
Питон уже почти не используется в машинном обучении, это стереотип
Я вообще в финтехе работаю.
Вот думаю, в свободное время может начать участвовать в ML.Net сообществе? Заодно и погрузиться в мышинное обучение без отрыва от основной работы/стека, и может стать частью опуенсорсного сообщества ML.NET? Может, мои коммиты примут со временем, какие-нибудь там статьи напишу, всё такое.
Питонистов, например, сейчас много. А спецов по ML.NET, наверное, меньше. Может и спрос на них на каком-то этапе больше.
https://www.linkedin.com/pulse/embracing-future-machine-learning-comprehensive-guide-bansal--niwzc/
>что обновил заранее? зачем ты обновляешь заранее? сначала ты выделяешь дополнительный "локальный" стейт чтобы через него работать как то его синхронизируя, а потом жалуешься что оно дескать может быть не синхронно.
Я не обновляю заранее. Обновляет заранее тот кто пишет визуальную часть и кто решил что ему надо еще своих стейтов.
> непонятно где "там".
Я ж расписал...
Ну ладно. Еще раз.
Вот у меня приложение для заметок.
Есть NoteModel - определен в App.Domain
Есть NoteService - определен в App.Application
Далее - есть NoteVisualModel - определен в App.UI
Есть NoteVisualService - тоже определен в App.UI
Сбоку есть NoteViewModel - пользуется NoteVisualModel.
NoteViewModel - дергает NoteVisualService
NoteVisualService - дергает NoteService
NoteService - лезет в БД, пытается что-то сделать, обновляет в случае чего NoteModel
Так вот. Теперь у нас включается человеческая криворукость.
Кто-то берет и обновляет стейт NoteVisualModel в обход всего этого дела. В результате - мы имеем неконсистентное состояние. И оно теперь никак не синхронизируется.
> в общем я нипанимат что ты хочешь наворотить и зачем.
Я хочу чтобы добиться неконституционного состояния было нельзя...
>>3365921
А я изначально так и хотел. Чтобы у нас был на уровне приложения определен стейт. И из него просто брали, и пытались модифицировать. Но по ряду причин, в виде 3 сеньеров, которые каждый сам с усам - получилось что получилось.
> Выглядит как будто у тебя основная логика уехала на вью-модельный уровень, а уровень репозиториев у тебя слабый.
Именно прикладная логика - на уровне приложения. Полностью.
Просто там дюже много красявостей, типа тут что-то изменилось., там должно заморгать, при наведении мышки - перестать моргать, там заблокироваться, тут прогрессбар с процентами... Ну короче, там из-за того что дизайнеры надизайнили красявостей таки получилось так, что вот эти красявости много логики и на визуале в плане этих самых красявостей требуют.
При этом - не хочется чтобы эти требования к красявостям проникали на уровень ниже.
> Ещё вопрос. А чего вы на экране рисуете? Что-то сложное?
Ну. Не то чтобы прям сложное. Просто типа вот нажали кнопку на этой панельке, там должно заблокироваться, тут - заморгать индикатор, это подсвечиваться.
Плюс - возможность пользователю все перенастроить, скрыть, перетащить куда надо, ресайзить и вот это вот все.
Раньше было заебись - берешь DevExpress и погнали. Щас DevExpress нельзя, приходится искать что-то более-менее годное или руками делать.
>При этом - не хочется чтобы эти требования к красявостям проникали на уровень ниже.
А у тебя выбора другого нет. Если одни элементы визуально связаны с другими - ты хоть разбейся, но придётся это выносить на более глубокий общий слой.
От тебя по ходу требуют писать красивое приложение с анимациями и прочей поеботой, но ты сопротивляешься. А у тебя домен по ходу это рюшечки и моргающие кнопки
Нууууу. Я это обошел через шину.
Что-то происходит на уровне домена - визул реагирует. Домену похуй на взаимосвязь визуальную.
А так - да. Требуют рюшей.
Но я уже не раз был в ситуации, когда сначала требуют красявостей, чтобы показать. А через неделю пользования - прилетает от конечного пользователя - дайте возможность все красявости нахуй вырубить и вот такенный список уже нормальных требований по функционалу. Потому - не дам этой хуйне место в домене.
решение твоей проблемы просто - ВЫПИСЫВАНИЕ ПИЗДЮЛЕЙ тому, кто пишет херню и нарушает правила.
потому что можно из вида и напрямую в бд залезть и в космос и вообще в другую реальность. Вот только это будет уже нарушение паттерна
насчет NoteVisualModel
смотря что ты под ним понимаешь.
вот для меня есть пара стульев
1 каждая вьюмодель держит в себе свой стейт и общается с другими вьюмоделями какими то событиями заставляя их менять свой визуальный стейт. Все размазано, особенно беда с командами и антипаттер god object много где
2 делаем единый стейт который помесь медиатора с вьюмоделью/презентнорм. Всё меняется в нем и вьюмодели слушают уже его изменения используют напрямую. И команды в нем - он в модель и ходит. Далее изменяет свой стейт и вьюмодели обновляют себя.
и оба варианта говно.
Ему просто нужна такая древняя магия дидов как потребитель-производитель ака событийная модель взаимодействия.
Очевидно он пытается сделать так чтобы разные части приложения реагировали на какие-то действия в других частях. Единственный правильный способ сделать такое это создать сквозной слой шины событий.
Если событийная модель приводит к разделению атомарной операции на части, то ты неверно провел границы модулей или неправильно понимаешь границу атомарности операции.
https://www.reddit.com/r/dotnet/comments/1cmenho/is_mlnet_relevant/
Короче, надо наверное змею учить и интегрировать сервисы на дотнете и змее.
ну можно и так
https://github.com/dotnet/TorchSharp
хотя это слизерин
Вьюмодели придумали пидарасы из микрософта, когда надо было впарить новую вижуал студию. Получилось хуево, как обычно у мелкомягких, и теперь джуны путаются снова и снова.
Есть классическая схема работы десктопных приложений: UI, контроллер, сервис. Контроллер получает данные от UI и передает в сервис. Или получает данные из сервиса и передает в UI. Есть шина событий, на которую подписан контроллер. Данные поменялись, контроллер получил уведомление, запросил данные у сервиса, сказал UI, что надо перерисовать тектбокс. Все просто, не надо никаких медиаторов-хуяторов.
Ты наркоман. VeiwModel нужна для дестктопа. Тебе нужно где-то хранить состояние UI.
Нет, ты. Как, по-твоему, работают программы на других фреймворках или вообще без фреймворков? Рак под названием MVVM есть только в дотнете, и даже там существует код на винформсах.
> То, на что ты тратишь по абзацу текста обычно называют сокращением, чтобы не ебать мозги окружающим. Пойди, почитай про MVC, MVP, MVU, MVVM, и прочее
Vue и Angular так-то под MVVM...
Просто там как я уже говорил - стейт обычно не множется. Есть какой-нибудь Vuex, Pina, NgRx и т.д.
Ты загрузил с сервера куда тебе надо состояние. Все. Пока не перезагрузишь - оно такое и будет. Все компоненты - какими-нибудь геттерами подвязались к этому стейту и радуются.
Если нужно чтобы сервер как-то сообщал: вебсокеты и теми же механизмами в тот же самый стейт.
А вот в десктопе какая-то фигня получается(
>сказал UI, что надо перерисовать тектбокс.
во-первых, чистый MVC неудобен для десктопа
его вариант типа MVP был возможен для формсов ибо там не было (а может и щас нет) вменяемых биндингов
MVVM используется там где есть БИНДИНГИ
и это не только дотнет. в андроид тоже MVVM и БИНДИНГИ
>А вот в десктопе какая-то фигня получается(
в десктопе дается общий механизм MVVM
и без наличия других правил каждый терзается по своему
вот обычные MVVM фреймворки похожи, есть сложные типа PRISM
но они больше решают вопросы навигации, разделения на блоки, но как то обходят вопросы "а как лучше поделить на вьюмодели, что в них хранить, а куда команды то..."
Некоторые изобретают MVVMC фреймворки (и носятся с этой диаграммой на пике)...каждый по своему понимая что тут есть контроллер.
У меня вот MVVMP подход
слишком много свободы и, как обычно, подводные камни обходятся молчанием.
У тебя подход насрать в одну кучу. Вью и контроллер - это один слой. Бизнес-логика - это следующий слой. Контроллеру не надо знать про recognition engine, его задача - в нужный момент вызвать IRecognitionService.PerformRecognition(string filePath), получить List<RecognitionResultDTO> и дальше скормить этот лист во вью.
основной жалобщик в этом треде не я. Я сам написал кучу WPF фреймворков так что у меня свой франкенштейн с контроллерами и лайфтаймами, и прочими причудами что не канон
но высказаться я могу....
это как раз у MVVM подход "насрать все в кучу" (он и стейт вида обрабатывает и команды в нем же), что и делает его GodObject. Попытки разгрузить вьюмодели и приводит некоторых ко всяким контроллерам (тут уже каждый по своему понимает что он должен делать.)
А этот пик просто бродит по инету и я хз чего это они какой то там Engine отделили от модели.
>Контроллеру не надо знать про recognition engine, его задача - в нужный момент вызвать IRecognitionService.PerformRecognition(string filePath)
ты же сам понимаешь что этот твой коммент лишен смысла? но это ладно. какая разница то.
>recognition engine,
Почему так дохуя всего на схеме? На каком уровне медиатр подключен? Это DDD?
Возникает вопрос. Они там чего, блядь, ебанулись все? Почему буквально каждая следующая "тестовая пирамида" отличается от предыдущей?
Особенно доставляет, что есть даже одна перевёрнутая с ног на голову.
Потому что гуманитарии пытаются косить под инженеров и примазаться к айтишной тусовке ради бабла, но свою суть им никогда не изменить.
Приложение просто 1 раз запустить без гуя, и что бы оно работало в фоне.
Почему Visual Studio временами перестает компилировать код, я ебу мозга, но при банальном перезаходе или перезагрузке он компилируется?
Иногда не компилируется даже после перезагрузки, но банальное создание нового проекта и перепечатка всех прежних внешних файлов без изменений снова делает компиляцию корректной?
Это уже рождает параною. Я не понимаю, не компилируется из-за ошибки какой конкретной, или это неведомой хуйни ебовеной и поможет перезапуск.
Да хуй знает.
На редите читал что проблема давняя.
Может ебануть ошибок кучу, а при пересборке ошибки пропадут.
У меня иногда теряет точку входа Main, а при перезапуске находит её и все норм.
Ну такова что бы при пересборке или после перезапуска что то с нихуя не компилировалась такова небыло.
Я одно поле из private в public перевел для одного теста, эта залупа минуту одупляла до этого, чтобы без ошибок скомпилировать. Тупая манда блядь.
Какая версия студии у тебя?
Алсо поотключай в настройках все лишние анализаторы и фоновые активности.
Просто обёртки возьми. То, что раньше называлось xamarin native
Я не пишу на сипипи. Но на сипипи же хуева гора сборочных систем, мейк всякий, и так далее. Выкидывай нахуй всё нестандартное и пересоздай проект из шаблона в студии, а туда свой код перенёси.
Непонятная хуета пропадёт и либо оно начнёт нормально собираться, либо ты всё нахуй сломаешь.
Либо по началу как бы соберётся, но это пиздёжь и самом деле ты упустишь какую-то мелкую деталь и у тебя будет стрелять исключение где-нибудь в ночь на крещение в 2027 году.
Ты никогда не узнаешь если не попробуешь.
>Но на сипипи же хуева гора сборочных систем, мейк всякий, и так далее.
Вот, кстати, одна из причин, почему я и забил в свою время на плюсы. Любой, сука, проект будет совершенно по разному собираться. И к каждому нужно еще кучу всяких тулзов и прочей хуйни найти и понаставить, чтобы это просто собралось, не говоря уже про запустилось.
Ну что сказать, у нас кросс-платформенный csproj, в котором пара настроек и dotnet build
> Кстати почему медитр говно
А есть какая-то проблема, которую он решает? Мне так никто и не объяснил, нахуя он нужен.
потому что его писали с упором на выразительность и создания DSL
поэтому всякий шум типа ; new ()=> и прочего там просто нет.
и есть штуки типа настоящие инлайн функции, функции без классов, скоупы, а также делегирование (когда в шарпе в очередной раз пишу руками класс враппер, то особо об этом вспоминаю не очень добрым, но весьма матерным словом)
>функции без классов
Зумеры изобрели процедурную парадигму. В С вообще все так написано, классов нет только куча ебаных функций.
>Зумеры изобрели процедурную парадигму.
не изобрели, а не стали говорить "нинужна" понимания что штука весьма весьма пользительная.
Там и структуры заново изобрели. Называют их дата-классами.
А кто-то говорил что не нужно? Статические классы в любом ООП языке это процедурный стиль.
Вообще я почти уверен что мне даже еба сениоры с трудом ответят на простой вопрос "процедура и функция это одно и тоже?"
> процедура и функция это одно и тоже?
Попробую ответить, хоть и не еба сениор
Функция - всегда возвращает результат и в большинстве случаев должна не иметь сайд-эффектов.
Процедура - имеет сайд эффекты и может не возвращать результат.
Помнится в паскале для них даже отдельные ключевые слова были.
>потому что его писали с упором на выразительность и создания DSL
Спасибо! Теперь понятно, почему котлин такой выразительный.
не изобрели, а взяли концепцию кортежа. Ты не изобрел колесо, хули ездишь на транспорте.
>>3368701
>А кто-то говорил что не нужно?
не могу в шарпе создать функцию без необходимости запихать ее в какой либо класс. минимал апи то вообще не то.
>>3368731
вот. все именно так и произошло. шарп тупо копировали "сделаем свою жаву" и потому в основе это калька с жавы и только потом уже стали сахар накидывать, а в котлин сразу закладывалось DSL
Не заметил, спасибо. Но всё равно выглядит как хуйня из жопы
>только
Короче, можешь ещё раз повторить, что такое ВЫРАЗИТЕЛЬНОСТЬ?
Я нихуя не понял, для меня это как пиздануть что-то гуманитарное наподобие "Котлин лучше c# потому что он более РЕФЛЕКСИВНЫЙ и ИМАДЖИНИРУЮЩИЙ".
>Короче, можешь ещё раз повторить, что такое ВЫРАЗИТЕЛЬНОСТЬ?
Весь прошлый тред это обсуждали и все уперлось в то, что это просто когда сахарок в одном языке якобы лучше чем сахарок в другом. Причем критерий "лучшести" - это либо следствие синдрома утенка, либо просто представления о прекрасном конкретного кнопкодава.
>когда сахарок в одном языке якобы лучше чем сахарок в другом
не якобы, а лучше.
ты не пишешь на жаве, а на шарпе потому что шарп сильно слаще жавы. или это якобы?
>просто представления о прекрасном конкретного кнопкодава.
гм. а чего это шарп такой перетащил primary constructors, backing field, если это же просто чужой сахар который ЯКОБЫ лучше?
загадка природы.
> не якобы, а лучше.
Что лучше?
> ты не пишешь на жаве, а на шарпе потому что шарп сильно слаще жавы. или это якобы?
я не пишу на сишарпе, я пишу на дотнете. Нахуй мне всрался ваш синтаксический сахарок, который неебически выразительный если надо ебаться с градлом, который сам сломался - сам починился на следующий день?
Мб в RabbitMQ надо создать очередь?
Хз, никогда через обёртки типо масс-транзита не работал. Всегда вручную
>получилось
и иди нахуй со своим ебучим масс транзитом пиши DDD поеботу, не забудь в медиатр затолкать
>и иди нахуй со своим ебучим масс транзитом пиши DDD поеботу, не забудь в медиатр затолкать
Ну бля че в гугле первое выдало то и изучаю)
>Что лучше?
сахар ))
вон даже шарп к себе некоторое тащит. Правда кривовато по сравнению с оригиналом, но тащит.
>если надо ебаться с градлом
принимается. сам в шоке как там все непонятно (если не читать мануалов, а я конечно их не читал ни одного по градлу), но....котлин то тут причем. можешь не юзать градл.
Ну не знать чем енам лучше чем поля статического класса это уже клиника. Стажер лвл.
то есть ты хочешь сказать что имеется енам И статический класс потому что делал стажер, который не понимал разницы? или что ты хотел сказать?
Валидация DTO входной или entity?
а как ты собираешься из DTO собирать entity если в dto половины нужных данных может просто не быть?
Круче. Уже собирается и проверяется именно entity. DDD епта, нам важно следить за доменом.
>Коллеги, вы как считаете что правильно.
Как написано в ТЗ и заложено в архитектуре.
Энтити, очевидно. Как вообще валидировать DTO? Тащить бизнес-логику в контроллеры, которые должны быть тонкими? Или передавать DTO в сервисы, которые не должны зависеть от транспорта? Оба варианта выглядят так себе.
Буквально ни чем?
Уж точно не шарповские.
Енамы нужны хорошие. Не эта хрень из времен сей;
В духе:
public enum Color
{
puiblic readonly byte R;
puiblic readonly byte G;
puiblic readonly byte B;
Color(byte r, byte g, byte b){
R = r;
G = g;
B = b;
}
RED(255, 0, 0);
GREEN(0, 255, 0);
BLUE(0, 0, 255);
}
И чтобы с коробки нормально можно было для них форичи делать. Чтобы можно было запечатать его и нельзя было привести что-то к нему просто так.
Те енумы что в шарпе есть - это говно из жопы и в принципе от статического класса не отличается ничем.
>Энтити, очевидно.
то есть сущности могут быть в невалидном состоянии? ну ок ок )))
Это точно DDD?
>сахар ))
Чем что лучше? У меня вот в сишарпе 4-5 сахаров над интерполяцией строк:
@$"""{a}"""
$@"{{a}}"
"""This is a "raw string literal". It can contain characters like \, ' and "."""
$"|{"Left",-7}|{"Right",7}|"
2 синтаксиса для инициализации словарей
Dictionary<string, int> d = new () { {"", 1}};
Dictionary<string, int> d2 = new Dictionary<string, int> { [""]= 1};
2-3 сахара над инициализацией коллекций
3-4 сахара над паттерн-манчкином
заебёшься считать, сколько сахаров над свойствами
я ебал эти ваши сахары новые. Я иногда даже думаю свалить на менее ВЫРАЗИТЕЛЬНЫЙ GO, там вроде нихуя нет. но если я свалю на ГО, то в нём решат добавить ВЫРАЗИТЕЛЬНОСТИ, ООП и опять всё по новой.
>в принципе от статического класса не отличается ничем.
отличаются все же, просто поборник энама не может ответить "а нах.... тогда статический класс еще вообще существует"
> Те енумы что в шарпе есть - это говно из жопы и в принципе от статического класса не отличается ничем.
энумы это буквально числа. Если тебе нужны объекты - просто пользуйся объектами
Ну да, это правильно. Пока не вызвал валидацию, сущность не валидна.
ну это ты сахарную пудру какую то притащил
этим как раз шарп страдает.
в котлине такой херни нет
просто там ИСКАРОПКИ много чего что в шарпе "каждый делает как хочет и ЕСЛИ МОЖЕТ"
Котлин позволяет создать jetpack compose (который просто шикарен в плане своей выразительности описания ui и при этом полноценный код, а не хамлы всякие), на шарпе же будет уродство, потому что нет ни инлайн методов, ни скоупов, ни делегации, ни даже extension property, ни расширения статического класса, ни аналога object, ни автореализации интерфейсов
Зато есть куча синтаксического мусора в виде new, ;, ()=>, принадлежности к классам
То есть шарп не способен в принципе создать такое.
>Как вообще валидировать DTO?
Атрибуты например навесить. Типа [Required], [Compare], [Range], etc или вообще свои создать. Тогда оно будет отсеиватся еще до попадания в контроллер и он у тебя таким же тонким и останется.
А бывает вообще валидация на стороне клиента еще до отправки запроса.
хреновая это сущность если ее можно ввести в невалидное состояние.
небось из бд эти сущности иногда читаете частично, да?
>public enum Color
>{
>
>puiblic readonly byte R;
>puiblic readonly byte G;
>puiblic readonly byte B;
>
>Color(byte r, byte g, byte b){
>R = r;
>G = g;
>B = b;
>}
>}
>в котлине такой херни нет
хуя у тебя синдром утёнка. котлин это буквально квинтэссенция сахара
А есть атрибут, который проверяет, что поле с id по внешнему ключу есть в БД и что статус соответствующей записи разрешает на неё ссылаться?
>Котлин позволяет
Да поебись ты уже со своим котлином и успокойся.
Если у тебя на него такой стояк, то что-ты в .net треде делаешь?
на шарпе я пишу с его рождения. нужно пояснять, что это задолго до котлина?
>котлин это буквально квинтэссенция сахара
верно. сахар есть сахар - с ним просто ПРОЩЕ жить
но не по 10 вариантов одного сахара в разном виде.
ты же на это жалуешься
Потому что одно дело иметь доп синтаксис инициализации массива/словаря
и совсем другое дело иметь фичу уровня делегации свойств.
конечно и в шарпе есть такое - тот же Linq он как раз про выразительность. И Expression.
Такого в котлине нет и с этим плохо по понятным причинам.
>>3369387
>то что-ты в .net треде делаешь?
я шарпист. мой основной хлеб это шарп. на котлине я пишу только под андроид, когда натрахавшись с замарином просто выучил другой язык. И оценил его выразительную мощь
А шарп я заслуженно!!! критикую. Шарп хорош, но в нем хватает говна.
DTO - это anemic OOP. Используется в современных клаудах.
Entity - это rich OOP, используется в некро копро легаси для десктопа.
Если тебе делать нехуй, то можно и такой собрать.
Поинт был в том, что валидация может хоть какой быть. На уровне ДТО, или сущности. Может вообще на стороне клиента пройти. А может и где-нибудь посередине бизнес-процесса, когда сущность обогатится.
В большинестве проектов она размазанная по всем этим способам, а утверждать, что только твой вариант верный - долбоебизм.
Открою тебе страшную тайну. Крч умные люди встраивают валидацию на уровне мидлвари ещё до попадания кода в контроллер.
Логика валидации при этом находится в АПИ слое. Нужные зависимости прокинуты через DI. Реализации лежат на слое приложения. Но это очень кривая система если тебе надо дохуя контекста для валидации.
>но не по 10 вариантов одного сахара в разном виде.
Ну хуй знает. Если например с той же интерполяцией, то я предпочту кучу вариантов шарпа, чем например её огрызки в джаве.
>>3369388
>конечно и в шарпе есть такое - тот же Linq он как раз про выразительность. И Expression.
>Такого в котлине нет и с этим плохо по понятным причинам.
Ну так о том и разговор. Опять приходим к тому же: "Выразительность" языка - это просто когда кто-то предпочитает один сахар другому. При том, что когда в типа "невыразительном" языке есть сахар лучше, он почему-то все равно не становится "выразительным"
DDD - ЭТО ДОЛБОЕБИЗМ
>DTO - это anemic OOP. Используется в современных клаудах.
>Entity - это rich OOP, используется в некро копро легаси для десктопа
Хуя себе умник! Давай ка подробнее, чего ты там вычитал в своих статьях на медиуме?
>смотри там, не обдрочись
почему это. в шарпе мне такое не предлагают. там предлагают сраный хамл.
поэтому дрочил, дрочу и буду дрочить на шикарные вещи.
А вот на хамл не буду. Дрочить на говно как то....ну может кому и норм, а мне нет.
>>3369409
>Выразительность" языка - это просто когда кто-то предпочитает один сахар другому.
выразительность это способность реализовать функционал кратно и читабельно, то есть выразительно
Знаешь про Fluent синтаксис. Вот это как раз из этой оперы про выразительность.
А теперь посмотри на инциализацию ktor и сравни где приятнее
но это ты можешь сказать "На вкус и цвет есть два стула..."
но это означает что ты любишь есть хоть говно.
про primary constructor и backing field наглядные примеры
если ты не будешь ими пользоваться, ну значит ты неприхотлив, но вот если будешь....
Мне в приложении нужен список ролей. Он заранее известен и понятен.
Но что я должен делать с охуенными енамами что есть сейчас?
Я делаю енам, который просто циферка, потом я делаю таки класс Role, и начинаю пляски с бубном чтобы не давать никому создавать что-то неправильное.
А далее появляются еще разрешения, которые тоже заранее известны в рамках обозначенных ролей. И опять. Я делаю енам. А потом делаю класс такой же.
Короче. Жопа происходит.
А объекты. Я не могу просто так взять и, например, перебрать их. Не могу удобно сравнить их. Не могу в свич засунуть
switch(role)
case ADMIN: // todo handle admin
Сверху. Какая-то доменная логика - УДОБНО чтобы она была в этом енаме. Но что я должен делать? Я должен писать экстеншн метод. НАХУЯ? Почему из коробки нельзя просто:
if(role.HasAccess(some))
?
Типа. Ну серьезно. Ну серьезно....
Я все сказал. Меня вы не переубедите. Текущие енамы - говно. Нужны более мощные.
Единственно правильная валидация - доменная валидация в бехевиоре MediatR.
На серьёзных проектах как правило заменяют устаревший DI контейнер на MediatR+FluentValidation полностью - это позволит тебе написать один общий валидатор на все валидируемые объекты: хендлеры команд, события, сущности, агрегаты, репозитории. Таким образом, в DDD всё - это валидируемый объект.
Таким образом, пишешь валидатор один раз, а валидируются все объекты, попадающие в CQRS пайплайн.
>Знаешь про Fluent синтаксис. Вот это как раз из этой оперы про выразительность.
Рот я ебал того мудака, который придумал через точечку писать и назвал это гордым именем ФЛУЕНТ. Я думал, мода на это говно прошла в 2018 году.
Там же не отладишь нихуя
> Я делаю енам, который просто циферка, потом я делаю таки класс Role, и начинаю пляски с бубном чтобы не давать никому создавать что-то неправильное.
> А далее появляются еще разрешения, которые тоже заранее известны в рамках обозначенных ролей. И опять. Я делаю енам. А потом делаю класс такой же.
Нахуя ты систему ролей сам пишешь? возьми станартную
> А объекты. Я не могу просто так взять и, например, перебрать их. Не могу удобно сравнить их. Не могу в свич засунуть
> Я все сказал. Меня вы не переубедите.
А тебя никто и не пытался переубедить, иди на хуй от сюда
>> MediatR
> Сразу мимо. Это говно надо огнём выжигать.
Есть еще вариант писать валидаторы через Automapper.
Маппишь условно либо на сущность, либо на ошибку в зависимости от логики. Валидаторы описываешь в декларативной форме прямо в конфигурации
Ну во первых, я могу понять когда ты пермишены прибиваешь к коду, но роли то нахуя в енамы пихать? Роли это буквально набор пермишенов и весь их прикол, что они динамические и могут создаваться и менятся на лету.
А во вторых, ты по сути хочешь от простого перечисления полного функционала класса. Ну так и пользуйся классами.
>А объекты. Я не могу просто так взять и, например, перебрать их. Не могу удобно сравнить их. Не могу в свич засунуть
А ты не торопись, подумай и поймешь, что можно.
>Единственно правильная валидация - доменная валидация в бехевиоре MediatR.
Сразу нахуй. За обычное использование MediatR-а (реквестов и хендлеров) в нормальных местах тебя сходу обоссут, а за использование его behaviour-ов так и по кругу опустят. Они очень легко превращают код в маленький филиал ада, с регистрацией 100-ни бехейвиоров в Startup.cs с припиской капсом "НЕ МЕНЯТЬ ПОРЯДОК РЕГИСТРАЦИИ". Потом это дерьмо хрен отладишь, особенно если до тебя ещё успел поработать сверхразум, любивший дергать медиатор из его же хендлеров и бехейвиоров (в том числе из правил FluentValidator'а, который в одном из них вызывался).
Кстати стандартные штуки fluentvalidation не работают с минимал апи и тд.
Есть какой-то интересный способ встроить его в мидлвари запросов самому и чтобы кайф ловить?
>Потом это дерьмо хрен отладишь, особенно если до тебя ещё успел поработать сверхразум, любивший дергать медиатор из его же хендлеров и бехейвиоров (в том числе из правил FluentValidator'а, который в одном из них вызывался).
Всегда так делаем. В любом нормальном DDD репозитории без бехевиоров невозможно. Как ты иначе будешь делать асинхронные запросы без доказательства последовательного исполнения? Чел, ты вообще про СQRS хоть читал? А про аоп?
Любая доменная валидация должна сама понимать, что ей пора отработать, и не важно, из какого пайплайна её триггернули, из раббита или из ЮД
Жирно.
>>3369483
Либо ты жирнишь, либо непрофпригоден. Если второе, то напиши название шараги, где работаешь. Буду ее стороной обходить, когда в следующий раз работу искать буду.
1. Таки я просто как пример привел. Когда нам нужно перечисление, но это перечеисление должно не только ограничиваться циферкой какой-то.
2. Приложения разные бывают. Вот допустим многим нужно чтобы был просто админ и неадмин. Адимн - все может. Неадмин - базовый функционал. Ну или типа демоюзер-полноценный, аналогично. Если про десктоп-то говорим. Мне не нужна особо охуенная система ролей.
3. Ну как я так просто запихну в свич класс-то?
Да. Сейчас я могу наследоваться, и паттернамтчингом хуйнуть. Но тогда - у меня либо самому следить за тем чтобы объект этого типа был только один в приложении, либо хуярить ненужные объектики. Опять же - чтобы теперь просто сравнить роль - я должен буду переопределять метод для сравнения.
Если бы енамы которые я хочу были частью языка - можно было бы создать по экземпляру и радоваться...
А так - ну да. Костылями и всякими исхищрениями можно.
Но это не отменяет того что базовый енам который сейчас, это все равно что обычный enum а не enum class в плюсах.
У тебя не должно быть никакой доменой валидации. Мы валидируем входную ДТО, че там дальше это проблемы бизнес логики.
Ты допросишься однажды, тебе сделают
struct record enum
И ебись с ним
В ДДД это так делается. Общая сквозная доменная валидация на всех нужных уровнях пайплайна.
А валидаторы сами решают, что им валидировать, а что нет. Это очень просто
Только так, иначе как ты будешь валидировать вызовы медиатра из репозиториев?
Тоже познал эту же боль с медиатором. Только у нас ещё хуже было. У нас все внешние вызовы в вызовы медиатора оборачивались.
Т.е. если тебе нужно было сходить в какой-то сервис, то ты подтягивал себе его proto-файл (у нас GRPC) был. Для каждой нужной тебе ручки из протника добавлял новые Request, Response и доп. модельки, если они в протнике есть. Потом добавлял конфиг автомаппера для маппинга всего этого и отдельный хендлер, который маппил Request на модельку GRPC-запроса, дёргал GRPC-ручку, а потом маппил результат на Response и возвращал его. Ну и вместе использования ты просто отправлял модельку запроса в MediatR.
Также была реализована работа с кафкой и S3.
В какой-то момент всех достало руками добавлять реквесты, конфиги автомаппера и хендлеры. Тогда запилили сорс-генератор, который по одному классу с кучей атрибутов это все генерировал. Но с отладкой стало ещё хуже. Так как теперь, если ты ошибся в конфиге, и указал что-то не то, то сорс-генератор либо падал без внятной ошибки, либо генерировал какую-то дичь, из-за которой все падало уже в рантайме.
Лучше просто дать возможность перегружать оператор is в классе, хотя бы ограниченно, без шаблонов, просто с значение определенного типа в качестве правого аргумента.
Тогда бы можно было реализовывать свои enum-object'ы и нормально с их значениями работать. А то сейчас не хватает возможности их в switch'е использовать.
В GRPC есть Interceptor'ы. Можно запилить валидацию ещё и в них. Как вам?
Чего ты рвешься? DDD можно использовать, пока у вас 10 rpc и один сервер. Или когда ты футстек мартышка из стартапа и твой код никогда не попадет в прод. Выйдешь в большой интернет с такой архитектурой - утонешь нахуй.
Так делают дебилы. В мидлваре валидируют входной джейсон, что юзер айди - это действительно число, а не бизнес требования.
>Логика валидации при этом находится в АПИ слое.
О, вы из епама!
>А так - ну да. Костылями и всякими исхищрениями можно.
По моему как раз то, что ты хочешь получить от енама и есть какой-то дикий костыль, который нужен только тебе одному, просто потому что ты придумал, что тебе именно так удобнее.
Ты хочешь какую-то залупу, которая бы имела свойства класса, её можно было бы пихать в свитч (я х.з. кстати почему ты просто не можешь одно из свойств объекта для этого использовать) плюс еще и своствами синглтона обладала с уникальностью.
А потом что? Еще захочешь какой-нибудь ConcurentEnum, чтобы еще и в многопотоке конфликтов не было?
Хуйней какой-то страдаешь, имхо.
Я просто жавовски enum описал, няша...
Единственный аргумент который мог бы быть в сторону шарповских - это быстродействие. Так ведь нехрена. Если ты чуть больше чем просто список чисел с именами их используешь - шарповский енум в любом другом случае медленный что пиздец, потому что на каждый чих под капотом дохуище рефлексии. Просто сделать ToString - тебе сама студия скажет - чел, если тебе надо, лучше напиши свой метод расширения, а то наш енам будет медленно тута. Хочешь обойти все значения перечисления - та же залупа. Хочешь добиться чтобы нельзя было просто так любую циферку скастовать к enum'у - ну ты эт, много хочешь, проверяй каждый раз через ту же рефлексию что эта циферка не принадлежит перечислению.
Ну серьезно.
Даже в контексте кодов ошибок.
public enum HttpErrorCode {
BAD_REQUEST(400, "Bad Request"),
UNAUTHORIZED(401, "Unauthorized"),
FORBIDDEN(403, "Forbidden"),
NOT_FOUND(404, "Not Found"),
INTERNAL_SERVER_ERROR(500, "Internal Server Error");
public final int code;
public final String message;
HttpErrorCode(int code, String message) {
this.code = code;
this.message = message;
}
}
При этом - я имею возможность в современной жаве - это в switch засунуть и как-то использовать.
Скажи сейчас что это пиздец какой редкий кейс и никому не надо.
Да много где эт надо. Хотя бы базу засеять какими-то хуйнями из домена.
Но да, лучше же до конца стоять на том что не нужно. В шарпе вообще ниче не нужно. До момента пока сами мелкомягкие не впихнут это в язык, потом, конечно, ом-ном-ном, как удобно. Я помню что и рекорды когда я в этом треде описывал их - грили - нахуй надо, пили сам свой иммутабельный класс и каждый раз переопределяй сравнение, чтобы работать с ними как со значениями, а как завезли-то так сразу - ой, а че бы рекорды не использовать для таких случаев.
Сейчас - все конечно можно обойти.
Я при желании могу вот так сделать:
public enum HttpErrorCode {
[HttpErrorCodeMessage("Bad Request")]
BAD_REQUEST = 400,
[HttpErrorCodeMessage("Unauthorized")]
UNAUTHORIZED = 401,
}
public static class EnumExtension{
public string GetMessage(this HttpErrorCode code){
// реализацию через проверку аттрибута
}
}
Но эт же откровенно неудобно. Это откровенно ошибкоопасно. Сверху - эт жутко медленно.
Блин. Может быть таки взяться и наконец написать сорсгенератор для всей этой залупистики. Посмотрю реально ли я шиз или таки люди хотели бы такое иметь в языке.
> Лучше просто дать возможность перегружать оператор is в классе
перегружать синтаксический сахар? Такое возможно только в действительно ВЫРАЗИТЕЛЬНОМ языке программирования
> А то сейчас не хватает возможности их в switch'е использовать.
вот, использую энам в свитче. У тебя не работает так?
Можно экстеншен-метод сделать
public string GetMessage(this HttpErrorCode code){}
и на него тест написать, что GetMessage покрывает все возможные варианты HttpErrorCode. Делов на 10 минут
> сорсгенератор для всей этой залупистики
Бля, я писал аналог даппера через сорсогенератор, это такая поебота, что пиздец. А если в нугет заворачивать - то пиздец, никто не поможет, заебёшься
не путай с LINQ
если ты пишешь конфигурацию в fluent синтаксисе, то тебе отлаживать её и не нужно.
кстати насчет отладки. Это проблема студии же - это она не умеет отлаживать.
могли бы давно у себя реализовать плюшки ozcode, но хрен вам.
после ozcode на стандартный дебаггер без слез не взглянешь.
>вот, использую энам в свитче. У тебя не работает так?
я мимокрок, но имею ту же претензию к шарпу
это ты используешь НЕ энам объекты, а просто енам, которые суть числа.
вот тебе пик пример чего хотелось бы.
это просто пример. Там может быть абсолютно ЛЮБАЯ информация.
Да и тратить время на вычисление в рантайме. Атата.
ну и подумай как ты этот свой тустринг будешь запихивать в match в том же шарпе.
> ДДД с медиатром.
Для полного погружения:
- обязательно подключи автомаппер. Развяжи сущности по слоям
- регистрируй объекты в DI только дженериковым путём. Инжекти только общие классы (IService<T>, IRepository<T>, IMapper и IMediator).
- Сделай базовые обобщённые хендлеры и команды, IEntityCommand<T, TResult>, IEntityDtoCommand<TEntity, TDto>
- Сделай базовые Behavior на логирование, обработку ошибок, валидацию, отправку доменных событий.
Так ДДД противоречит всем мыслимым практикам. Особенно богатые модели.
Смотри у тебя модель отвечает за
1) представление данных из БД. Их хранение, мапинг на БД и тд.
2) за валидацию данных и их изменения
3) за управление событиями
В ДДД документ сперва сам себе меняет подписанта, потом сам себе меняет статус, потом сам себя подписывает, потом сам себе пишет аудит этих действий, потом сам документ порождает событие "документ подписан".
Проблема долбоебов с ДДД в том что мы моделируем БИЗНЕС ПРОЦЕССЫ а не домен. Действия над документом производит актор который знает как правильно эти действия производить, другой актор знает как проверить документ, у события же актора вообще нет это побочный результат выполнения операции подписания.
По такой схеме у тебя должно в коде в конкретном месте лежать логика подписания документа в неком DocumentSignCommand от которой наследуются все специфичные команды разных видов документов где описана спкцифичная для них бизнес логика. Эта команда вызывает некий IValidator и просит проверить документ на соответствие правилам. После завершения работы документ сохраняет в БД через вызов SaveChanges() и с помощью IEventService мы порождаем событие.
Заметил фишку? Теперь весь этот процесс реально выглядит как-будто я описал реальный процесс подписания документов где документ передаётся разным людям и они с ним что-то делают, а не просят документ что-то сделать.
У людей неверное понимание что в ООП выражет метод.
document.Sign() это буквально просьба для документа подписаться. Более правильно тогда уже user.Sign(document).
Про локализацию не забудь, ага. А то потом приходится сраной метлой вычищать сраный декларативный код от сраных гуманитариев.
ты вообще мне отвечал? что тебе мешает взять строку из ресурсов?
Поебень которая занимает 4gb ram в вкладке браузера не считается
100% бэкендеров.
Ведь на самом деле никто не знает, что такое хайлоад.
Дотнет - это не про хайлоад и хайперфоманс, за этим в го. Дотнет - это мартышка фулстек в стартапе пукнул ангуляром в кафку, чики-брики медиатр автомапер орм, мышкой задеплоили в ажур через админку и сидим урчим.
Тут вопрос, что считать хайлодом. Постоянные 100 rps на сервис уже хайлод? А 500? А 5000? Где эта грань?
У меня в команде есть один (микро-)сервис с средним RPS-ом в 2k, который держит 5k при нагрузочных тестах. Хотя может и больше, если больше подов поднять. Можно уже всем на собесах говорить, что хайлодом занимался?
>Можно уже всем на собесах говорить, что хайлодом занимался?
нет конечно. ведь когда все накроется пи....тазиком, то виноватым будешь ты.
а так ты "а я причем".
>нет конечно. ведь когда все накроется пи....тазиком, то виноватым будешь ты. а так ты "а я причем".
ну по крайней мере его возьмут. В следующей компании будет говорить, что решал проблемы связанные с хайлоадом
Я не нашёл достаточного обоснования, почему это значительно лучше чем синхронизироваться на object. Единственное логичное объяснение - это попытка выкинуть из заголовка объекта несколько байт, но такой информации я не нашёл.
Дайте пояснение по этому поводу? Что считает ваша мама?
Иначе со стороны выглядит как будто к бесконечной куче примитивов синхронизации добавился один
Похуй, все равно пользуюсь в основном семафорами. Локов, хорошо если раз в несколько лет касаюсь.
Ну. Вот я на авалонии. Стандартный такой - хуяк, 3 слоя. UI, Инфра, и приложение. Все в отдельных сборках.
Вот у меня на уровне приложения - надо положить объектик в коллекцию, ну, чтобы не мудрствовать - сделали сразу observable, фиг ли нет. Чет в фоне произошло чтобы - хренак - обновилось.
На уровне UI - подписаны на изменение коллекции биндингами и должны обновить UI при изменнии.
ХУЯК, а ОПЕРАЦИЯ-ТО АСИНХРОННАЯ, МОЖЕТ И В ДРУГОМ ПОТОКЕ ЗАВЕРШИТЬСЯ. А ОКНО НЕЛЬЗЯ ОБНОВЛЯТЬ В ДРУГОМ ПОТОКЕ. В результате - хурма, у тебя из-за такой
И типа ну фигли. Ну реально.
Иду с лицом жабы делать статический класс, который из всех уровней будет давать доступ к UI-потоку.
Че еще делать-то остается?
Я реально не хотел. Но с другой стороны - делать чтобы на уровне приложения я просто срал событиями, и потом уже на уровне выше - я буду ловить их и уже в UI запихивать - я не хочу еще больше.
>Че там чистая архитектура говорит по поводу того как правильно UI'ные
Чистая архитектура заканчивается там где бэк упирается в API. Все что происходит за API, всякие фронты, UI-хуи и т.д. с чистой архитектурой не совмещаются. Там даже обычное ООП не применимо.
Внезапно вспомнил про такую хурму как IObservable, лол. Уже отупел с этими вебами.
В общем. Да. Решение что вижу - модель таки IObservable, а не чистое ObservableCollection'ы и прочую муру.
UI - это слушает, свои вещи таки в UI-потоке обновляет.
Нормас короче думаю.
Имитация бурной деятельности, когда очень надо выкатить новую фичу, но все идеи давно закончились. С ними все ясно после охуительного нововведения "индекс с конца массива".
Алсо, в 2025 году все пишут асинки, локи остались где-то в древнем легаси с конкаренси.
А причем тут многопоточка и конкретно управление общим состоянием потоков и асинки?
>статический класс
Не статический класс, а IContext, который является синглтоном и инициализируется после создания главного окна. Передаешь туда Dispatcher из окна. Можно разделить на IContext и IContextInitializer, первый ридонли, второй для чисто инициализации. Физически они мапятся на один и тот же объект.
Дальше через DI прокидываешь контекст во вьюмодели-контроллеры. У контекста есть метод Execute(Action<>), который запускает экшен в UI потоке. В контроллере ты получаешь ивент "юзернейм изменился" и делаешь ctx.Execute(() => this.UserName = newName)
В асинках свой планировщик и своя синхронизация через слимы. Локи - это про классическую конкаренси на уровне ядра.
В общем есть табличка, ячейки таблички могут быть текстовыми, могут быть с галочкой, с выпадающим списком, с кнопкой, ещё какие-то.
А мне надо чтобы в ячейке был прогрессбар. Но через гуи такого выбора нет.
Как решить такую задачу?
В дизайнере форм ты этого не сделаешь, но можешь сделать из кода. Наследуешься от DataGridViewCell, в конструкторе создаёшь экземпляр прогрессбара, переопределяешь метод Paint(), в нём рендеришь прогрессбар в Graphics. Затем создаёшь DataGridViewColumn и ему устанавливаешь CellTemplate.
Пример с мсдн: https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/customize-cells-and-columns-in-the-datagrid-by-extending-behavior?view=netframeworkdesktop-4.8
>Стандартный такой - хуяк, 3 слоя. UI, Инфра, и приложение.
хуйня. Во первых, "стандартных" слоёв нет. Во вторых, производительное UI приложение потребует гораздо больше слоёв на стыке с пользовательским интерфейсом, чем три. "чистая архитектура" все эти моменты игнорирует, но именно там будет основная часть проблем.
>ОКНО НЕЛЬЗЯ ОБНОВЛЯТЬ В ДРУГОМ ПОТОКЕ. В результате - хурма, у тебя из-за такой
Можно работать в 2 потока, поток интерфейса и поток основного приложения. А границу разделения поставить в биндингах MVVM.
Таким образом, если произошло обновление поля ввода на интерфейсе, то во вью-модель оно попадёт через проброс в правильный поток. И наоборот
Но это ебота страшная, уровень вхождения сеньёр-долбоёб-нахуй-я-устроился-в-эту-помойку-работать.
> МОЖЕТ И В ДРУГОМ ПОТОКЕ ЗАВЕРШИТЬСЯ.
На этот случай пишутся диспатчеры потоков, которые определённую фунцию запускают в требуемом потоке.
Просто так и пишешь: ThreadDispatcher.ExecuteInUiThread(x => UpdateCheckbox(x)) . Но опять же, это надо делать по правильному и с первого раза.
> Иду с лицом жабы делать статический класс, который из всех уровней будет давать доступ к UI-потоку.
Примерно так, да. Только не статический, а положи его в DI
Всё вышеизложенное я лицезрел на одном проекте, который работал как в одном потоке, так и в двух. Сейчас с нуля такой писать я бы заебался.
И да, кстати, медиатр говно
>Я не нашёл достаточного обоснования
А достаточного и нет:
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/#threading
>You can absolutely still just use object, and you’ll still need to do so in certain situations, like if you’re using the “condition variable” aspects of Monitor (such as Signal and Wait), and you’ll still want to in others (such as if you’re trying to reduce managed allocation and you have another existing object that can serve double-duty as the monitor). But locking a Lock can be a more efficient answer. It can also help to be self-documenting, making the code cleaner and more maintainable.
Но Lock теперь предпочтительнее использовать, потому что:
>Lock, however, will generally be a tad cheaper (and in the future, as most locking shifts to use the new type, we may be able to make most objects lighter weight by not optimizing for direct locking on arbitrary objects)
>Единственное логичное объяснение - это попытка выкинуть из заголовка объекта несколько байт, но такой информации я не нашёл.
Заголовок используется не только для синхронизации:
https://devblogs.microsoft.com/premier-developer/managed-object-internals-part-2-object-header-layout-and-the-cost-of-locking/
Ещё в поисках обоснований можно почитать issue на 200+ комментов:
https://github.com/dotnet/runtime/issues/34812
> clearer
За слова "чище" надо без раздумий в ебало с ноги бить.
вангую, что вот такая строчка не скомпилируется:
Lock lock = new Lock();
и надо будет писать @lock ?
Вижу, что решением было бы удаление старой конструкции и перевод всего на using. Но, если они бинарную сериализацию выкидывали несколько лет, то с этим не справятся и за... хотя не буду мандеть
Беги срочно сообщи в Кэмридж.
https://dictionary.cambridge.org/ru/%D1%81%D0%BB%D0%BE%D0%B2%D0%B0%D1%80%D1%8C/%D0%B0%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9/clearer
Первый проще и легче, но там where TKey : notnull и надо будет всё облепить аттрибутами и вообще всё ложь и пиздёж.
У меня есть некий while(!_cancellationTokenSource.IsCancellationRequested) который сверху обернут в try catch. В catch попадают ошибки подключения, но я бы хотел чтобы на определенных hResult логика внутри цикла продолжала исполняться (реконектись каждые 10 сек к примеру).
У меня на уме как это реализовать только через goto.
Или есть какая-то нормальная реализация?
А зачем тебе это? Любой словарь в С# и так уже умеет принимать null.
Просто подави исключение и все. Код прерывается после throw. Просто сделай логирование и не кидай ничего.
А, то есть сделать try catch внутри while и один сверху?
У тебя try/catch снаружи блока while, а должен быть внутри. А возможно, и там, и там
Допустим, ты добавляешь новое значение по ключу null.
Будет ли высчитывать словарь хеш код у null?
Если да, что произойдет если вызвать null.gethashcode() ?
@
АВТОМАППЕР
@
FLUENT ASSERTIONS
Наткнулся на метод ГЕТ ПЕНИС
В левом варианте нет - для всех действий будет проверка is null и два варианта; в правом варианте да, у surprise'а будет ссылка на нужный IEqualityComparer<T>.
На пике код максимально кратко, чтобы смысл был понятен - побоялся, что простыню никто не захочет смотреть, а описывать словами... ну такое.
Мне кажется правый вариант лучше - очевиднее и "честнее" для использования, что ли, но сложнее, и будет медленнее и тяжелее.
> В левом варианте нет - для всех действий будет проверка is null и два варианта; в правом варианте да, у surprise'а будет ссылка на нужный IEqualityComparer<T>.
На мой взгляд, ты делаешь странновато. Скорее всего у тебя есть возможность вообще не работать с нулями в словаре.
Рассмотри возможность использовать обычный словарь с помощью Automapper.
Если тебе надо использовать объект как ключ, то ты уже где-то сделал ошибку.
Сделать словарь объект - что то связвнное с объектом
Ваш кэп
>А в чем суть использования объекта как ключа?
Это буквально база ООП в В C#. ВСЁ можно использовать как ключ в словаре и сконвертировать в строку.
Другой базы ООП для вас нет
>в нём рендеришь прогрессбар в Graphics
И вот как это сделать?
Также изучал пример по твоей ссылке. Там к таблице добавляется новый столбец и он модифицируется. А вот как изменить уже существующий столбец я так и не понял. И даже мне надо не весь столбец, а конкретную ячейку.
>>3371542
>WPF
Создал посмотреть тестовый проект. По моему тоже яйцо только в профиль.
>Создал посмотреть тестовый проект. По моему тоже яйцо только в профиль.
верно.
яйцо в анфас на винформсе ты уже видел.
а вот яйцо в профиль это банальное
<DataTemplate><ProgressBar /></DataTemplate>
а в случае если надо редактируемую ячейку то там есть CellEditingTemplate (или как то так, влом гуглить)
ну в общем то да - абсолютно одинаковое
на самом деле небо и земля, даже учитывая что это мерзкий хамл, а писать в винформс стиле можно и на впф, правда это тупо
Нельзя на впф писать в стиле винформ, многие конструкции поддерживаются только в замле
хамл вообще это просто хмл-ое выражения кода. так что любой хамл можно выразить в коде.
Но кэп говорит что впф-онли конструкции как бы по определению не могут быть в формсах
А писать в стиле "пихаем в code-behind обработчики, напрямую работает с контролами и какие такие биндинги" - эт можно
>>3373949
Я ньюфажина и не особо понимаю что вы мне тут пишите. Лучше бы мне конкретное решение подсказали.
using System.Net.NetworkInformation;
var adapters = NetworkInterface.GetAllNetworkInterfaces();
Прикол в том что, если снять галку с TCP/IPv4, сетевуха пропадает из списка, и следовательно МАС уже не посмотреть.
Кто виноват и что делать?
>Лучше бы мне конкретное решение подсказали.
Бери связку MediatR+Automapper, вадидацию делай через FluentValidation. Используй DDD и CQRS
я и подсказал - бери WPF
на нем блекджеки и шлюхи вращающиеся в кнопке которая в прогрессбаре которая в ячейке таблицы, которая сама в шлюхе
делаются куда проще.
в формсах ты либо берешь готовое, либо с помощью такой то матери впихуешь невпихуемое
в WPF изначально lookless, то есть сразу задумано что внешний вид отделен от функционала и может быть заменен.
конечно есть проблемы с фокусом, захватом мыши и прочим, но переопределить внешний вид чего угодно это основной функционал.
плата за это больше нагрузка на систему по сравнению с формс, ведь WPF сам рисует контролы
ну и конечно внешний вид не системный, ведь WPF сам рисует и хреново подстраивается под внешний вид оси
>WPF изначально lookless
Как раз наоборот, луковая архитектура скорее вредит WPF. Предпочтительно брать паттерн "чистая архитектура" через CQRS. Таким образом, в WPF приложении всё это либо команда, либо доменное событие. Идеально брать медиатр в качестве реализации команд, а интерфейс обновлять по событиям, вбрасываемым из медиатра же.
Всё остальное реализуется через "поведения" медиатра. Захотел валидацию - делаешь делаешь общее валидирующее поведение. Работаешь с коллекциями - добавляешь пайплайн, который разделяет все запросы на асинхронные вызовы того же медиатра.
Это называется паттерт MWPF
тебя в детстве лук заставляли есть каждый день?
у тебя триггер на слово лук без учета значения этого слова)
у тебя WTF от медиатра
это распространенное психическое заболевание
в будущем его будут в учебниках по психиатрии описывать.
>у тебя WTF от медиатра
Нахуй ты это говно сюда опять притащил?
Ну а таких опишут в той книге по психиатрии, но в другом разделе
>Ну а таких опишут в той книге по психиатрии, но в другом разделе
Ты ебанутый? Зачем о мощных DDD-CQRS фреймворках писать в психиатрии?
>>медиатр
>>фреймворк
лучшее, что есть на сегодня для организации WPF+MVVM.
Конечно! Целых три языка знаем:
1. Ubiquitous Language.
2. XAML: <DataTemplate><ProgressBar /></DataTemplate>
3. Английский: Assert.That(collection, It.That.Is().Should(have => have.At(x => x.Least).Single().Equal[item]))
Хочу в мышинное обучение и датасатанизм, но там везде Змея.
Изучаю синтаксис змеи и мне хочется плакать.
На Реддите советуют совмещать Змею и ML.Net
Чтобы сделать крутое резюме в мышинном обучении и не потерять свой шарпейский опыт, хочу стать в свободное время контрибутором в репозитории ML.Net и SharpTorch.
Какие подводные у такого плана?
>Изучаю синтаксис змеи и мне хочется плакать.
какой ты неженка. вполне нормальный синтаксис. Лаконичнее шарпа между прочим.
Синтаксис может и нормальный, а вот идея сделать отступы частью синтаксиса - полное говно. Я даже не знаю какие еще проебы в дизайне ЯП можно было бы поставить на один уровень с этим.
>а вот идея сделать отступы частью синтаксиса - полное говно
наоборот это киллерфича. код в едином стиле, а не каждый извращается как хочет.
НО.
Как сделать в авалонии респонсив верстку?
Типа просто в бравзере - эт делается буквально на изичах, даже без всяких там сторонних хреновин, медиаквери и погнали.
А вот в авалонии - ну, чет нормального адекватного решения - не нашел.
Типа можно конечно забиндиться на размер и при изменении размера окна - стиль нужный проставлять. Но опять - эт не выглядит как нормальное решение.
Неистово двачую. Пока пишешь один и по гайдлайнам - кажется ну, проблема преувеличина.
А потом прикриплейд у чела. И на все недовольства - МНЕ ТАК УДОБНЕЕ.
Еще и твой код будет в такую хуйню форматировать, потому что МНЕ ТАК УДОБНЕЕ.
Ну увольте его и все. Или пусть установит себе на решарпер набор ваших правил кодостайла или нахуй идёт.
Еще киллер фичу могу вам рассказать. Берете пишете хуки на автоформат и стайлчек, заодно ещё туда прогон тестов можно добавить (ведь абсолютно любой коммит должен быть полностью рабочей системой)
классная фича
особенно помогает когда просто чужой код на гитхабе (или просто чужой) смотришь.
или ой - не помогает.
Так ты общался с челом или нет? Если это его личный проект для удовольствия может там хоть не русском писать, хоть на фарси в одну строку.
У тебя то можно что-то говорить, то это уже стал код рандом чела из гитхаба. Определись в своих маневрах блять.
>Ну увольте его и все
Да. Ведь все кто недовольны кодом коллег имеют возможность взять и уволить всех неугодных.
> Берете пишете хуки на автоформат и стайлчек
И чел берет и хук выпиливает, потому что ему МЕШАЕТ. Возвращаешь - идет к руководству и говорит что ты саботируешь процесс разработки, он-то фичу сделал, и вообще, помните, 20 лет назад я героически спас прошлый проект в ситуации когда остальные поувольнялись, а тут какие-то щеглы фи-фи делают на мой волшебный и во всем хороший код.
Ну срсли.
> стайлчек
Давай стайлкоп откапывать и ронять сборку в самый неподходящий момент.
> хуки
хуки - всегда плохая идея. Особенно если использовать какой-нибудь Husky, который работает секунд 20, и ломается раз в 2 недели
Когда в товарищах согласья нет, На лад их дело не пойдёт, И выйдет из него не дело, только мука
>И чел берет и хук выпиливает, потому что ему МЕШАЕТ. Возвращаешь - идет к руководству и говорит что ты саботируешь процесс разработки,
Поздравляю, у вас 2 проблемы на проекте, МУДАК и НЫТИК
>Давай стайлкоп откапывать и ронять сборку в самый неподходящий момент.
Стайлкоп это анализатор, он на этапе компиляции/сборки работает. Если ты заливаешь код ни разу не проверив собирается ли он вообще - ну земля тебе пухом. А если у вас есть возможность создать и слить ПР от несобраной фича-ветки в dev/master/release - ну тогда земля пухом всей вашей конторе.
>И чел берет и хук выпиливает, потому что ему МЕШАЕТ. Возвращаешь - идет к руководству
Ну так тут дело не в языке и возможности его код по разному форматировать, а в мудаке и его тараканах. Ты же понимаешь, что он и в пайтоне сможет сделать по своему, например штук по 15 пробелов на отступы и говорить, что ему так удобнее или еще, что придумает.
это значит у меня что твой код и выключение ip4 не ломает его, а значит виноват ты и страдай
>что ему так удобнее или еще, что придумает.
Шизик скорее всего. Они как правило не решают задачи на проекте, а борются с форматированием или ещё какой хуетой
Если вообще встаёт вопрос форматирования, - то скорее всего шизик на месте. Он блюдит за тобой
Ну у нормальных людей просто есть согласие по стилю кода выраженное в файле настроек. Поставил файлик и все.
Делать блин нечего
Питон везде - в огромных проектах и в миллионах разных скриптов которые правишь в блокноте
Какой в жопу файлик
> тиобе
Бейсик люди тоже обожают? Что-то про него ни одного слова доброго не слышно, а он как-то на 6 место вылез в этом недорейтинге.
>Бейсик люди тоже обожают?
конечно. вполне заслужено вылез.
Я белый человек с IDE и решарпером которые следят за код стайлом, именами разной хуйни, спелчекер на 2 языках и даже сонар подключен чтобы сразу показывать проблемы.
Тоже самое для фронта в VS code вагон плагинов и прочей залупы.
Ваши холопские дауничи с нотпадом нахуй пусть идут.
Кто кого ломает? Что ты там себе нафантазировал?
У меня конечная цель снять все эти галки из кода, чтобы винда не срала ненужными мне пакетами в сеть. Как это сделать я пока не знаю.
Если знаешь - скажи, буду признателен.
Сейчас, в качестве временного решения, перед запуском софтины, снимаю эти галки вручную. А без галки айпи4 мак-адрес не посмотреть.
А кто из нас кто?
Я просто типа давно смирился. Просто не пускаю в свой код его, и не лезу в его.
Но погореть в интернете - бог велел. Типа ну реально. Ну реально. Пока просто пишешь себе - забываешь что код другие люди пишут, и они иногда СВОЕОБРАЗНЫ.
дык у бота спроси
зайди в duckduckgo https://duckduckgo.com/?q=DuckDuckGo+AI+Chat&ia=chat&duckai=1
а там тебе и решение на повершеле и на шарпе выдаст
правда через netsh и не знаю работает ли
ему и поясняй проблему про свою ногу
ну ты не мудак потому что совета спрашиваешь, как быть с таким.
Если у твоего зазеканца очень своеобразный стиль, то просто утрируй проблему,
Ебани
[pre]
в
стиле
Маяковского
Залупой
по губам
КОД
[/pre]
У него жопа взорвётся, он страдать начнёт и маму звать
>Типа ну реально. Ну реально.
Смотри у тебя есть несколько вариантов.
1. Оставить все как есть и продолжать в этом вариться. Словить через какое-то время депресняк и выгорание и потом долго от этого восстанавливаться.
2. Просто съебать. Поменять работу и забыть. Минусы понятны, из плюсов - ты охуеешь насколько яркий и нормальный мир за пределами твоего болота.
3. Поиграть в крысиного короля. Стань сам злоебучим мудаком. Представь, что ты отыгрываешь в ролевухе какого-нибудь хаотик-эвил-ассасина. Устраивай ему проебы, подставляй перед начальством, подстраивай сбои на проде по его части, искажай информацию идущую от него другим людям. На любые претензии все отрицать до самого конца - ты не при делах и не ебет. Из минусов - можно попастся. Из плюсов - тонны веселья и здоровая (отиносительно) психика.
Так а хули там, StrongInject брать, который забросили или в автофаке эта ебала встроена, бери и пользуйся.
Но в рот я ебал автофак. Люблю его, конечно, хороший контейнер, но всё-таки ебал я его в рот и на хую вертел.
Через рефлексию охуенно получается, работает очень быстро, самого кода писать - 20 строчек. Но для петуханов эта рефлексия ваша. Души в ней нет
Почему я обязательно должен делать присвоение?
int Z = 10;
AAA(out Z);
private byte AAA( out int X)
{
byte D = 8;
if(5 == 10)
X = 20;
return D;
}
>ОшибкаCS0177До передачи управления из текущего метода параметру, помеченному ключевым словом out, "X" должно быть присвоено значение.
Потому что если if у тебя не обработается, то значение x не поставится. И при вызове методе мы всегда можем запросить out int x.
Почему у меня возникает ошибка при использовании тернарного оператора как на первом пике? Там же логическое выражение до вопросика, всё как положено.
Если создать bool переменную c, то ошибки нет. Чё за какалово?
> знатокам
Первый раз вижу чтобы так использовали ?: Обычно используют как на пике
То, что между точками-с-запятой - это стейтменты (я хз, как по русски), а у тебя выражение.Попробуй, например, напиши
2*3; // то же самое будет.
Конпелятор подумает, что ты забыл выражение присвоить куда-то. Тут так же, тернарная поебота это выражение, оно не самостоятельно
>Вопрос к знатокам.
пиздец, задаёшь вопросы уровня первая неделя изучения языка. У тебя в голове скорее всего вообще ещё пусто если такие странные куски кода пытаешься конпелировать.
Но и для долбоёбов в дотнете есть выход! Не горюй, не задерживайся на дотнете, поищи что-то что тебе подходит по уровню, например, python или js. там быть долбоёбом, спрашивающим, почему у него значок равно не конпелируется - норма, тебя за своего примут
Так и сделал.
>>3377836
>то значение x не поставится
Ну не поставится и не поставится. Проблема то в чём?
>при вызове методе мы всегда можем запросить out int x
Тут тебя не понял.
В твоем случае нужно делать как на пике
Тогда будет работать.
Но делать так не надо. На любом код ревью тебя обоссут за такой код.
>>3378365
Спасибо
>>3378229
>вопросы уровня первая неделя изучения языка
Так оно и есть, пошёл нахуй.
У этого класса есть:
- поле Dictionary<T, int> dictionary
- публичный метод PublicAdd(T t) { ... }, при обращении вызывающий приватный метод PrivateAdd(T t), в свою очередь вызывающий dictionary.TryGetValue(t, out _).
Стоит ли сделать проверку на null и выброс исключения до того, как произойдёт обращение к dictionary.TryGetValue? Или поймать исключение в PrivateAdd / PublicAdd и перевыбросить? Или пусть исключение поднимается из словаря "наружу"?
>Стоит ли сделать проверку
В случае если ты все-таки передашь туда null, то получишь не ошибку, а всего лишь предупреждение и можешь это прощешлкать, если у сборщика не стоит установка падать на ворнингах, ни или вообще где-нибудь в коде директивно отменишь nullable.
Да, лучше в твой первый публичный метод PublicAdd первой строкой всунуть ArgumentNullException.ThrowIfNull(t). В публичных методах лучше всего валидацию аргументов делать как можно раньше. Это правило хорошего тона. Плюс так банально будет проще и быстрее по стектрейсу понять, где и что пошло не так.
Когда пояснение ждать? Я уже нугет запилил
https://www.nuget.org/packages/FactoryGenerator.Microsoft.Extensions.DependencyInjection/
>Стоит ли сделать проверку на null и выброс исключения до того, как произойдёт обращение к dictionary.TryGetValue?
Если ты пишешь публичную библиотеку - да.
Если код локальный - забей хуй. Ты же сам себе доверяешь и не выключаешь nullable
Если код локальный, но ты сам себе не доверяешь - схавай эчпочмак, запей бутылочкой добрый-кола и всё равно забей хуй.
ну ты же видишь что выходные были. потерпи блин.
я пока на первом этапе - пытаюсь понять нафига оно тебе вообще.
Пиши код в той парадигме какую ожидал. Если ты объявил что принимаешь notnull, то это проблема долбоеба снаружи.
>Я уже нугет запилил
Ну и нахуя? Будто без тебя там говна в версиях 0.0.x не хватает.
Не понял.
Dictionary.TryGetValue выбрасывает ArgumentNullException, если передать ему null.
>Если код локальный, но ты сам себе не доверяешь - схавай эчпочмак, запей бутылочкой добрый-кола и всё равно забей хуй.
Так я не научусь нихуя.
Иначе, наверно, тоже, но это хотя бы шанс.
>>3379316
>это проблема долбоеба снаружи.
Я пока что навсегда и есть этот долбоеб снаружи.
>Ну и нахуя? Будто без тебя там говна в версиях 0.0.x не хватает.
Чтобы можно было использовать через нугет в рабочих проектах и чтобы осталось мне принадлежать
>Я пока что навсегда и есть этот долбоеб снаружи
Тогда в чем проблема? Ты же читал про SOLID и чистую архетуктуру? Ну вот так и делай, есть внешний АПИ класса и если кто-то суёт nullable типы в явное объявление notnull, то он тупой или невнимательный.
Я на своих проектах включаю строгую проверку чтобы любые попытки передавать nullable типы где они не ожидаются приводили к ошибке.
>Я пока что навсегда и есть этот долбоеб снаружи.
Тогда нах тебе это не нужно, у тебя в любом случае исключение выпадет очевидное, просто стектрейс будет на две-три строчки короче или длиннее
>использовать через нугет в рабочих проектах
Для этого не обязательно тащить свое говно в общий репозиторий. Нюгеты можно и локально использовать.
Ну или подключать проекты библиотек как сабмодули.
>Для этого не обязательно тащить свое говно в общий репозиторий.
не используй
Очевидно же, что это для повышения ЧСВ, а не потому что есть реальная необходимость.
> Я на своих проектах включаю строгую проверку чтобы любые попытки передавать nullable типы где они не ожидаются приводили к ошибке.
Производительность даже не имаджинирую
>Производительность даже не имаджинирую
Это compile time фича, каким хером она на итоговую производительность будет влиять?
твое заявление можно трактовать двояко
так что все правильно он не имаджинирует
Производительность станет как у питона из-за проверок на nullable.
>Производительность станет как у питона из-за проверок на nullable.
не станет
Да. Выражаться ты будешь довольно часто
А потом... привыкнешь и уйдешь на похапэ
>Производительность станет как у питона из-за проверок на nullable.
Еще раз для долбоебов. Это compile time проверки. В итогом билде их не будет.
Больше всего надо в контексте событий шины. Т.к. откровенно заебался, когда чел берет - меняет на своей стороне сообщения втихую, пока ты в отпуске или что-то еще, а потом такой - я отправил у меня все работает.
Хотелось бы что-то в виде:
_test.Producser(typeof(ServiceA.Program).GetAssembly())
.Produce<ServiceA.SomeEvent>()
.Consumer(typeof(ServiceB.Program).GetAssembly())
.CanConsume<ServiceA.SomeEvent>(onError:"Can't consume")
.HasHandler(onError:"Handler is missing");
Но на самом деле что угодно было бы ок. Потому что откровенно это задолбало.
в kotlin оно вырезается из релизного билда одним правилом
в шарпе их вообще не существует в билде.
Если у вас все контракты в виде классов, которые в json потом сереализируются, то х.з. как это нормально сделать. Только если какой-то свой кастомный анализатор писать, который будет из Гита брать предыдущую и новую версию файлов и проверять, нет ли ломающих изменений в новой.
Мы эту проблему для сообщений в кафке решили с помощью protobuf'а. Все контракты описываются в proto-файлах и во время билда отдельной джобой пушатся в schema registry, из которого с помощью cli-тулзы их можно потом подтянуть в другие сервисы. В этой же джобе сделан анализ proto-файлов на braking changes. Т.е. у тебя просто новая версия сервиса на прод не зальется, если ты контракты поломал.
Скажи что ты просто жирный трололо или просто не понимаешь о чем речь. Я просто не хочу верить что есть такие долбоебы.
OpenFileDialog.InitialDirectory = "?????????????????";
В котлине нет проверок на NULL в рантайме. В c# фича nullable помимо статического анализа добавляет в IL код проверки на null на каждый вызов, но только в релизную сборку
Чуть позже пруф скину
>Чуть позже пруф скину
Вот когда скинешь, тогда и выпишем из пиздоболов.
Жава ведь старый язык, который построен на костылях, например, те же дженерики. Когда у шарпа много классных плюх, которые увеличивают скорость, вроде структур и спанов.
Почему так?
Так че там по перфомонсу?
Автоматом не добавляется там никаких проверок на null. Пока сам в коде их руками прописывать не начнешь, ни в IL, ни в ASM они не появятся.
Вот ещё кейс nullable enable и not null аргумент. По IL и ASM'у отличий от предыдущих нет.
>В котлине нет проверок на NULL в рантайме. В c# фича nullable помимо статического анализа добавляет в IL код проверки на null на каждый вызов, но только в релизную сборку
все с точностью до наоборот.
у тебя котлин и шарп местами перепутаны.
вот что отвечает чатагпыты
Environment.GetFolderPath(Environment.SpecialFolder.MyComputer)
так зачем ты нас вопросами мучаешь. Вкалывают роботы, а не человек - забыл что ли заповедь.
>все с точностью до наоборот.
>у тебя котлин и шарп местами перепутаны.
К сожалению, всё с точностью, да наоборот. Одна из причин, почему котлин называют выразительным - это что проверки на нулл не надо делать, так как компилятор за тебя всё делает.
> Мы все ещё ждём пруфы IL кода с проверками на null.
Сейчас, подожди
>Почему во всех топах, где сравнивают скорость/эффективность языков жаву ставят выше шарпа?
У джавы более современная виртуальная машина, в которой более выразительный
и лучше поддающийся оптимизации байткод.
Байткод джавы компактнее и там, где дотнет использует 2 машиных слова, джава
зачастую использует одно.
В джаве более шустрый сборщик мусора. Их там вообще много, можно менять как перчатки.
Объект у джавы имеет гораздо более короткий "загловок", у ней быстрее работает виртуальный диспач методов.
В джаве более производительные дженерики, в отличие от дотнетовских, которые на упаковке откисают.
В джаве лямбдам не нужна упаковка, они работают статически.
Потому что JAVA имеет более производительную нативную компиляцию.
Зачем мне ждать. Это не я жду несуществующих проверок в IL
Зато у меня есть правило вырезающее проверки в kotlin
Так что мне ждать нечего
Блять что за хуйню ты мелешь. Какие блять правила, какие вырезания.
Тебе мозги кто-то вырезал, возможно твой жид компилятор хуетлина подумал что там null.
еще раз для особо одаренных
в шарпе проверки на нулл, если ты их явно не впишешь, существуют на уровне анализатора и в итоговый IL не попадают
в котлине же null-safety реально вписывается компилятором в каждый метод для проверки в рантайме что то типа
Intrinsics.checkParameterIsNotNull
И это безобразие приходится вырезать либо с помощью параметров -Xno-param-assertion и -Xno-call-assertions либо всякими там прогуардами
учи матчасть, а потом приходи позориться.
>в котлине же null-safety реально вписывается компилятором в каждый метод для проверки в рантайме что то типа
ебанашка, там на уровне Dalvik, в принципе отсутствует значение NULL. То есть, либо ссылка указывает на валидный объект, либо ссылки вообще нет. В дотнете же есть пиздёжь Балмера о том, что "на уровне компиляции", на практике, если ты в IL посмотришь, там каждый вызов засран проверками на нулл
>там на уровне Dalvik, в принципе отсутствует значение NULL.
в душе не кое что делаю про далвик, но это как бы виртуальная машина для жава. И ты мне говоришь что в жаве нет NULL? ну ок ок )
то есть многочисленные issue на тему этих проверок в котлине тебя не смущает. ты предпочитаешь им свои фантазии
ну хоть бы попробовал
А на скрине твоем что? что ими показать то хотел? На что там смотреть? Это тот обещанный IL? может код принесешь? Да мы вместе проверим как ты обосрался
Чел чел чел. Ну ты ведь понимаешь что принес сюда nullable типы и судя по коду ещё и атрибуты. Естественно там возможны проверки на null.
Абсолютно любой ссылочный тип в С# nullable по умолчанию. Новый сахар не меняет язык вообще, а добавляет костылями возможность явно указать ожидается ли null вместо ссылки на объект. Это штука исключительно для этого.
Так где исходники того что ты нам принёс. Уважаемые господа сверху тебе показали как надо.
Как ты кстати можешь объяснить что твои кукареки про null чеки никак не влияют не бенчмарк?
Что читать? Твои фантазии?
Тащи код я скомпилирую, а ты поищешь там нулл чеки
Вот как эта хрень правильно называется?
Это Авалония, на данный момент самый заебись кроссплатформенный фреймворк. Позволяет реактивно в десктоп под Линупсы. В конце прошлого года посмотрел на него и переписал одну из поделок, разделенную на бэк (c#) и фронт (vue) на Авалонии, получилось збс.
Примерно неделю с учетом не работающей без впн большей части документации.
Тогда ему в пердолинг с Дельфи, или как оно там сейчас называется. Помню раньше надо чо с формочкам, открыл, контролы набросал, события заполнил и збз довольно урчишь Паскалем в углу, но это было лет 25 назад...
>Помню раньше надо чо с формочкам, открыл, контролы набросал, события заполнил и збз довольно урчишь Паскалем в углу,
Вот ты мне сейчас воспоминание разблокировал. Буквально мой первый в жизни кодерский коммерческий заказ. Когда по молодости на заводе подрабатывал, начальник цеха ("ну ты же в компьютерах разбираешься...") попросил дочке помочь с дипломом. А там надо было как раз софтину написать демонстрирующую нетороые рассчеты. Я как раз за паскаль шарил еще со школы. По совету другана взял делфи и буквально за пару дней освоил, сделал и получил бабки. Причем первый день это была просто поездка к другану за диском с инсталлятором и объяснением под пиво, что это вообще за зверь такой. С ним же мы потом гонорар и провивали.
Золотые времена были.
Рихтера прочитал.
Придется детей делать чтобы им завещать ждать, а потом внукам
>Рихтера прочитал.
И тебе мало?
Выдохни, чел. Выйди на улицу, траву там потрогай.
У меня еще снег, слякоть. Еще и холодно... Какая, блин, трава?
Я не жду. Тебе отличный скриншот скинули, и если ты хоть неделю разбирался в устройстве дотнет-машины, то давно бы уже до всего сам догадался
Я могу тебе дикпик скинуть
Только что это доказывает?
А нихрена
Для одаренных - твой скрин ничего без когда и компилятора
Потому что любой может за минуту проверить что ничего компилятор не вписывает
И либо ты показываешь особый код, который скомпилится у всех с
Проверками на нулл
Либо ты вагиномяч
А свой скрин незнамо чего можешь засунуть себе... В мяч
Ты блять долбоеб хоть бы почитал че ты кидаешь
https://github.com/dotnet/roslyn/blob/main/docs/features/nullable-metadata.md
Проверка на null блять у него.
>Я могу тебе дикпик скинуть
>Только что это доказывает?
Нахуя? Ты долбоёб, что-ли. Давай скрин с кодом с проверками на нуле или или на хуй
byte [] говно;
byte жопа = (byte)(говно - 0x30);
Почему я должен писать этот пиздец?
(byte)(говно - 0x30);
Как указать константе что она byte?
>Почему
Потому что у тебя все выражения справа от знака равно автоматом к int приводится.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#1247-numeric-promotions
Почему вы байтоебы плюсанутые документацию читать упорно не хотите, а сразу лезете со своими привычками в другой язык. То указатели им подавай, то байты везде пихают.
Поясни, нахуя нужно кодировать числа вот так 0x30 ?
Почему ты просто не напишешь 48? Крутизна не позволяет?
Я не он, но отвечу, что когда работаешь на уровне именно байтов, то 16-ричное представление гораздо удобнее (насколько нужно вообще байтоебить на шарпе, это отдельный вопрос).
Есть не только байтоебные области где, это может быть удобнее, например кодирование цветов намного удобнее и нагляднее в hex, чем в 10-ричной системе.
И что это за херота?
Что это за нагромождение кода? Какое то безумное создание не пойми чего, какие то явные касты и вообще куча говна
Хз вообще что ты доказываешь этим кодом, что скрином с IL и что доказываешь вообще.
Напоминаю забываке утверждение
"не нужно везде проверять на null, потому что компилятор помогает отследить хождение nullable типов, а значит ЗАЧЕМ ЗРЯ ТАКТЫ ПРОЦЕССОРА ТРАТИТЬ на явные проверки (достаточно защититься на границе контекста, но это уже оффтоп)"
И далее идет утверждение (мое, которое противоречит ошибочному чужому) - в шарпе дальше анализаторов ничего не идет, а в котлине эти проверки будут В КАЖДОМ МЕТОДЕ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! вписаны в IL и создаст оверхед (если не озаботиться их вырезанием)
Твой код вообще хз о чем.
Есть простой способ проверки.
пишешь
public void Foo(string text){...}
и подобный код на котлине
fun foo(text: String){...}
И если их скомпилировать, то в шарпе не будет ничего лишнего, а в котлине компилятор добавит проверку text на null через Intristics (что не значит плохо, лично я поклонник fail fast с возможностью вырезать ассерты, но это просто факт)
Как твой ответ коррелирует с тем, что компилятор генерирует проверки на NULL? Это факт и с этим уже ничего не сделаешь
>что компилятор генерирует проверки на NULL
ГДЕ генерирует? ткни пальцем где он генерирует проверку нарушая правила null safety
показать можешь?
даешь мне код, я генерю из него IL
ты показываешь где компилятор делает то, что не должен
и обосновываешь почему не должен.
Да, могу. Смотри выше. И в предыдущем тренде несколько раз обсуждали.
что выше смотреть? показывай что смотреть и поясняй
у меня нет хрустального шара разбираться
и напоминаю - мы говорим про фичу null safety, которая БЫЛА ДОБАВЛЕНА намного позже чем родился компилятор шарпа.
То есть как бы компилятор в принципе не опирается на правила какого то там анализатора вовсе - и не генерит ассерты не потому что анализатор говорит ему "не надо", а просто потому что он НИКОГДА И НЕ ГЕНЕРИЛ их
Шарп по природе своей имеет null и ожидание null, а всякий там null safety прикручен сбоку и компилятором не командует.
И для шарпа все ссылочные типы нуллабельные по определению.
Но все же давай разбираться.
Про котлин ты уже молчишь - там тебе показали Intristics и ты в кусты (хотя конечно может и не ты про котлин заявлял что он ничего лишнего не генерит)
не помню в прошлом треде "несколько раз обсуждали"
тащи, показывай
я не буду за тебя копать.
Чувак, прекращай кормить троля. Явно же видно, что он прикидывается идиотом, жирнит и разводит тебя на длинные пасты.
ну почему же. Вон он целый код родил пытаясь заставить компилятор....вот тут я не понял что.
Технически он прав - шарп не пытается доказывать "там не может быть null" на уровне IL. И он использует callvirt, который внутри себя проверит на нулл чтобы выбросить NRE. Есть конечно NullableContext, но я хз как он влияет на работу callvirt
Вот только так поступает и жава и котлин (который на жава рантайме) - там вызывается invokevirtual который страдает тем же недостатком "ни про какие не-нулл ссылочные типы мы знать не знаем"
Вот если бы это был какой нибудь rust, то другое дело
Это JIT потом может вырезать бесполезные проверки на null если сможет доказать что их там не будет.
А вот с null-safety на уровне кода
- в шарпе она прикручена сбоку и поздно. Безусловно оно может влиять на работу JIT через всякие там NullableContext. Это у нас читальщик рихтера пояснит
- в котлине оно изначально и попутно дописывает ассерты но Intrisctics, про которые jit знает и может их выбрасывать если докажет.
(по факту доказывает он не очень, но не думаю что в шарпе дело обстоил лучше)
не буду я извиняться за чужой обсер.
напоминаю оригинальное БРЕДОВОЕ заявление
"В котлине нет проверок на NULL в рантайме. В c# фича nullable помимо статического анализа добавляет в IL код проверки на null на каждый вызов, но только в релизную сборку"
я выступил против этих слов и попросил автора бреда предоставить пруф
И то, что мне начали впаривать про "нулл проверки поскольку рантайм ничего не знает про не-нуллс ссылочные типы" - вообще к теме не относится.
Такое положение дел и в шарпе и в шарпе (и автоматически в котлине)
А вот с фичей nullable все обстоит РОВНО НАОБОРОТ от этого заявления
И я по прежнему жду кода пруфа который можно скомпилить и увидеть проверки на нулл которые будут вписаны в IL. calvirt это не проверка на null на уровне IL - это просто вызов метода.
>и в шарпе и в шарпе
и в шарпе и говножаве (фикс)
то есть я жду где мне предоставят пруф что фича nullable что то там вписывает.
МикроКонтроллер
>>3382123
Там не только прошивка, но и прошивалка прошивки, а у неё оконный интерфейс.
>>3382141
Потому что надо преобразовать аски-код цифры собственно в саму цифру.
>Там не только прошивка, но и прошивалка прошивки, а у неё оконный интерфейс.
А ведь были времена, когда и гуй некоторые на асме писали...
>Есть не только байтоебные области где, это может быть удобнее, например кодирование цветов намного удобнее и нагляднее в hex, чем в 10-ричной системе.
А в данном то конкретном случае оно тебе что дает? Вот блять, если честно, начинают заебывать гении, придумывающие свои оптимизации... Извините, просто накипело, третий день не могу отойти от отечественной разработки "ЛМ ЧЗ", где цену приводят в целое до копеек и кодируют в 80-ричную систему, да и хуй бы с ним, но они еще и словарь свой придумали...
какие нахрен оптимизации
байт пишется как БАЙТОВОЕ ПРЕДСТАВЛЕНИЕ ЯВНО, чтобы оно ТАК И ЧИТАЛОСЬ
что за хрень ты несешь, гений блин.
И ведь блять не прикопаешься, "14630" до “ACW.” сократили, аж блять на 20%, кто-то наверно и премию получил...
А ведь могли бы использовать 16-ричную систему и полусить те же 4 символа - "3926", только для конвертации использовать стандартные либы, а не весь вот этот пердолинг...
Что лучше подойдёт как результат проверки на содержание словарём ключа и значения, если такой ключ таки содержится?
Мне больше нравится левый вариант (потому что это один класс, не надо проверять тип), но я никак не могу придумать нормальное имя для метода Contained - всё, что приходит в голову, больше тянет на свойство, либо получается длинная херота.
Изобретаешь велосипеды с квадратными колесами
причем они не на раме даже, а на руле
Вот то, чем ты сейчас занимаешься - это вредительство в чистом виде. Ты поверх c# и стандартной библиотеки пишешь поносную хуету, которую перестанут сопровождать как только ты покинешь проект.
Ну или сам повзрослеешь, перестанешь маяться хуйнёй и просто возьмёшь Automapper, который отвечает за эту хуету в нормальных проектах.
Брух, я хуй простой скуф, даже не вкатывальщик в айти, у меня это хобби. Я даже сижу на старой версии, ибо зачем мне новое, если я базу ещё не понял.
>Если я базу ещё не понял.
А чего её понимать? База это понимание двух вещей: MediarR и Automapper.
Строишь на них событийно-ориентированный доменный автомат, и оно всё само за тебя работает, ты только сущности добавляешь
А не похуй ли что там будут сопровождать что не будут?
Вот срсли.
Кабан-кабанычу - хуйлан. Коллеги - хуйланы.
Все вокруг - пидорасы, которым похуй на все, кроме на деньги.
Так нихай страдают.
Переопределил в коде все что только можно, самые критически важные куски кода завязал на свою функциональную хуйню. Шлифанул всезд где можно и нельзя ансейфом, ну и свою ОРМ сверху, на которой вся работа с БД построена сделал.
Если сдохнет - ну, и славно, я весело провел время.
Респект. Делаю точно так же.
Правда коллеги у меня норм, заняты примерно тем же чем и я, просто мы договорились не мешать друг другу весело проводить время.
Мне надоело учить коллег как правильно делать ООП и DDD, я бы хотел, чтобы это автоматически работало, где-нибудт при сборке
А причем тут OOП и запрет new. Я бы тебя нахуй послал и сдал техлиду или СТО что ты долбоеб проф непригодный который вместо нормального кода DDD делает.
Чел, на всех серьёзных проектах запрещают создание объектов через NEW. Для этого существует Automapper, Ну, или на худой конец можно написать абстрактную фабрику, или если вообще припекло - через рефлексию создавать. Вот так мы на прошлом проекте создавали объекты
Там, смотри скриншот выше приложил, я немного сократил обработку исключений, но основная мысль в том, что всё работает САМО, и тебе не нужно никаких NEW писать.
вот ты ругаешься, а у человека ДОХРЕНА свободно времени и ДОХРЕНА дури чтобы все это творить.
>Мне надоело учить коллег как правильно делать
А схуя ли ты решил что это правильно?
New - это рак.
Вот серьезно. Особенно в эпоху когда у тебя есть DI.
Знаешь насколько кайфово, когда вот такой вот охуенный дед, который любит всюду new хуярить - потом ходить и за ним говно вычещать, потому что еблан забыл отписаться, задиспозить нужное или еще что-то.
Про тесты я не говорю.
new в 2025 это все равно что руками дергать сисколы, писать обработчики прерываний или выделять память. С вероятностью 99% ты насерешь, потом остальным разбираться.
У нас физически невозможно new вызвать У нас полное DDD и так получается, что мы только с абстракциями работаем. Во всех контрактах у нас интерфейсы. А они в свою очередь автоматически резолвятся в соответствии с настройками DI.
Просто инжектишь IMediator и он за тебя всё делает как надо
>потом остальным разбираться
Ну так и радуйся, это озанчает, что у тебя будет работа.
>new в 2025 это все равно что руками дергать сисколы, писать обработчики прерываний или выделять память. С вероятностью 99% ты насерешь, потом остальным разбираться.
В гайдлайнах Microsoft запрещено new писать. Только Activator.CreateInstance(...)
>У нас физически невозможно new вызвать
то есть не делаете new List<>/Dictionary<>
сдается мне что ты пи.....лукавишь
Для такого в нормальных проектах есть отдельная фабрика, создающая коллекции, чтобы всякие мимокроки не создавали непонятно что.
>то есть не делаете new List<>/Dictionary<>
Ни в коем случае! У нас запрещены не-доменые коллекции (читай, которые ломают событийную модель). Все коллекции заменены на асинхронные, которые через медиатор тригерят события.
Зачем для всего? Пишешь одну фабрику, она тебе создаёт все объекты. Ну или настраиваешь маппер, на создание объекта из энама объектов:
var domainIdentity = _mapper.Create(DomainFactoryObjects.Identity).AsAggregate<IdentityDomainAggregate>;
>>3384084
А после работы вы садитесь в кружок и дрочите друг другу приговаривая - "Какие же мы охуенные, у-у-ух, бля...".
А как вы пишете
Создание вспомогательных списков, массивов и причём тут блять DDD и ООП?
В ООП нет никаких запретов на прямое создание объекта, а ДДД вообще к коду не имеет отношения это инфоцыганская хуйня для аналитиков.
>Ни в коем случае! У нас запрещены не-доменые коллекции (читай, которые ломают событийную модель)
Ебанутый, причём тут событийная модель которая относится к взаимодействию разных сервисов или общей шине монолита и коллекции.
Ты блять как например делаешь
var zalups = new List<Zalupa>()
//Хитрое создание залуп из пуп
return zalups;
Где-то в проекте у тебя будет вызовы new. Ты не сможешь ничего написать без этого.
>А как вы пишете
Через DDD
> Создание вспомогательных списков, массивов и причём тут блять DDD и ООП?
В домене нет списков и массивов. Всё, что не раскрывается в домене не имеет смысла создавать в коде. Читай ниже пример с портфелем
> В ООП нет никаких запретов на прямое создание объекта
Не запрещено. Но в домене всегда есть вездесущий язык, на котором пишется доменный код. А в нём никаких NEW нет.
Вообще считается, что есть ряд признаков, по которым можно отличить мусорный императивный код от обычного ДДД:
- Создание объектов руками
- Более одной точки с запятой в методе
- Использование реальных классов за место абстрактных интерфейсов
- Использование функций, которые не привязаны к объектам
- Использование примитивных типов, не относящихся к домену. У тебя по сути не может быть МАССИВА потому что в домене вообще никогда не бывает таких категорий. Может быть, например ПОРТФЕЛЬ С ПИСЬМАМИ. Или у тебя не может быть переменной Int32, у тебя всегда определяется доменный тип КОЛИЧЕСТВО.
Такая хуйня. Я первый раз тоже долго вникал, но потом понял, и оказывается, в ДДД, после того как всё правильно настроили, вообще код почти не надо писать. Добавил аггрегат, а он сам по себе работает
>Ты блять как например делаешь
>var zalups = new List<Zalupa>()
>//Хитрое создание залуп из пуп
>return zalups;
Такого кода не может быть в ООП. Как ты тест напишешь?
Вижу два решения:
- Корректная конфигурация маппинга пуп на залупы. Ты декларативно описываешь логику и никаких new нет
- Фабрика, котрую ты инжектишь. Но это не фабрика List<Zalupa>(), а абстрактная фабрика доменного агрегата залуп. Скорее всего будет фабрика хуя, потому что залупы никогда не бывают в списке и это нарушает доменные ограничения
Плохо что так нельзя
(byte)0x30
Интересно почему есть такое ограничение? Или тупо не догадались добавить?
>Можно так делать, работает, компилируется.
А вот и не знаю, такое вот не компилируется:
byte [] говно;
byte жопа = говно[5] - (byte)0x30;
конечно
потому что при
byte foo = 0x30
компилятор может скастить в byte при компиляции и быть уверенным что все ок
а результат вычитания это int и если тебе так надо byte, то сам касти его к byte подписываясь под договором о ССЗБ
>а результат вычитания это int
Как вообще из (byte) - (byte) может получится int? Что за шиза?
Блять, ты добоеб, тебе же выше кидали ссылку на доки.
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#1247-numeric-promotions
как как
читай определение
Представляет 8-разрядное целое число без знака.
А теперь отними 10-100 и попробуй выполни условие.
А для надежности отними 0-255 и попробуй впиши в 8 бит
как получится - пиши в мелкософт что они все идиёты
>>3384284
>для надежности отними 0-255 и попробуй впиши в 8 бит
0000 0001
Я понимаю, что защита от дурака и всё такое. Но если я использую byte значит я занимаюсь байтоёбством и здесь любые ограничения только во вред.
>мелкософт что они все идиёты
Таки да.
Вот тебе на пике от самого Скита ответ
(ссылка для истории https://web.archive.org/web/20140118181840/http://bytes.com/topic/c-sharp/answers/463685-why-does-adding-2-bytes-together-result-int )
>>3384312
>Таки да.
Можешь заодно в Sun/Oracle написать и в джава тред сходить пожаловаться, потому что в джаве то же самое поведение.
>0000 0001
вижу число ОДЫН
> Но если я использую byte значит я занимаюсь байтоёбством
ну так делай это ЯВНО. я вот не хочу 0 - 255 получит ОДЫН и узнать об этом где то потом в рантайме в проде.
>здесь любые ограничения только во вред.
нет никаких ограничений. есть просто НЕСКОЛЬКО перегрузок операций арифметики для упрощения этой самой арифметики с учетом возможности переполнения (ну чтобы его не было лишний раз).
>>3384316
> в джаве то же самое поведение.
но учитывая что шарп это калька с жавы, то ожидаемо. Они оттуда и null притащили
А так да - ТАК ИХ. пусть знают что нех мне тут ишь ты чего удумали мешать байтоебу стрелять себе по ногам.
>ишь ты чего удумали мешать байтоебу стрелять себе по ногам.
Чел, дело не в возможности выстрелить себе по ногам. Возможность байтоебить в шарпе - это побочка и вряд ли покрывает хотя бы несколько процентов кейсов его использования. И при использовании byte и прочих подобных типов меньше int оно все будет каститься для арифметики к int-у или выше. Просто потому что это тупо быстрее на 99% современной архитектуры. Да даже МК сейчас все 32x поголовно и стоят копейки.
Поэтому если ты хочешь прям хардкорно байтоебить, то врубаешь ансейф, кастишь все явно, юзаешь указатели и т.д. Ну или берешь обычный C, Rust или еще что и не ебешь себе мозг.
>Поэтому если ты хочешь прям хардкорно байтоебить, то врубаешь ансейф, кастишь все явно, юзаешь указатели и т.д. Ну или берешь обычный C, Rust или еще что и не ебешь себе мозг.
Зачем, если можно просто Automapper взять и замаппить мутный байтоёбский код на обычные доменные сущности?
>нужно
Сначала добавляешь два нугета Automapper и MediatR. Затем все регистрации DI переписываешь на обработку команд из пайплайна. Команды создаёшь автомаппером.
Очередной долбоёб будет переписывать приложение на медиатр/автомаппер, чтобы байтоёбские проблемы починить. Надеюсь, ты проебёшь 2-3 месяца на это, и потом вернёшься к работе
Спасибо за такие высокие оценки моей продуктивности. Я планировал месяцев 5 потратить на рефакторинг.
Очень интересно.
Все плюсы CQRS паттерна. Не нужно регистрировать ничего, всё само работает. Код гораздо более понятный для компилятора становится. В конструкторе не более двух зависимостей. Автоматические перехваты любых вызовов, AOP из коробки
Минусов нет
https://arialdomartini.github.io/mediatr
https://habr.com/ru/articles/705296/
Я для маппингов в последнее время стал использовать Mapster с его функцией кодогенерации маппингов в методах-расширениях. Они для моих кейсов (маппинг dto-ки в dto-ку) лучше подходит. Во-первых, сильно быстрее работает, а во-вторых, всегда можно понять, как он там маппит, нормально это поотлаживать (банально можно в сгенерированный метод провалиться во время отладки) и руками исправить маппинг в случае чего.
Плюсы Automapper:
Легче отладка
Быстрее навигация по коду
Не вбрасывает никаких исключений, просто работает
Автоматические конвертации
Чистая архитектура невозможна без автомаппера
Выше производительность, и быстрее компиляция, старт приложения (автомаппер работает отложенно).
Минусов нет
Вот получил я по езернету некий кадр, как бы я сделал раньше? Я бы создал указатель на структуру и присвоил ему адрес кадра и бац! у меня кадр сам по полям разложился. А тут?
Хуйтут. Если тебе надо кадры дрочить и память нахуй ты на С# полез.
Выучи блять больше 1 языка. Желательно С++, С#, питон, JS и ещё какой на твой вкус. Каждой задаче необходим свой инструмент.
Да пизжу, конечно. Автомаппер - это мусор, который работает тогда и только тогда, соблюдают КОНВЕНЦИИ.
А конвенции обязуют иметь одинаковое именование и предсказуемую структуру данных во всех слоях.
На практике этого возможно добиться только в CRUD приложении на 2-3 сущности, но там не требуется множества слоёв, и, соответственно, автомаппер не нужен.
ну это сильно низкий уровень. Можно и повыше быть в районе MemoryMarshal, Unsafe и по возможности работать с ref не опускаясь до чистых указателей.
https://learn.microsoft.com/ru-ru/dotnet/api/system.runtime.compilerservices.unsafe
там смотри примеры
все верно. С его помощью ты опасно копаешься в кишках Span с помощью некоего высокоуровнего апи, но все же не опускаешься до сырых указателей (которым нужно делать fixed чтобы GC не сломало всё посреди операции)
>С его помощью ты опасно копаешься в кишках Span
Если, про MemoryMarshal, то да, он по большому счёту про спаны, но Unsafe'ом можно ковырять любой ref.
>с помощью некоего высокоуровнего апи
Ты серьёзно? Unsafe - ни одного высокоуровнего апи, MemoryMarshal - может и можно некоторые методы с натяжкой назвать высокоуровневыми.
>но все же не опускаешься до сырых указателей
По тому как ты выразился у меня складывается впечатление, что ты считаешь: "раз нет unsafe контекста, то значит это безопасней" (я столько раз видел такое мышление, это просто пиздец; как люди ебашат просто лютейший UB, но "зато без unsafe").
>(которым нужно делать fixed чтобы GC не сломало всё посреди операции)
Зато Unsafe'ом или MemoryMarshal'ом можно случайно превратить ref, который указывал на объект, в ref который теперь указывает хуй пойми куда (или наоборот).
Хочется больше уточнить по поводу ref.
По спеке ECMA-335:
>If address arithmetic is used to create a managed pointer that refers to any other location (an object header or a gap in the allocated memory) the garbage collector’s behavior is unspecified.
Но рантайм вроде частично ок с этим (по крайней мере пока этот ref не dereferenced).
Вот, проблема в том что GC смотрит на ref'ы, а на указатели ему поебать. И с помощью этих апи можно случайно изменить ref таким образом, что GC может его обновить при сборке мусора (так как ref начал указывать на объект) или наоборот не обновит (если ref перестал указывать на объект).
MemoryMarshal имеет Create[ReadOnly]Span() и GetReference() методы, которые вообще не проверяют аргументы (и с этими методами можно: записать в ref который ты получил и пустого Span'а, создать Span с неправильной длиной (а если с отрицательной, то 100% UB, ведь JIT генерит код считая что у спана длина не может быть отрицательной) и т.д.).
И нормальных туториалов по Unsafe и MemoryMarshal нет. Даже в доках толком примеров нет (ну хотя бы Unsafe говорит какие разделы спеки почитать, но сколько людей реально пойдут читать, а не сразу побегут играться с новым ногострелом). И ещё есть туториалы в которых с помощью StructLayoutAttrbiute ебашат UB.
В общем, ref'ы не безопаснее, чем голые указатели (а если учесть что множество туториалов про unsafe (указатели и т.д.) слишком поверхостные, то указатели могут оказаться даже безопасней, особенно для новичков).
Ну и в догонку:
>Enumerating type safety guarantees in MemoryMarshal and friends
https://github.com/dotnet/runtime/issues/41418
>раз нет unsafe контекста, то значит это безопасней
я не говорил безопаснее. Я говорил про уровень погружения в пучину.
Тебе проще на сырых указателях, а мне ровно наоборот - ехал спан через спан и иногда палец в спан.
С доками да, но на самом деле их валом статей и я следил за рождением всего этого поэтому мне это ближе.
А на unsafe чистый не лез, мне такое погружение не нужно.
Это всё, конечно, интересно, но задача это типовая. Неужели нет способа лайтовее её решить?
Для языка, на котором пишут системщину, может и типовая. Но не для языка, на котором перекладывают жсоны и клепают формочки.
Я вообще не понимаю нахуя с байтами арифметика, запретить и нахуй. Байты как тип имеют полное право на жизнь для составления датаграмм в протоколах железок, типа если надо с сериал портом работать, т.к. в даташитах этих протоколов все в байтах и это правильно. Но арифметика...
>MediatR
Не слышал. Посмотрю.
>>3386863
>>3386874
>для языка, на котором клепают формочки
А если надо и то и другое?
>>3386920
Не ну можно, конечно, и битовыми операциями обходиться, маски накладывать, но иногда, как в моём случае, легче вычитанием бахнуть.
Подразумевается сборка в DLL. API в данном случае - это публичные классы и методы с документацией.
> API в данном случае - это публичные классы и методы с документацией.
У них в тз написано, что чтобы инициировать загрузку данных, нужно по rest api обратиться к самому приложению.
Во
> POST /api/load
> Content-Type: application/json
А чтобы получить данные, соответственно с GET уже.
Такое приложение всё равно же можно собрать в DLL? Хотя нет, я не понимаю. Нужно ли в итоге писать главный проект, где точка входа.
Ты случаем не в одну волгоградскую контору собеседуешься?
Нет, не в волгоградскую. А ты о какой? Какая-то известная в узких кругах?
> У них в тз написано, что чтобы инициировать загрузку данных, нужно по rest api обратиться к самому приложению.
Тут надо дёрнуть стороннее REST API через какой-нибудь HTTP-клиент, но собственное API проекта - это публичные методы.
> Такое приложение всё равно же можно собрать в DLL?
Да.
> Нужно ли в итоге писать главный проект, где точка входа.
Если напрямую не требуют, модно не писать, но лишним не будет для ручных тестов.
Не важно, просто ТЗ формулировкой очень напоминает то, которое я для них делал когда-то давно.
Если они руководствуются той же логикой можешь сделать так.
- делаешь основное приложение - стандартный asp.net сервис, у которого есть API, в который ты можешь ткнуться. В Api два эндпоинта. Один для сохрания данных, который будет принимать запрос, сохранять в БД и возвращать Id. И второй метод это возможность по id проверить статус этих данных (предполагается, что за это время с ними какая-то работа совершается, например фоновой задачей)
- делаешь отдельную библиотеку-клиент в которой предоставляешь интерфейс через который можно дернуть нужный сервис.
- делаешь простое консольное-мок-приложение, к которому подключаешь эту библиотеку и чтобы пользователь мог через него сохранить свои данные и получить их статус.
Ну и все это подготавливаешь для показа. Первый сервис где-нибудь разворачиваешь или подготавливаешь докер для него. Для мока делаешь билд, который можнго запустить и потыкать палочкой. Ну и всякие там документации исходники и т.д. не забываешь.
>я не говорил безопаснее. Я говорил про уровень погружения в пучину.
>Тебе проще на сырых указателях, а мне ровно наоборот - ехал спан через спан и иногда палец в спан.
Не, я за спаны и всё такое (к тому же учитывая что только спаны получают "интересные" (LastIndexOfAny, SearchValues и т.д.) апи, а String и Array - ничего из этого). Я скорее про то что если лезть в MemoryMarshal и Unsafe надо быть особенно осторожным (учитывая нюансы перечисленные в >>3386788 ).
>С доками да, но на самом деле их валом статей и я следил за рождением всего этого поэтому мне это ближе.
>А на unsafe чистый не лез, мне такое погружение не нужно.
А каков процент статей которые идут дальше чем: fixed - в статьях про unsafe, "щас строки без аллокаций поковыряем" - про спаны? К тому же большинство статей про unsafe контекст старые как говно мамонта (даже новые, блядь, содержат инфу 15 летней давности). Я не спорю что такие блоги/статьи есть, где автор полностью осознаёт что делает и осведомлён о последних нововведениях рантайма и языка, но такие ты хуй найдёшь просто написав в гугле что-то типа "C# unsafe", "C# span" и т.д.
И ещё по поводу доков.
Вот сколько людей в курсе что с C# 11 можно объявлять указатели на managed типы? И ты эту инфу просто так не найдёшь.
"What's new in C# 11" в офф документации - нихуя.
В статьях про unsafe в офф документации - нихуя.
В статьях в .NET блоге - тоже нихуя.
А вот в репе языка и в репе Roslyn, если очень присмотреться то ссылка с текстом "ref fields" ведёт на proposal "Low Level Struct Improvements", который без оглавления, и там в середине текста есть маленький рандомный раздел "Changes in unsafe context" с двумя короткими предложениями (которые можно случайно проглядеть в таком большом документе) по этому нововведению. Ведь очевидное место поиска, да?
https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/low-level-struct-improvements.md#changes-in-unsafe-context
Пришел читать про ref fields, а тут в середине про какие-то указатели.
не буду спорить. Это нужно следить за разным типа
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/
там упор именно на перфоманс поэтому больше наваливают про спаны. Например, кто знает про AlternateLookup у словаря?
ну и за подобным https://www.bytehide.com/blog/everything-new-in-net-9-the-ultimate-developers-guide
где по верхам остальное.
но конечно это не научит применять Unsafe
поэтому для этого я смотрю проект SpanJson, который упоролся именно в Span/Unsafe (и поэтому рвет по перфомансу решение от мелких, но более low-level), хожу читаю его код и такой "гм, а что это он тут делает, что за магия" и начинаю разбираться
У них написано, что в саму программу нужно JSON передать через http. И результат работы программы тоже через JSON проверять.
>>3387326
> стандартный asp.net сервис
WebApi ?
Короче, вот
https://itpdevelopment.ru/testjobbackend.html
Судя по описанию - банальный враппер над хттпклиентом
оно же RestClient, оно же - то что генерят всякие Retrofit(для жавы) или Refit для шарпа, оно же - typed http client как его понимает мелкософт в их HttpClientFactory
и апи это собственно сам такой класс, однако....
>>3387421
судя по этому
>У них написано, что в саму программу нужно JSON передать через http. И результат работы программы тоже через JSON проверять.
таки да нужен вебапи, который будет получать запрос и дергать что то внешнее через вышеописанные typed http client и возвращать. Ну и у себя в бд хранить.
в общем очень простая штука
только вот уже это не библиотека как бы, а приложение
поэтому нипанятна
>ну и за подобным https://www.bytehide.com/blog/everything-new-in-net-9-the-ultimate-developers-guide
Я промолчу про рекламу, но я рандомно глянул и:
>It is now possible to declare extension methods on readonly struct without losing the benefits of immutability.
???
>C# 13 allows defining constants that were previously not possible, such as DateTime values.
???
Ты разраб ByteHide?
Слово из спам листа?
нет. просто дал пример первый попавшийся. Я не храню в закладках прочитанное.
Просто если читать разные what's new, а не только офф доку (в которой только основное), то можно много разного найти и узнать.
Да, есть такое. Ненавижу это говно. Дохуя лет проебал на DDD CQRS (медиатор+говнокод+до 6 слоёв автомаппинга), теперь нашёл ссаный угол, где можно излить душу.
Не вини меня, иди на хуй
создаю с нуля два дефолтных winforms проекта
- первый под .net framework 4.8
- второй под .net 7.0
нихуя нигде ничего не правлю, т.е. проект просто с пустой дефолтной формой и все. Компилирую оба проекта в release и наблюдаю следующее
1. экзешник под .net framework весит 6.5кб и стартует мгновенно
2. экзешник под .net 7.0 весит 150кб(!!) и стартует на порядок медленнее. Плюс рядом с экзешником test.exe еще лежит какая-то либа test.dll, хотя у меня чисто винформс проект и никакие либы я не добавлял.
Почему так? В плане почему медленнее старт, почему exe весит 150кб а не 6.5кб и че за либа компилится в дополнение к ехе.
>че за либа компилится в дополнение к ехе
эта либа и является основной. это ехе генерится как дополнение к ней.
потому что дотнет 7 он же коре является кросс и само приложение лежит в длл и рассчитано на запуск как
dotnet appname.dll
вот можешь даже винформс проект так запустить.
а для винды компилятор услужливо генерит ехешник с иконками и хз каким еще добром.
Пиздец блядь, т.е. распространяя свой софт я должен одновременно в комплекте с ним распространять еще какой-то ёбаный левый экзешник с неясным функционалом, у которого даже сорцев в паблике "почему-то" нет, хотя .net вроде как уже опенсорсный. Охуенно.
>т.е. распространяя свой софт
А ты у нас ниибаца издатель?
Это да. Хз почему он разного размера
У меня и полметра есть
Это ты ещё не думал о пользователях, у которых не установлен рантайм дотнета. Иначе бы и не заметил этот несчастный экзешник на фоне сотни дллек.
>о пользователях, у которых не установлен рантайм дотнета.
Похуй на них, они не являются нашей целевой аудиторией.
>у которых не установлен рантайм дотнета
подлая штука кстати. ставились разные рантаймы студией, потом студия обновлялась 17-19-22, а в итоге старые рантаймы и не удалить. Ни один способ не помог ибо "где дотнет ставили (студия определенной версии) - туда и идите".
пришлось внаглую удалять папки и чистить реестр руками.
>а в итоге старые рантаймы и не удалить
Ты что поехавший, нафига их удалять?
а нафига они мне нужны? Я давно все свои проекты перевел на дотнет 9
ну 8 ладно LTS
остальное нахер не нужно, тем более всякие 3.1
а место на диске кушает
у меня 100 гигов диск (теперь то сложно ресайзить) и контента на нем на все 1000000 триллионов сестилитеррабайт. Потому что всякие там жетбраинсы срут инсталлерами на диск с (а там 11 гигов папка инсталлерс, что просто ....тут нет цензурных слов... и ее нельзя удалить и переносить чревато) Потому что всякие кеши пакетов срут туда (ну ладно можно отключить), нюгет кеш туда же (и где тулза по его очистке от старых версий пакетов???)
всякие постманы, гитхабклиенты срут своим говном и сами говно по много сотен гигов. Нвидиа со своим говнософтом так вообще лютый северный зверёк.
меня спасают симлинки (но не всегда, ведь СРАНЫЙ ЖЕТБРАИНС С ИХ ЖОПОРУКИМ СОФТОМ), но проблема ведь не в наличие места, а в ГОВНЕ.
>у меня 100 гигов диск (теперь то сложно ресайзить)
Сейчас нормальный M2 SSD на 1Тб, можно за 6...7К взять.
Чего тут сложного?
>студия обновлялась 17-19-22
С 17-го то года, можно с обедов по 10 рублей откладывая на несколько таких накопить.
>Чего тут сложного?
у меня ссд суммарно на 2.5 тб. причем ссд нормальные, а не китайский дешман. Я, как и все разработчики на шарпе, с одной зарплаты могу весь комп поменять, но зачем...
Просто заниматься расширением ЧРЕВАТО (в далеком году с помощью акронис партитион пытался расширить диск ц и оно ушло на 12 часов и в итоге просто запороло мне полностью хард так что доверия у меня этому нет)
и руки не доходят.
но я повторюсь - ГОВНО засрет все доступное пространство хоть всю вселенную, да и соседнюю.
вот наглядный пример. хочу в сервисе делать уведомление в винде 10. Ну чтобы никакое WPF приложение не висело. Так хрен там - нужно UWP, а чтобы его писать нужно отдать еще 8 гигов чтобы просто получить возможность сделать уведомление в винду
потому что какой то ИМБЕЦИЛ решил что это может делать лишь UWP приложение и нельзя "просто подключить какой то там пакет с нугета".
Он же на каждом углу, как и в любом высокоуровневом языке кроме жабы. Автопроперти, инициализаторы, вывод типов, лямбды, юзинг по IDisposable, форыч, LINQ, экстеншн методы, асинк.
AOT-му коду не нужен прогрев (сбор статы и компиляция горячих методов с большим уровнем оптимизации), приложение сразу со старта быстро работает. А значит его можно для облачных функций в том же Azure нормально использовать, т.к. выгрузить все приложение из памяти к херам, а потом по первому пришедшему запросу его снова запустить это нормальная практика. А если ему каждый раз прогреваться нужно, то время ответа таких функций будет страдать + ценное процессорное время впустую тратится. Вот M$ его и форсит. И все допилы под AOT того же ASP.Net Core прям видно что на майковское облако нацелены.
Ну и для десктопных приложений это норм тема, т.к. время из запуска уменьшает.
>т.к. время из запуска уменьшает.
только работает разве что для консольных приложений.
>допилы под AOT того же ASP.Net Core
Только смысла в них минимум, т.к. в асп-сервисе по любому при старте будет куча всяких инициализаций, на фоне которых разница между AOT и JIT будет копеечной.
Дохуя, на самом деле.
1. Без АОТ невозможен Xamarin-IOS.
2. Ускоренный запуск Xamarin-Android.
2. Лямбда-фунции в AWS дешевле, там оплата буквально по миллисекундам
3. Особо оптимизированная ебала наподобие последних оптимизаций System.Text.Json, которые наполовину из кодогенераторов состоят. Вот представь, что у 200 тысяч структур, которые ты в дженерики завернул и у тебя джит конпелятор на каждый новый вызов их компилирует. А теперь представь, что АОТ может эту хуйню как ускорить, так и наоборот замедлить.
ОПЦИЯ, короче, которая тебе нахуй не нужна, но потом внезапно так сильно нужна, а ты долбоёб, на пейфоне напрограммировал и у тебя всё тормозит как у шлюхи
>на фоне которых разница между AOT и JIT будет копеечной.
Для особо упоротых случаев же, где либо на кресты переписывай, либо ебись конём
Ну, если у тебя прям микро-микрописечный сервис с тремя ендаоинтами на minimal api, то может и будет иметь смысл.
С другой стороны, если он такой микро, то там и джитом все нормально жить и стартовать будет.
В общем, актуально только в облаке, где тарификация по миллисекундам процессорного времени.
Я спросил гопотоу и дипсик, они какую-то залупу с тем чтобы мидлвар ебашить и проверять конфиги в нем с редиректом хуйнули. Даже я понимаю какая хуйня.
В общем. Суть. Меня заебало, что каждый раз, блядь, кто-то не может инструкцию, которую, блядь, я написал, сук, кладу прямо рядом с дистрибутивом и все это вот - не могут ебучую строку подключения и сертификаты положить куда надо.
Хочу чтобы приложуха такая: бля, чет недонастроили, го настраивать.
Мое видение было такое изначально - я просто в main проверяю, не вижу конфиги или они коррапчены - хуяк, делаем свой веб-ап второй, на рандомном порте запускаем, запускаем бравзер и просим настроить. Все ок - завершаем приложуху и по основному сценарию - сконфигурировали, хуе-мое настроили и погнали.
Но вроде как выяснил что заеб в том что ConfigurationManager - в единственном экземпляре и вообще ну тип не хорошо.
Второе решение было - ну ок, будем так же - но типа процесс отдельный запускать, ждать пока он завершится, дальше - если теперь-то конфиг правильный - запускаемся, иначе - пишем, ну сорян, конфигурируй сначала.
Но вообще чет мне кажется что я куда-то не туда копаю. Ну не может быть такого что только меня заебало каждый раз писать разворачивателю, где ж там в appsettings.json - прописать эту самую строку подключения. Сто пудов есть что-то что кто-то умный сделал уже.
В общем. Кто знает - помогите.
В логи пиши просто "Пидар, конфиги проверь" и падай. Нахуя чет выдумывать. Если кто-то твой вебсервис запускает, он по любому либо логи должен читать, либо у него мониторинг есть в котором он это увидит.
Ну вот челы из не буду писать откуда, а то клиентов обзывать нехорошо - не читают, пишут на почту поддержке - те мне.
Да много кто не читает как я понял. Я бы не думал об этом вообще, если бы постоянно не присылали: КАК СЕРТИФИКАТЫ ПОДКИНУТЬ? КАК К БД УКАЗАТЬ НАСТРОЙКИ??
Это при том что в той ебаной инструкции буквально как раз эти кейсы описаны прям по шагам, просто скопируй, поменяй на свое если надо. Ну да ладно.
Но вот немного подумал-подумал и решил, что вместо веб-сервера можно авалонию хуйнуть, лол. Все так же, но мы типа при старте не веб-сервер а авалониевскую хурму запускаем, причем в двух видах - одну как десктопное приложение, вторую как веб-хуитку в случае работы на серверах, после настройки - таки основной сервер. Максимально простой как мне кажется способ, при этом - ну уже ну невозможно будет обосраться.
Он буквальнов в try {} finally { dispose } разворачивается, куда уж сахаристее.
>ну уже ну невозможно будет обосраться.
Ага. А у пользователя на другом порту уже что-то висит, или порт вообще заблочен.
Плюс сама ситуация когда твой сервис вместо основного запуска, делает что-то совершенно другое, вызовет еще больше вопросов и тебе будут предъявлять уже за это.
> Зачем нужны перечисления если есть словарь?
Словарь это синтаксический сахар над перечислением
>Ну не может быть такого что только меня заебало каждый раз писать разворачивателю, где ж там в appsettings.json - прописать эту самую строку подключения.
Суть в том, что у тебя приложение может конфигурироваться с нескольких источников, и эти источники как бы накладываются друг на друга, которые накладываются друг на друга согласно приоритету.
Притом, у тебя могут быть как встроенные в код источники, так и внешние:
https://microservices.io/patterns/externalized-configuration.html
По классике делают так:
В самом начале идёт appsettings.json, Туда складываются базовые настройки, коротые вообще никогда не меняются
Чуть выше приоритетом идёт appsettings.ENVIRONMENT.json . Тут идут настройки согласно контуру (окружению), в котором запущено приложение. В принципе, если тебе похуй на безопасность, то можешь просто сложить все настройки отдельного контура в appsettings.Production.json . Как приложение поймёт, что оно продакшен - читай тут https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-9.0
Еще выше приоритетом стоит источник, который берёт настройки согласно переменным окружения, которые контейнер получил из кластера. Это обычно в конфигурации кубера настраивается
Ещё выше приоритетом стоят секреты (коннекшен-стринги, ключи апи), которые приходят из хранилища секретов, например Vault, они тоже приходят в приложение из переменных окружения, но немного другим способом
Если делать всё по правильному - то дохуя сложно получается. Но твоё решение с прерыванием процесса запуска для настройки - странное
Я все это знаю, няша.
Типа ну срсли. Когда все поднимаем мы - нет никаких проблем. Но у нас клиенты такие, что им часто надо, чтобы на их мощностях поднималось, их админы/девопсы этим занимаются. Им просто передается инсталлятор(deb/rpm/msi)/контейнер. Передаются инструкции. Но хурма с тем что что-то они там донастроить не смогли происходит и прилетает постоянно - а как сертификаты, а как подключение к бд. А как то. А как это. Задалбывает вот серьезно.
Ну и опять - учитывая что у всяких Gitea, Gitlab есть таки этот самый "первый запуск", который позволяет поднять контйнер и просто ручками донастроить если не настроили - не то чтобы прям это что-то странное.
Ваши проблемы. Мои проекты не требуют от пользователя ничего кроме указания где находится БД.
>Им просто передается инсталлятор(deb/rpm/msi)/контейнер.
Нихуя себе. Ты отдаёшь 4 экземпляра собранного приложения без зависимостей в сторонний деплой и говоришь, что это "просто".
На мой взгляд, ты пытаешься сложное обозвать простым и проблемы спихнуть.
Вообще, вижу, что тебе надо просто на этапе инициализации приложения вбрасывать вменяемые исключения на каждую отсутствующую/неправильную настройку.
Вбрасывай так, чтобы даже индус или xoxoл разобраться мог: "При запуске приложения обнаружено, что у вас в настройках недостаточно корректно указан параметр ConnectionStrings__MainConnectionString, Укажите переменную окружения ConnectionStrings__MainConnectionString , которая указывает на рабочий инстанс вашей базы данных Postgresql в следующем формате: ФОРМАТ"
Ещё лучше чтобы он давал шаблон настроек с комментарием что где и как вписать.
Совсем дурак? Словарь можно менять в динамике, перечисления же - константа.
ты бы тест в военкомате бы завалил с таким ответом. Сразу бы получил категорию Д
Лежит не просто рядом с кодом а в нем.
За 5 лет того что выносил в файлики то что должно быть как бы спраочниками - ни разу не было такого что надо что-то добавить в перечисления без компиляции новой версии.
Опять же - пропадает говнокод который вызывается тем что ты либо каждый раз лезишь в БД проверить - а что это либо забиваешь и хардкодишь значения перечислений прямо в коде когда лень проверять нормально, тут ты их постоянно под рукой имеешь.
Ну и самое удобное - ты просто берешь и выносишь это в общую сборку и если нужно в нескольких сервисах - они все эту ДЛЛ подключают и радуются.
В чем я не прав?
>Совсем дурак? Словарь можно менять в динамике, перечисления же - константа.
Ил код посмотри
>В чем я не прав?
Все коллекции пустые, тебе очень повезло
Ну. Мне лень накидывать было.
Суть-то не в коллекциях, а в том чтобы не выносить из кода всякие перечисления, которые кладутся в БД. Типа: тип скидки. Купон, Промокод, Акция. Эти штуки жестко закодированы в бизнес-логику все равно и типа не должны меняться на ходу, обычно добавление такой шутки в любом случае повлечет за собой пересборку приложения.
Но если сами эти данные лежат где-то далеко от кода, в CSV/SQL-скрипте/XML, прости господи, то ты будешь вынужден далеко от кода это править, и накосячить с какой-нибудь запятой - проще. Риск того что ты не выдержешь и напишешь в коде вот так: if(Disconunt.Type == "Promo") - возрастает. Вся херну. Потом что-то поменять надо будет - и ты ищи-свищи.
Нахуя ты оправдываешься? В твоём случае работает - могу только порадоваться, позавидовать и пожелать удачи
>В чем я не прав?
>забиваешь и хардкодишь значения перечислений прямо в коде когда лень проверять нормально
Вот в этом.
>>3389876
>ты не выдержешь и напишешь в коде вот так: if(Disconunt.Type == "Promo")
Ну так не делай так.
Ну и как бы вынос справочников за код, подразумевает вынос связывания их с кодом так же наружу (в конфиги или куда-либо еще). Грубо говоря если у тебя добавляется какая-то новая категория, то в код ты просто добавляешь её обработчик как есть, а вот связывание его с категорией (условие вызова) уже должно лежать за кодом (например в конфиге) и вызываться каким-нибудь общим провайдером.
Есть три файла:
main.cs (почти пустой)
fw.cs (class fw помещает файл в public string "contfile" все поля-public)
find.cs (class find в нём метод FindText())
namespace один на всех
Находясь в методе FindText(), я могу создать объект класса "fw", но он не может взять содержимое поля "contfile".
Через МАЙН могу, но нахер мне ООП если как в Си пинать туда-сюда указатели-ссылки, блять!
Думаю что нехватает аналога #include но нигде не нашел ответа. Везде пишут что надо using(namespace) но он один на все файлы.
И самое смИщное, эта ёбаная VS2019 задолбала сообщениями "ваша переменная не используется", а то, что я вышел за пределы массива(string) при поиске подстроки, она нихера не написала. сука.
Классы должны быть каждый в своём файле,и уж не в одной куче в main.cs ну его нахуц.
Я не погрмозд. Вопросы.
Как такое в этих ваших шарпах делается?
Эта штука называется static-переменные. Ничего хорошего в ней нет, сразу нахуй идут и мультитрединг, и тестируемость.
Создавай поле класса и используй его в методах сколько хочешь.
>Вопросы.
Внимательно прочитал твоё сообщение. Могу заключить следующее:
1. Ты не читаешь документацию
2. У тебя кривые руки
3. Ты недостаточно понятно изъясняешься
Таким образом, могу заключить, что ты собрал БИНГО. Тебе нельзя заниматься программированием, у тебя ничего не будет получаться, и это ничем хорошим не закончится.
Вот начал чтобы разобраться пытаться сделать как вижу.
Вышло примерно вот как на прикриплейд. Исходя из охуенной мысли что я зачем-то хочу DI.
Но пока не нравитя то что я роуты явно создаю, думаю добавлю в дальнейшем типа возможность аттрибутом вью-модельке показать какой контрол нужен.
На работе дядька делает не так. Он берет и руками создает инстансы контроллов и вью-моделей, во вью-модели кидает контролл и там его теребит чтобы нужное поведение добиться. Меня это триггерит потому что в моей глупой башке - то что визуальное - должно внутри самого контролла и происходить, а то что типа описывает состояние - во вью-модели. Ну еще это триггерит, потому что он чтобы это все можно было прокидывать дофига статических классов наделал чтобы из любого места куда ему там надо достучаться.
Лазил на гитхаб смотреть как люди-то делают. И вот ну все по разному. Кто-то берет и хуярит все в кодбихаинд. Кто-то делает все вью-модельки синглтонами классическими и через вью-модельки состояния, визуал через контроллы. Кто-то делает что вью-моделей никаких нет...
Я короче не понимаю. Уже спрашивал-то. Но все равно непонятно как-то, как делать десктоп чтобы говной не воняло.
>Я короче не понимаю. Уже спрашивал-то. Но все равно непонятно как-то, как делать десктоп чтобы говной не воняло.
Делай MVVM.
Общие сервисы просто в конструктор инжекти.
Сервисы, которые нужно диспозить, создавай через фабрику, и уничтожай в Dispose родителя
Фабрики руками не пиши, используй какой-нибудь nuget типо FactoryGenerator.Microsoft.Extensions.DependencyInjection
Профи из тебя как из говна котлета.
1 Ты не указал на ошибку
2 От тебя только кукарек, больше ничего.
3 Прекращай дрочить на своё отражение, нарцисс.
4 Читаешь ты жопой - я написал, что не являюсь прогромоздом, и язык C# не знаю.
return смойся в унитаз, не загаживай трэд.
> Но пока не нравитя то что я роуты явно создаю, думаю добавлю в дальнейшем типа возможность аттрибутом вью-модельке показать какой контрол нужен.
Хуйня идея. Вью модельки должны находится в отдельном проекте, который ничего не знает о представлении. Для роутов лучше делать так - берешь имя вью модельки к примеру UserPageViewModel, и в проекте с представлениями ищешь класс с именем UserPage. Я делаю именно так. Максимально ленивый и в то же время хорошо работающий способ. Роуты конечно можно вручную добавлять для экзотических случаев.
>>3390082
> Сервисы, которые нужно диспозить, создавай через фабрику, и уничтожай в Dispose родителя
Хуита, за диспоз должен отвечать IServiceProvider. Условно, тебе нужно навигироваться на страницу, ты в модели представления базовой страницы создаешь Scope, через этот scope получаешь нужную вью модельку, и когда уходишь со страницы просто диспозишь скоп.
И да, роутер не должен никакие зависимости резолвить и вью модели получать. За все это пусть отвечает модель представления в рамках которой осуществлчется навигация. Она создает вью модель, передает ее как аргумент роутеру, и тот уже либо при навигации устанавливает ее в качестве datacontext, либо передает как аргумент в событие onnavigated, если ты пишешь например на uwp/winui/uno, где вместо datacontext в коде создается свойство модели представления и к ней биндятся через x:bind
Ок. Переписал, сделал скриншот.
Какого хера, созданный объект класса (arField) не может взять содержимое поля "filecontent", если и класс и поле "public"?
Создав этот же объект в майне (файл Programm.cs) всё работает, но майн я засерать не хочу. Да и получится тоже самое как в С++ без участия классов (передача кучи параметров в функции).
Если я создам метод "Get" в классе "Archive", то скорее всего смогу получить содержимое поля "filecontent", но поять же почему не работает самый простой вариант?
Искал в инете но аналогов моему не нашел.
Блятьб, это же, сука, самое простое и примитивное решение, какое сразу приходит в голову, хули нет примеров в инете? бесит.
И ещё. Этот код отаботает раз, и я про него забуду на годы, а может навсегда. Ранее мне хватало знаний, что бы без классов решать задачи на С++, но надо будет отправлять запос на Яндекс переводчик (готовый код уже нашел), вот и пришлось писать на шарпе.
>Лазил на гитхаб смотреть как люди-то делают. И вот ну все по разному. Кто-то берет и хуярит все в кодбихаинд. Кто-то делает все вью-модельки синглтонами классическими и через вью-модельки состояния, визуал через контроллы. Кто-то делает что вью-моделей никаких нет...
Ну так каждому свое. Делать "по красоте" слишком напряжно и много костылей нужно. Такое делать если тесты нужны. Но если нет...я тоже как то делал, а потом победил прагматизм.
Вот у меня в итоге ServiceProvider доступен во вьюмоделях (что адски неправильно), мне не нужны фабрики вьюмоделей, а также я везде по вьюмоделям таскаю Context (вот как в андроидах) - чем сразу решаю вопрос принадлежности к окну (у меня классический мультиоконный подход, а не эти ваши смузиебские подобия телеграма. И я могу спокойно показать диалоговое окно, а не еб...я с разными либами и их КОСТЫЛЯМИ, где только ПОТОМ в рантайме узнаешь, вернее НЕ узнаешь, что забыл навесить аттрибут и потому окна с ошибкой нет, а WPF МОЛЧА поглотило исключение.) и с лайфтаймами (а с ним ссылки строгие, никаких weak, которые так любит WPF), никакого роутера в принципе нет, подход ViewModel-First,
Про первую часть сообщения - не согласен.
Ну, т.е. я понимаю аргументы, которые приводятся обычно, но оно разбивается о реальность, в которой даже когда люди по класическом MVVM делают выходит, что каждому вью - идет своя вью-модель, а если что и переиспользуется - оно в сервисах. Я потому и решил, что нехуй выебываться и сделал как на прикриплейд.
Про скоупы - согласен, думаю так и сделаю.
>>3390140
>И да, роутер не должен никакие зависимости резолвить и вью модели получать. За все это пусть отвечает модель представления в рамках которой осуществлчется навигация.
Почему?
Я просто достаточно много писал на JS и конкретно Vue - там роутер сам компонент нужный достает и это было пиздец удобно.
Я хочу именно к такому в конечном итоге прийти. Чтобы на основном окне - просто некий RouterView был, а далее по компонентам вниз можем вложенные роутеры иметь которые другие представления будут возвращать.
Типа как это было в Vue:
<app-layout>
<app-header>
<router-link to="/">Home</router-link>
<router-link to="/About">About</router-link>
</app-header/
<router-view/>
<app-footer/>
</app-layout>
И лично мне это очень даже нравилось.
>вьюмоделям таскаю Context (вот как в андроидах)
Ну и попутно могу организовать общую вьюмодель для какого то графа вьюмоделей и спихнуть туда все команды и при этом не мучиться всякими RealiveSource AncestorLevel
Ну и feature-based подход организации папок, ибо делить на папки View, ViewModels это люто неудобно.
> Ну, т.е. я понимаю аргументы, которые приводятся обычно, но оно разбивается о реальность, в которой даже когда люди по класическом MVVM делают выходит, что каждому вью - идет своя вью-модель, а если что и переиспользуется - оно в сервисах. Я потому и решил, что нехуй выебываться и сделал как на прикриплейд.
Ну вот ты судя по пику пишешь на авалонии, и там вполне обычна ситуация, когда для разных платформ используется разный UI. Не говоря уже о том, что бывают случаи, когда нужно перейти на другой фреймворк, при чем плавно. И в случае если все вью модели в отдельном проекте достаточно просто создать новый проект с нужным фреймворкам и понемногу переносить вьюшки. А если все в одном проекте, то нужно будет копировать всю логику, потом обновлять ее в двух мкстах и тд. К тому же возникает соблазн работать с представлением непосредственно из вью модели.
> Почему?
Потому что если тебе перед навигацией нужно будет как-то подготовить (модель передать, состояния установить и тд) модель представления ты это сделать не сможешь. И вообще в сервисах должен быть принцип единой ответственности.
> Ну и feature-based подход организации папок, ибо делить на папки View, ViewModels это люто неудобно.
Нет, это как раз люто удобно, ибо не приходится гадать, к какой фиче разраб решил отнести свои классы
>ибо не приходится гадать, к какой фиче разраб решил отнести свои классы
Шта?
Хм. Ну, логично. Засчитываю как аргумент. Не привык просто еще к этой всей хурме. Откровенно, пока разбираюсь - все время кажется - проще бы было взять электрон и как привык делать на ЖС.
Ну вот ты видишь в верстке контрол UserView, где будешь его код искать со своим подходом? По классике он всегда будет лежать в папке Views/Controls, а у тебя?
зависит от того, для кого он общий.
Если он общий для всего то UI/Controls/UserView.xaml ибо feature-based не отрицает наличия глобальных общих вещей.
если для фичи (внутри которой может быть много разных подфич), то
UI/Feature/UserView.xaml - ибо это такой же вью как и другие в этой фиче и вложенных (для которых он общий)
UI/Feature/Controls/UserView - если я хочу подчеркнуть что это контрол ака контрол (ну к которому не нужно ожидать вьюмодель). Хотя это подчеркивание лишнее.
UI/Feature/Common/User/UserView - а вот с этим вполне может идти свой вьюмодел и не только. Тут поэтому и выделено в папочку. Но опять же Common вполне себе лишнее.
А потому если там не супер мега убер фича, то будет просто UI/Feature/UserView.xaml
>Какого хера
Такого, что ты творишь какую-то дичь.
Откуда у тебя GetArchive будет знать что ему брать, если ты не передаешь ему ссылку на уже созданный Archive? Ты вместо этого создаешь в нем совершенно новый экземпляр и пытаешься у него достать неинициализированное поле.
Что значит не может, если он берет?
Тебе надо просто понять что такое инкапсуляция и что такое объекты.
Смотри.
Представь, что класс - это инструкция по тому что положить в коробку и как с тем что в коробке лежит работать.
Каждый раз когда ты делаешь new MyClass - компьютер смотрит в эту инструкцию и создает новую коробку, кладет в нее данные, и в соответствии с этой инструкцией - если его попросят что-то сделать - надо сделать это вот так вот.
Так вот. Ты в main - ты создал эту коробочку. Положил в нее данные.
В GetField - ты создал уже новую коробочку. Данные в нее нужные тебе не положил.
Получаешь то поведение что у тебя на скриншоте.
Если тебе надо чтобы GetField возвращал данные - конструктор GetFeild - должен принимать нужный тебе архив, который ты где-то там создашь, так ты всегда будешь иметь возможность получить данные которые в этой коробочке лежат.
Ну. Я старался максимально просто.
Теперь, учитывая что ты там что-то про C/C++ вспомнил.
Вот как ты бы в C работал с какой-нибудь бизнес-сущностью? Ты бы создал структуру, описал ее поля, далее ты бы сделал метод который берет эту структуру и что-то с ней делает.
Банальный пример:
struct Point2i{
int x,
int y
};
Тебе надо сложить значение x и y;
Point2i Sum_Point2i(Point2i a, Point2i b) {
return {a.x + b.x, a.y + b.y };
}
Ну так вот.
Теперь это же но в ООПшном стиле:
public class Point2i {
// поля, которые
public int x;
public int y;
public Point2i(int x = 0, int y = 0) => (this.x, this.y) = (x, y);
// наш метод для работы
public Point2i Sum(Point2i other) {
return new Point2i(x + other.x, y + other.y);
}
}
>Хуита, за диспоз должен отвечать IServiceProvider.
По правилу Тараса Бульбы, кто объект создаёт, тот и отвечает за его уничтожение.
Если ты используешь скоупы, то за уничтожение объектов отвечает скоуп.
Если родительская вью-модель создаёт десяток дочерних, то уничтожением занимается именно родительская вью-модель.
>Условно, тебе нужно навигироваться на страницу
Если у тебя на одной странице одна кнопка, это сработает.
>По правилу Тараса Бульбы, кто объект создаёт, тот и отвечает за его уничтожение.
Тарас Бульба сказал что "диспоз слишком примитивная абстракция пригодная только для простых вещей типа запроса асп.нет" и завещал юзать лайфтаймы, которые суть годнота по одной лишь концепции и не страдают болячками диспоз (а попутно расширяют его ибо не отказываются от него), не говоря уже о прочих плюшках.
> и завещал юзать лайфтаймы, которые суть годнота по одной лишь концепции
Давай под каждую вью-модель по лайвтаймскоупу создавать. Вангую, что бы ебанёшься этим всем управлять уже на втором уровне вложенности
> и не страдают болячками диспоз
Какие болячки, это просто метод
>диспоз слишком примитивная абстракция пригодная только для простых вещей типа запроса асп.нет
Нет, блядь, нужно чтобы объекты создавались ебанутыми конфигурациями автофака, и уничтожались там же, в недрах автофака.
Только потом оказывается, что только один человек понимал, как это всё работает, и он уволился.
На мой взгляд, лучше слишком примитивная абстракция, которую каждого дотнетчика спрашивают на собесе, чем ебля с лайфтаймскоупами, которые, к тому же, прибивают гвоздями приложение к конкретным специфичным фичам одного контейнера.
Для asp.net mvc это похуй, но для графических приложений контейнер это заменяемый компонент. Вот у нас ввиду тысяч регистраций начал тормозить запуск приложения в инициализации DI. Мы написали свой контейнер, и отгребли по полной от того, что нам пришлось реализовывать всю специфику старого контейнера, в том числе каждую деталь процесса уничтожения объектов.
Короче, я для себя решил тогда не ебать себе мозги впредь, и от контейнера расчитывать только на его минимальную функциональность (резолв синглтонов и резолв трансаентов)
Спасибо анон!
Я то думал, открою поля, и с дефолтным конструктором всё заработает, поэтому и не писал его.
Наусложняли зачем то всё.
ВсёОК. Вопрос закрыт.
Давай под каждую вью-модель по лайвтаймскоупу создавать
кричал на площади илья
а люди шли не глядя мимо
но каждый думал а давай )))
не плоди лайфтаймы без надобности (с) Тарас Бульба
>Какие болячки, это просто метод
именно так. всего лишь метод. который
- можно забыть вызвать
- должен трекать то, что в нем должно очищаться. а это еще тот гемор.
(например мы подписываемся отписываемся на события экземпляров - потом разберись кто чего отписать нужно в диспоз).
Не дай бог что то забыть
Ну события шарпа это вообще отдельная песня
- нужно терминировать зависимости. причем в обратном порядке. А зависимость может вообще в конструктор прилететь. Ее терминировать? А если нет, то кто? Тот, кто позвал диспоз? а он вообще не в курсе существования зависимости нашего компонента ибо сам нас в конструктор получил
Вот в WPF поняли что не могут никак гарантировать вызов диспоз и сделали weak события. Наглядный пример слабости этого паттерна.
>>3390338
>создавались ебанутыми конфигурациями автофака, и уничтожались там же, в недрах автофака.
>На мой взгляд, лучше слишком примитивная абстракция, которую каждого дотнетчика спрашивают на собесе, чем ебля с лайфтаймскоупами, которые, к тому же, прибивают гвоздями приложение к конкретным специфичным фичам одного контейнера.
ты просто не пробовал. или пробовал, но ЗАЧЕМ ТО гвоздями прибивал к DI
"Гвоздями" оно прибито только в асп.нет - и то НЕ ПРИБИТО, а просто контейнер используется как лайфтаймвладелец в силу очевидности "когда родили и когда убивать".
Пытаться использовать контейнер как лайфтаймер в десктопе...а зачем вы это делаете?
Время жизни компонента не связано никак с контейнером, да и владелец тоже "тот, кто знает о времени жизни" - а это кто угодно, а не контейнер.
>>3390329 >>3390338
Лайфтаймы это убер годнота по удобству.
- всё живет в каком то лайфтайме. Просто принимаем лайфтайм в конструктор и вешаем на него все наши "нужно убить вместе с нами". Не нужно думать о других.
- подписки тоже с лайфтаймами. автоматически отпишутся
- отлично живет с десктопными вещами, где все существует хрен пойми сколько времени.
- в силу похожести на 90% на CancellationToken (просто семантика другая же, а паттерны похожи как близнецы) то лайфтайм можно передать как токен.
(правда это примитивный лайфтайм. нормальный имеет кучу разных штук типа "запусти операцию и пока она работает не давай терминировать лайфтайм, то есть все компоненты ДОЛЖНЫ жить")
- забыть терминировать гораздо сложнее. Конечно забыть можно всегда, но вызывать явную терминацию лайфтайм нужно редко. Вот о нем и написал в "из неудобств".
Из неудобств - если нужно терминировать дочерние вьюмодели отдельно от родительского лайфтайма, то тут придется делать им отдельные лайфтаймы, чтобы потом отдельно их терминировать.
Из неудобств2.0 - в WPF сложно с ними, потому что WPF задумывался под weak. И контрол, выгружаясь, может просто не сказать что он выгружается. В общем то там решается не слишком сложно. А вот с виртуализацией сложнее - тут контрол НЕ выгружается, а просто меняет DataContext и поэтому нужно менять лайфайтм при смене DataContext
(правда это нужно только тогда если в КОНТРОЛЕ в code-behind нужно на что то подписываться и отписываться (в общем то та же проблема и без лайфтаймов, просто лайфтаймы ее тут не особо решают) - а иначе и проблемы нет)
> Просто принимаем лайфтайм в конструктор и вешаем на него все наши "нужно убить вместе с нами"
вот это слишком туманно написал. Поясню шире
Мы получили лайфтайм в конструктор. И мы
- передаем его в порождаемые вьюмодели, чтобы они попали в тот же лайфтайм, что и мы. Умрем мы - умрут и они. Ни о чьих дочерних диспоз нам думать не нужно. Не нужно следить "кто диспозабле, а кто нет" и "сегодня он вроде нормальный, а завтра стал диспозабле, а нам не сказал, падла"
- подписываемся с найшим лайфтаймом. А значит оно автоматически отпишется. диспоз метод до сих пор не содержит ни строчки кода ибо не существует
- так же можем регистрировать себя в разных там списках с лайфтаймом. Если мы умрем, то будем оттуда автоматически вычищены (хотя лично я такое использовал ни разу ибо хз куда в какие списки пихать вьюмодели, но сама концепция)
- передаем наш лайфтайм как CancellationToken
В итоге у нас 0 строчек кода в методе диспоз. Нас не волнует насколько диспозабле то, что рождаем МЫ САМИ и их изменение. Не волнует порядок терминации (а он должен быть обратным). Ну и наличие коснутрукторов не позволяет нам забыть подумать о времени жизни того, кто требует в себя лайфтайм - то есть если у нас 5 этажей вложенности и на последней вложенности ВДРУГ появилась необходимость метода диспоз, то это будет жопа (которую даже если не забыл решить решать непонятно как).
А с лайфтаймами просто появится в конструкторе параметр и компилятор не даст это собрать пока не решишь проблему.
> можно забыть вызвать
Ты пытаешься объяснить, что есть какой-то чудесный механизм, который управляемые ресурсы сам уничтожает волшебным способом, и сам от событий отписывается. И, главное, сам догадывается, когда это нужно делать.
Сдаётся мне, что ты лукавишь.
> ты просто не пробовал.
Да в том-то им дело, что пробовал. Разгребал восьмилетнюю кодовую базу с вложенными скоупами (это пиздец, если их писал не ты лично). Пробовал сами писать вложенные скоупы. Считаю, что это такая же хуйня как и автомаппер: по началу кажется, что проблемы решает, а на практике получается только хуже.
> В итоге у нас 0 строчек кода в методе диспоз.
Ну давай, попизди мне еще. Коммунизм там, социализм, лайвтаймскоупы все проблемы решают в 0 строчек
>И, главное, сам догадывается, когда это нужно делать.
кто сказал что сам. Конечно же кто то вызывает. Как и с диспоз.
>Разгребал восьмилетнюю кодовую базу с вложенными скоупами
Сдается мне что ты путаешь скоупы от DI с лайфтаймами - это АБСОЛЮТНО РАЗНЫЕ вещи.
лайфтаймы они как браться похоже на CancellationTokenSource с его CancellationToken.
Но ты же почему то их юзаешь и брат жив. А мог бы просто Cancel/Stop каскадно вызывать )
>Ну давай, попизди мне еще. Коммунизм там, социализм, лайвтаймскоупы все проблемы решают в 0 строчек
Именно так. Ты же когда принимаешь CancellationToken и передаешь его дальше, то не сильно волнуешься "ой как бы мне вот эти методы что я вызываю отменять то" - ты просто вешаешь эту задачу на "вот вам токен, он означает КОНЕЦ ВСЕМУ и вы проверяйте или подписывайтесь на него, в общем, сами разберетесь, мое дело передать, как передали мне"
в итоге в твоем коде 0 строчек кода отмены дочерних операций - передал токен и пьешь пиво в бане, а оно работает.
CancellationTokenSource с его CancellationToken можно использовать как готовую либу.
Просто либы для управления лайфтайми все же более семантически заточены под именно это. И там не Cancel, а Terminate, и не Register(метод) (хотя и это есть), а банальное Register(Disposable), ну и терминация в обратном порядке, ну и состояний побольше, а так реально братья по они с CancellationToken
Что ты несёшь? Ты ебанутый? У тебя хоть пример твоей потешной хуеты есть?
могу дать ссылки на видео где о них рассказывается. но это ж время тратить смотреть.
вот чье решение юзаю я (дал тайминг сразу на проблемы диспоза, посмотри минут 10 и познаешь дао. он лучше меня поясняет)
https://www.youtube.com/watch?v=Sq_h5bVWJ0k&t=402s
А так давно еще в одном из этих тредах не поленился написал и выложил пример как с ними жить даже если фреймворк о них не знает. Но то давно было. Ничего не сохранилось.
Есть еще видео на ютубе где челы свою имплементацию lifetime впихивали в MVVM + autofaq и рассказывали как и что.
Это видео не смог сходу найти.
Кек, очередной хер с NIH синдромом решил не разбираться и объявил диспозабл УСТАРЕВШИМ.
И ни разу, блядь такая, не сказал, что этот лайвтайм нужно по цепочке вызовов передавать и создавать количество лайвтаймов по количеству вложенных объектов. А еще дохуя терминологии: Дефинишен, Компонентный дескриптор, лайфтайм, источник, встраивание в IDisposable.
90% разрабов не будут разбираться и просто пальцем у виска покрутят.
Оставшиеся 10% мудаков будут заёбывать всех своими высосанными из пальца проблемами, пока ты им эту серебряную пулю не включишь.
>решил не разбираться
похоже это ты решил не разбираться )
>объявил диспозабл УСТАРЕВШИМ
Ну таков уж Тарас Бульба. Он на порождении и убивстве собаку съел.
>лайвтайм нужно по цепочке вызовов передавать
Нет. лайфтайм принимается в конструктор и передается ровно на один вызов вглубь. Класс, в КОТОРЫЙ его передали имеет свой лайфтайм который и может использоваться внутри себя. Так что никакой передачи по уровням не будет. Всякие специальные вещи типа "своя реализация событий" могут иметь методы принимающие Lifetime (причем они никогда не будут иметь свой ибо это структурные вещи), и то не будут никуда передавать.
А уж обычный код никогда не принимает лайфтайм в свои методы.
>и создавать количество лайвтаймов по количеству вложенных объектов
ты принял CancellationToken в метод и вызываешь 10 методов внутри этого метода. Каждому ты создашь свой CancellationTokenSource?
нет? а почему? ответом на этот вопрос и будет аргументом на твое замечание
>А еще дохуя терминологии: Дефинишен, Компонентный дескриптор, лайфтайм, источник, встраивание в IDisposable
уровень джуна так то.
>90% разрабов не будут разбираться и просто пальцем у виска покрутят.
прямо как ты. решил не разбираться
>всех своими высосанными из пальца проблемами
тебе на видео пояснили проблемЫ паттерна диспозабле. Доходчиво пояснили.
Тебе в WPF пояснили проблему и ввели weak ссылки поэтому.
Поэтому в MVVM фреймворках испоьзуется weak мессенджер ибо нет гарантий отписки.
но ты продолжай верить в непогрешимость IDisposable
так и пиши "многабукав ниасилил".
А всем остальным, кто пишет под десктоп, настоятельно рекомендую посмотреть это видео и не слушать ниассиляторов.
>Каждому ты создашь свой CancellationTokenSource?
Операция одна, а лайвтаймов много.
>тебе на видео пояснили проблемы
Высосали из пальца. Приукрасили. Всё как обычно.
Чел, я не против, что ты всякое мутное говно от джет брейнсов ешь. Но оно не решает никаких проблем
>а лайвтаймов много.
с чего вдруг. Лайфтаймы рождаются по той же самое необходимости что и дочерние CancellationTokenSource - а именно "необходимость отдельно от базового отменить/терминировать дочерние ресурсы".
А это нужно не так уж часто. Тот же запрос в асп.нет кор может принимать в себя хоть 100 зависимостей, но у них один общий лайфтайм.
>Высосали из пальца
да да. конечно из пальца. соглашусь
- забыли вызвать
- вызвать дважды
настолько невозможно забыть вызвать диспоз и вызвать дважды, что
в стандартной доке
https://learn.microsoft.com/ru-ru/dotnet/standard/garbage-collection/implementing-dispose
пишется и про защиту от 2го вызова и про финализатор как защиту от "забыли"
- необходимость складировать диспозабле
очевидно нет никакой проблемы. мало нам хлама от _disposed и методов диспоз и финализатора, еще давайте добавим одну коллекцию. Ну а чего нет.
И в КАЖДОМ таком классе повторим. DRY для лохов
- нужно диспозить в обратном порядке
А чи не насрать? Ну будет исключение, ну WPF проглотит. А вообще проблемы не будет, ведь в MVVM нас просто никто не вызовет диспоз
- кто отвечает за диспоз
Очевидно кто породил тот и отвечает. А вообще кто угодно может - метод то открытый ). Нет никакой проблемы.
забыл еще про ситуацию когда у тебя выполняется какой то код в классе
и в этот момент класс начинает диспозится (а он это может ибо кто то попросил, допустим закрыли окно) и ты такой диспозишь ресурсы, которые как раз нужны в этом выполняемом методе.
И ты такой...ну я добавлю CancellationTokenSource и сделаю ему Cancel первым в моем диспозе. Много методов? много CancellationTokenSource
(ах вот откуда они у тебя плодятся)
А то, что Cancel не останавливает операцию - да просто забудем и всё. Многопоточность это происки дьявола и разбираться в ней грех.
В крайнем случае будет исключение, но уже ж плевать же, ведь окно же закрылось. Ну лог засрем, так кто его читает. Да и вообще писать не будем.
Гладь и тишина.
Нахуя ты мне это пишешь? Ты сектант? Каждый год придумывают мусорные фреймворки, если я о нём до тебя не слышал, это означает, что надо дать ему пару лет настояться.
Если этим мусором никто так и не начнет пользоваться, можно забыть про него как про недоразумение. Потому что проблемы не было
>я о нём до тебя не слышал
и не услышишь. нет таких фреймворков. потому что все они основаны на WPF, в котором главенствует weak подход потому что диспоз паттерн говно.
ну не пользуйся. мне насрать.
Если тебе нравится ковыряться в говне - ну так я не запрещаю.
я уже прямо об этом сказал.
Зато другие поймут, ведь у них нет синдрома утенка и они готовы учиться лучшим подходам, чем существующие.
Я вот не юзаю события стандартные и мне не нужно изобретать решение для многопоточности.
Не юзаю диспоз и мне не нужно изобретать велосипеды для решения проблем (ранее список давал)
а ты можешь гнить в своем болоте, разрешаю.
https://www.youtube.com/watch?v=ZzmK7K2ZIxI
там они впихивали лайфтаймы (своя реализация, без наворотов как у жетбраинс) в автофак с вьюмоделями.
не знаю просто это сложно. Нет никакой сложности использовать лайфтаймы в любом MVVM фреймворке, благо это не супермагическая вещь, а банальный аналог CancellationTokenSource просто с другой семантикой.
Добавляешь в фабрики вьюмоделей параметр Lifetime, заменяешь события на кастомную реализацию с lifetime, DialogService свой (а он всегда свой) тоже подпилить чтобы связать окно и рутовую вьюмодель (и то если нужно). Мессенджер заменить на стронг версию. Можно сделать метод CreateScope с лайфтаймом (ни разу не пригодился, но легко)
ну и один метод расширение для FrameworkElement
и всего делов.
Я без проблем юзал их с CommunityToolkit.
Там больше проблем с банальным MessageBox, а не с лайфтаймами.
Ну а утята пусть продолжают юзать диспозабле и писать гору костылей решая ту же задачу просто криво.
> Говорят
Бабка в автобусе тоже много чего говорит. Проверить сам не можешь?
> Не осилили
Осиль в связном списке доступ к элементам за O(1), тогда и возвращайся.
С языком ты точно ошибся, тебе сюда: >>3375375 (OP)
доступ к любому элементу за один шаг.
ох уж эти современные мидлы
>Нет никакой сложности использовать лайфтаймы в любом MVVM фреймворке, благо это не супермагическая вещь, а банальный аналог CancellationTokenSource просто с другой семантикой.
Я вот уверен, что в любом MVVM фреймворке разработчики обязаны изпользовать MediatR. Потому что он решает все проблемы самого MVVM, в том числе и проблемы уничтожения ресурсов.
Я же не навязываю его тебе? Просто, если мы будем работать вместе, я включу его в проект и объявлю, что по всем законам программирования, в конструктор не должно приходить более трёх зависимостей, одна из которых медиатр, а другая - маппер.
ок. перефразирую. это означает что скорость доступа к элементу всегда такая будто в списке 1 элемент.
>>3390643
>Я вот уверен, что в любом MVVM фреймворке разработчики обязаны изпользовать MediatR
и используют кому надо. Просто MVVM фреймворки они в основном про GUI и вопросов доменной модели не касаются несмотря на буковку M.
Только он не всем подходит ибо имеет склонность рождать хендлеры по запросу. И тогда проще взять MessageBus любой
>в конструктор не должно приходить более трёх зависимостей, одна из которых медиатр, а другая - маппер.
ну если сможешь обосновать какую проблему решает и как без него плохо
с диспозабле и евентами я обосновать могу легко. просто покажу код диспозабле и спрошу как мне не юзать эту портянку, и попрошу организовать вызов его через 4 этажа,как трекать диспозы и так далее.
а еще подключу многопоток в диспозе где ты удивишься
а потом перейдем к событиям и попрошу решить проблему многопотока
и вангую что тут ты пук среньк сделаешь. Да ты уже сделал.
так что крякай дальше, молодой утенок.
Да ты долбоёб, заглотил про медиатор полную хуйню. Я просто случайных слов понпбрал про очередную библиотеку, которую везде пропихивают так же как ты свою хуйню.
ебанашек, у которых Dispose не работает, я, если мягко выражаться, не понимаю.
Иди на хуй, дальше борись с мельницами
>заглотил про медиатор полную хуйню
почему хуйню. я на WPF проекте тоже ее применял. Просто с некоторыми костылями.
>у которых Dispose не работает
диспоз работает. Просто, как ты заметил - ЭТО ПРОСТО МЕТОД
Который даже в базовом варианте требует засирать класс методом, защитой от "забыли", защитой от двойного вызова, трекингом вложенных диспозов
И уж никак не отвечает за вызов диспоза, трекинг снаружи, правильную терминацию
Паттерн говорит буквально - я портянкой защитился КРИВО (ибо защищаться финализатором от "забыли" это решение говно, просто по другому с "это просто метод" никак нельзя) как мог, ибо у меня лапки.
А поэтому в WPF проблема диспоза вьюмоделей решается...барабанная дробь....ОТСУТСТВИЕМ этих самых диспоз и перекладыванием. Вот даже веак евент дали, веак мессенджеры.
А коли ежели тебе хочется таки вызывать диспоз, так MVVM фреймворки этот момент обходят и "ну вы уж сами решайте эти проблемы как хотите"
так что сказать то хотел?
> так что сказать то хотел?
Что хотел - то и сказал.
Дальше просто ржём.
>Что хотел - то и сказал.
ну я увидел пук среньк без аргументации
еще один собрат утенка это тоже увидел
Остальные увидели то же, что я - анона без аргументов и пруфов включившего тупое трололо и такой "хаха смотрите я его триггерю"
но тут техническая борда, а не чатик в доте, поэтому мои аргументы читают И УМНЫЕ люди и узнают что то новое для себя. Так что мне не жалко. Для них и пишу. Не все же были в старых тредах.
Кто то узнает про медиатр и автомаппер, а кто-то про лайфтаймы
не все же молодые крякальщики
так что продолжай ржать. Но...2 утенка никогда не вырастут. Впрочем, небольшая потеря для шарпа.
>ЭТО ПРОСТО МЕТОД
И ОН ПРОСТО РАБОТАЕТ
> Вот даже веак евент дали, веак мессенджеры.
Ты не научился просто на события подписываьтся и объекты вовремя диспозить. Сейчас демонстрируешь, что ты в целом не понимаешь, в чём у тебя проблема, и ищешь решения в какой-то сторонней хуйне.
Что будет с тобой дальше:
1. Твои проблемы не решатся
2. К твоим проблемам добавится еще одна, порождённая дополнительной библиотекой
Чел, я расскажу тебе историю. Был один проект, на котором один челик неправильно понял как CancellationToken работает.
Короче, он заявил, что с текущего момента все должны пользоваться его кенселлейшен токеном (который представлял собой обычный завёрнутый КТ, только обозванный другими словами).
Он окидывал всех величавым взглядом батьки, который в спец кенселляции, и вообще дотнет познал и преисполнился настолько, что может лучше написать. Кодовая база проекта на тот момент 8 лет работала, и на полное переписывание ушло не меньше чем полтора года.
А потом просто хуй забили и продолжили обычным КТ пользоваться
>мои аргументы читают И УМНЫЕ люди
К сожалению, твои аргументы читают умные люди
>И ОН ПРОСТО РАБОТАЕТ
в случает банального using да
вьюмодели в using не запихаешь. подписки в using не запихаешь.
сама необходимость писать диспоз метод, где самому отписывать = закатывать солнце вручную
ну а если твой using забыли использовать - до одного женского органа твой метод диспоз )
>Сейчас демонстрируешь
кроме "ты дурак, я скозал" аргументы будут? нет? ну ок.
>>3390769
и это хорошо. ты себя к ним относишь? можешь дать контраргументы? нет? ну ок
2 чела без аргументов, один с синдромом утенка. спор уровня /b, но не pr
пук сренькайте дальше. мне на работе скучно.
> кроме "ты дурак, я скозал" аргументы будут? нет? ну ок.
да, ты жалуешься на то, что у ВСЕХ работает идеально, на то, с чем ВСЕ разработчики работают годами, и что работает как АК-74.
Ты недовольный нытик, изобретаешь велосипед, который не решает никаких проблем, кроме тех, которые сам же и приносит
>да, ты жалуешься на то, что у ВСЕХ работает идеально
унылые попытки трололо. нужно быть тоньше.
еще аргументы будут? в трололо ты уже слился.
Да нет никакого смысла.
Вот ты, когда посрать хочешь, то наверняка заглядываешь в каждую комнату в доме в поисках унитаза. А потом срешь...тупостью в тред
Лучше бы перекат запилил
>унылые попытки трололо. нужно быть тоньше.
>в трололо ты уже слился.
Я не шутил над тобой, я абсолютно серьёзно писал.
тогда хреново быть тобой если ты на полном серьезе показываешь что ты хреновый программист.
> показываешь что ты хреновый программист.
хули ты разнылся? тебе же никто не запрещает свою хуйню использовать
ты же сам видишь что тут есть любители которые готовы жрать говно только потому что оно РОДНОЕ говно и не хотят учиться альтернативам.
Безусловно. Иди математику подтяни, а то совсем поплыл со своим автомаппером медиатра
конечно без. ведь на мои аргументы никто не смог предоставить ничего кроме "все жрут говно, а ты ерепенишься".
Вот только это не аргумент.
>никто не смог предоставить ничего
Чел, ты пытаешься писать многопоточный код, где у тебя отписка осуществляется не в том потоке, в котором произошла подписка, пытаешься создавать объекты в одном потоке, а уничтожать их в другом:
> а еще подключу многопоток в диспозе где ты удивишься
> а потом перейдем к событиям и попрошу решить проблему многопотока
Что тебе надо "предоставить"? Удостоверение долбоёба?
>аргументы
аргументы блядь у него. Говна понаписал такого, что что с диспоузом не справляешься.
И думаешь, что крутая супер-библиотека за тебя все проблемы решит
>где у тебя отписка осуществляется не в том потоке, в котором произошла подписка
ну как бы в многопоточном коде принятно что все происходит в разных потоках (с) кэп
и если ты думаешь что подписка и отписка в одном потоке решает проблему многопоточности у евентов - вынужден тебя разочаровать. можешь хоть лок навесить.
>Что тебе надо "предоставить"? Удостоверение долбоёба?
ну удостоверение ты уже предоставил. Решение не сможешь ибо НЕ СУЩЕСТВУЕТ универсального решения. Всегда выбор из нескольких стульев из которых что-то торчит. И ты выбираешь то, что тебя меньше травмирует.
Сможешь предоставить универсальное решение многопотока для родных событий шарпа (которые event сахар) - да о тебе сложат легенды.
>>3391203
>что что с диспоузом не справляешься.
А никто не справляется. Об этом даже в офф доке пишут
а) костыли для "забыли" и "вызвали дважды" и это КОСТЫЛИ
б) вообще ни слова о том, кто и как будет обеспечивать "а вы не забывайте", а также "вызывайте вовремя"
>крутая супер-библиотека за тебя все проблемы решит
не все, но большинство
а) НЕ ПОЗВОЛЯЕТ ЗАБЫТЬ. А раз так, то можно смело юзать строг подписки и не бояться.
б) решает проблему двойного вызова
в) решает проблему очередности терминации
г) все отписки происходят когда надо, а не когда GC проснется, что может быть и много времени
д) в основном тебе не нужно вообще думать о вызове терминации. это делается инфраструктурой.
е) код чище. в твоем коде диспоз это редкость. а значит и весь мусор что он привносит - его нет.
В итоге я ШИКАРНО (с) юзаю их в вьюмоделями, тогда как любой MVVM фреймворк мне говорит "придумывай свой лисапед, мы тут за гуи только"
Ты как тот хуй с пробиркой на картинке:
>НЕ ПОЗВОЛЯЕТ ЗАБЫТЬ.
пугает несуществующей проблемой
> решает проблему двойного вызова
нет такой проблемы
> решает проблему очередности терминации
создаёт проблему и тут же её героически решает
> все отписки происходят когда надо, а не когда GC проснется
ты неправильно понял как это работает
> в основном тебе не нужно вообще думать о вызове терминации. это делается инфраструктурой
не пизди
> код чище
слова чище, выразительней, элегантрее - маркер долбоёба
> в твоем коде диспоз это редкость. а значит и весь мусор что он привносит - его нет.
на отладке зашьёшься.
>пугает несуществующей проблемой
>нет такой проблемы
об этих несуществующих проблемах прямо пишется в офф доке
далее можно не читать
уровень ICQ оппонента все уже поняли.
Ты же понимаешь, что это путь в никуда?
>что у тебя многопоток на вью-модельном уровне?
я такого не говорил. Я говорил про лайфайтамы в разрезе вьюмоделей, но это не значит что они только там
Как бы здравый смысл (не ищи что это такое, ты его давно потерял) говорит что вьюмодель не может подписаться на модель с лайфтаймами, если модель не знает про лайфтаймы.
А это значит что лайфтаймы это по все системе где вообще есть понятие время жизни (то есть там где раньше городил костыли с отписками и прочим).
А про события упомянул попутно что сама концепция кривая и что их фтопку решая сразу все их проблемы, в том числе и проблему многопоточности. Никаких event в системе, нигде - они там не нужны ибо убоги и проблемные. Только кастомные реализации принимающие лайфтайм и НЕ имеющие перегрузок без принятия онного. Это ГАРАНТИЯ что не забудут отписаться.
А ты, при добавлении унитаза в комнату, начинаешь всё содержимое из старых комнат в новые комнаты переносить. Лучше что ли?
>вьюмодель не может подписаться на модель с лайфтаймами, если модель не знает про лайфтаймы.
ну то есть, сначала надо всё приложение переписать на лайвтаймы, и может быть тогда они некоторые проблемы снимут?
IDisposableAnalyzers решают всё за 5 минут. Притом бесплатно, и их можно отключить.
> А про события упомянул попутно что сама концепция кривая
тут согласен, события это скорее паттерн, который включать в язык не обязательно было. Но они экономят кучу кода
> Только кастомные реализации принимающие лайфтайм и НЕ имеющие перегрузок без принятия онного. Это ГАРАНТИЯ что не забудут отписаться.
Заставь дурака Богу молиться, он и лоб расшибёт
Только если захотеть поставить унитаз не в свободном месте, а вместо кухонной плиты.
Придёт новый разработчик, нихуя не поймёт и нахуевертит отдельное решение в сторонке.
Проблемы будут расти как сталагмиты из говна, потом эта хуйня пролелет в DI контейнер, потому что удобно же.
Потом пол года переписывать будешь на новую хуйню от джет брейнса, но получится снова говно, и у тебя на руках будет 4 переплетённых пуповинами сиамских близнеца,
Затем ты перестанешь поддерживать код и добавлять фичи потому что будешь думать, что у тебя очень сложное приложение, а на самом деле ты просто не понял как диспозы и события работают
>начинаешь всё содержимое из старых комнат в новые комнаты переносить
есть такая беда, но в иммутабельном списке
в обычном же можно заранее комнату побольше запланировать.
Выделяй комнату размером со вселенную, куда все влезет и сиди себе сри хоть вечно
>всё приложение переписать на лайвтаймы, и может быть тогда они некоторые проблемы снимут?
Как и с другой фундаментальной либой. Чудес не бывает.
Ну на самом деле лайфтайм либа без проблем регистрирует в себя диспозаблы старые. Так что можно спокойно переписывать почуть, начиная с любого уровня. Допустим, у тебя проект использует хуету самописную типа Run/Stop. Тебе ж не сильно будет сложно добавить в этот проект CancellationToken и сразу же пожинать с него плюшки. А какая разница с лайфтаймами? А нет ее
>Но они экономят кучу кода
Это да. Но реализаций разных много - например, можно вернуть диспозабле токен после подписки, а выбрана была именно эта.
>Заставь дурака Богу молиться
да не заставляю я тебя, НЕ ЗАСТАВЛЯЮ. уймись.
Если ты не знаешь что такое концепция fail-fast, то и ладно.
А некоторые вон даже нуллабле в шарпе выставляют настройку "считать ошибкой и не компилироваться"
>>3391462
>Придёт новый разработчик, нихуя не поймёт
Ну если разработчик не может понять концепцию которая на 99% идентична концепции CancellationToken, то такой разработчик и не нужен. Даже в том же видео от жебтраинс про саму суть лайфтаймов всего 15 минут, а остальное про всякие хитрости типа битовых полей, оптимизаций, лог-фасад и так далее.
>просто не понял как диспозы
вернее отлично понял как они работают. И что они вполне допустимы в using (хотя по прежнему реализация диспоз это трехэтажный защитный монстр, но если уж он написан то ладно, не моя проблема же его писать), но если using невозможен, то значит нужно городить костыль по трекингу диспозов и их вызову, да и не забыть, да и вообще сгородить (а с в WPF это не просто) - проще взять готовое решение, решающее эти проблемы, которые диспоз не решает вообще - он же просто метод и не занимается проблемами его вызова
>IDisposableAnalyzers решают всё
да да. свежо предание....
он даже в гифке вон диспозит стрим, что в конструктор получил. А потом клиент этого Фуу класса с удивлением получит исключение что стрим сдох и такой "какого хе..."
Этот анализатор может помочь частично сгенерить метод диспоз
но никак не решает проблему вызова этого самого диспоз.
ну а про отписку событий там вообще не видать. Да и не всегда отписка это именно диспоз. Это может быть Un/Deregister или еще чего то. Никакой анализатор не увидит в нем диспозабле ибо его там попросту нет. И конечно же не добавит его в диспоз метод ибо откуда ему знать об этом. То есть опять же разраб должен сам трекать и не забывать отписываться/закрывать ручками даже с этим анализатором.
с лайфтаймами метод диспоз существовать не будет вообще и трекать ничего не надо.
Далеко ходить не нужно. Модерновая типа "стандарт" либа communitytoolkit в своем StrongReferenceMessenger (с weak все понятно - там в принципе нет отписок) имеет метод Unregister
поможет тебе твой анализатор с этим методом? вопрос риторический. А как он затрекает "подписался отписался снова подписался снова отписался"? вопрос риторический
1: приемлемо для словаря сделать #pragma warning disable или лучше дописать where T : notnull и в методах заменить Т на Т? ?
2: опять же #pragma warning disable или менять Т на Т? ?
Сделать #nullable disable понятно, но хочется разобраться с enable.
Ты долбоёб, конечно. Не смог в простых вещах разобраться, полез заниматься сложными. Скорее всего тебе очень тяжело программировать, а твой характер заставляет делать тебя хуйню. Поздравляю, у тебя БИНГО
>сложными
аналог CancellationToken
да. это очень очень очень сложно.
>в простых
каждый пишет кучу говнокода внутри диспозабле классов и кучу снаружи. При этом дополнительно велосипед для вызова диспоз не из метода диспоз.
ну это просто
>Скорее всего тебе очень тяжело программировать,
не без этого. знаю много языков ( и бесит когда простое в одном языке нужно делать через жопу в другом.
поэтому на шарп я в этом треде бочку качу много
но это не по теме.
Хочу наверстать Шарп и стать уверенным хотя бы джуном, а лучше джуном с плюсиком. Как быть? Какие книги/курсы можете порекомендовать? Сижу дома, могу фуллтайм учиться.
Спасибо всем, кто отзовется. Меньше вам страшного легаси кода в жизни и сломанных билдов.
1 pragma warning disable используют только пидарасы. Для нормальных людей такое допустимо только в автогенеренном коде, и только если эти директивы расставляются самим же генератором.
2 не пихать в сет default, а придумать для этого уникальный объект, который будет маркером для null. Да и вообще отказаться от использования null в качестве объекта в остальном коде.
>есть такая беда, но в иммутабельном списке
>в обычном же
Я так и не пойму, список там или всё же массив?
>2 не пихать в сет default, а придумать для этого уникальный объект, который будет маркером для null.
А если это сферовакуумный дженерик, как Dictionary?
>1 pragma warning disable используют только пидарасы.
Один раз... Это же в nullable контексте?
Что насчёт этого https://stackoverflow.com/questions/74544989/creating-dictionary-with-potentially-nullable-generic-key-type#comment131589586_74544989 ?
Что скажешь о заворачивании во что-то типа Nullable<>? Просто кажется, что это слишком дохуя, когда можно просто #pragma warning dis... ээ...
Алсо, если потом создать инстанс как G<MyClass?>, то ведь правильно будет ожидать, что он не только принимает null, но и возвращает, особенно если это некая коллекция без органичений T.
Экскузи муа за дохуя сумбурных вопросов, но как-то всё кажется неоднозначным.
не парься. шарп плохо обрабатывает T? так что смело прагмируй если он тупит и ну прямо никак.
Спасибо. Пробежался быстро по сайту, вроде действительно годно как справочник, вспомнить синтаксис и базовые понятия. Немного стремно, что нет понимания, кто составлял тексты и редактировал (вдруг там неверные знания или плохие практики?) Буду параллельно сверяться с какой-нибудь книгой, для внутреннего спокойствия.
> 1 pragma warning disable используют только пидарасы. Для нормальных людей такое допустимо только в автогенеренном коде, и только если эти директивы расставляются самим же генератором.
Спешите видеть, дурачок возомнил себя программистом и с уверенным видом вещает, что можно, а что нельзя использовать.
Знаю что нужно сделать интерфейс, чтобы функции команд реализовывали его, а так же изменить info на более общий класс, который хранит целое сообщение, а не только текст от него
https://pastes.io/bot-template
придет время и ты сразу будешь делать
- DI
- конфиг
- логгер
и т.д.
Запихнешь бота в сервис который и построишь через DI, а команды в хендлеры, которые классы и чтобы они авторегистрировались, а не словарик.
будет работать точно так же, но выглядеть наворочено )
>что можно, а что нельзя использовать
Где в моей фразе хоть слово про 'можно' и 'нельзя'?
ну может тебе и можно быть пидорасом, но другим все же нельзя
вот тебе ответ где там слово "нельзя"
А ещё будет добавлять медиатор, автомаппер и флюент валидатор.
И БУДЕТ ПРАВ.
я помню себя. тоже такой. блин пишу мелочь, нафига мне все эти дизайны и архитектуры, всё можно в Program.cs сделать.
А потом мелочь как начала расти да пришлось переделывать с нуля в итоге по нормальному.
Пары раз хватило и я теперь не выделываюсь, а сразу делаю как надо.
Что-то время идёт и всё не начинаю это делать. Как начать это всё осваивать? Переделать ту программу которую скинул, используя все эти интересные технологии. У ии что-ли спросить...
да. переделай. привыкай сразу к дизайну "все лежит в положенном для него месте".
сделай "по красоте"
заведи DI
заведи services.RegisterHandlers который все найдет и запихает в контейнер.
После этого ты изи сможешь получить в хендлере и сервисе что тебе нужно банально прописав в конструкторе
Искусство рефакторинга - важнейшее из искусств. Так еще сын Тараса Бульбы говорил, за что и был убит.
>>3391996
>А вот это вот нахуй не нужно в 99% случаев
согласен. это в 99% случаев не нужно кроме как именно сразу нужно. еще остается 20% когда реально не нужно
>по нормальному.
Начни с подключения JetBrains.Lifetimes и разбиения кода на гексоганальный CQRS.
Не забудь захватить чистую архитектуру и отличное настроение!
от JetBrains.Lifetimes всегда отличное настроение. Я ж не просто так тут столько постов написал какое оно шикарно (с)
>Сейчас .NET Full Stack джуны нахуй не сдались что-ли?
Всем нужны хорошие бэкендеры, которых периодически пытются припрячь к выполнению фронтовых задач. Слабые духом сдаются, сильные - посылают нахуй такие инициативы.
Фулкекеры - это сейчас оверхед. В среднем на команду из 4..6 беков приходится вчсего 1..2 фронтендера. При таких вводдных узкоспециализированные специ выгоднее универсальных, просто потому что в своей области они будут эффективнее.
Да, сам всегда так думал и пока дрочил без конца бек от фронта плевался, но сейчас пока в процессе вката начал писать проекты пришлось базово осваивать HTML CSS JS чтобы хоть какой-то UI был и AJAX, конкретно .NET в Full Stack видел куда чаще остальных (мб хуево смотрел)
Но и на чистый бек я тоже вакансий пока не нашел чтоб удалёнка без опыта
1 подготавливаешь перекат
2 перекатываешь
3 пишешь в старом треде что перекатил
почему с# - лучший язык?
>Перекати тред
Я сюда первый раз зашел за все время своего капчевания с 2012 года. Где тутошние усачи-перекатчики? Да и в тематике бумп-лимит навроде 2к постов?
Ваш тред недостоин переката. Как ни спросишь что-нибудь - то либо игнорят, либо паясничают.
Перекот --> >>3395748 (OP)
Перекот --> >>3395748 (OP)
Перекот --> >>3395748 (OP)