Этого треда уже нет.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
392 Кб, 1000x1000Прошлый тред: ???
Литература вторым постом
1. Ресурсы:
— https://dotnet.microsoft.com/learn
— https://docs.microsoft.com/ru-ru/dotnet/csharp/
— https://metanit.com/
2. Онлайн-компиляторы:
— https://ideone.com/
— https://dotnetfiddle.net/
3. WinForms или WPF?
Зависит от задачи. Для небольших проектов, скорее всего, будет достаточно винформочек. В случае, если разрабатываемое приложение достаточно серьёзное, то возможно его стоит писать с использованием WPF. WPF очень хорошо работает с паттерном MVVM ( https://ru.wikipedia.org/wiki/Model-View-ViewModel ), и позволяет пилить очень кастомизированные интерфейсы с помощью XAML, что в случае с WinForms делать намного сложнее.
4. Мне тут знакомый_нейм сказал, что C# умирает, это правда? Может не стоит его учить?
Неправда. C# активно развивается, недавно вышел .NET 5 и С# 9.0. Дотнет стал полностью опенсорсным и кроссплатформенным. В том же энтерпрайзе он очень даже востребован.
5. Какую IDE выбрать?
Для Windows самым очевидным вариантом будет Visual Studio ( https://visualstudio.microsoft.com/ru/downloads/ ). Бесплатной Community-версии более, чем достаточно для большинства задач. Также есть версия для macOS.
Кроссплатформенный полуредактор/полуIDE VS Code ( https://code.visualstudio.com/ ).
Кроссплатформенный IDE Rider ( https://www.jetbrains.com/rider/ ).
Также существуют C#-плагины для Atom и Sublime Text, но функциональность там достаточно сильно урезана.
6. С# для мобильной разработки
https://dotnet.microsoft.com/apps/xamarin
Новые возможности C# 9.0: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/
Текст шапки: https://pastebin.com/pbK8CGqw
======= ВТОРОЙ ПОСТ =======
7. Что почитать?
— The C# Player's Guide, третье издание (RB Whitaker) — отличная книга для ньюфагов, всё расписывается довольно подробно, очень много примеров кода.
— C# 9 and .NET 5 – Modern Cross-Platform Development (Mark Price) — подойдёт для ознакомления с платформой. Затрагивает все технологии, имеющиеся в .NET (веб, мобильная разработка, машинное обучение), ни во что не углубляясь.
— C# 8.0 in a Nutshell (Joseph Albahari и Eric Johannsen) — огромнейший справочник, over 1000 страниц, покрывает почти все области, начиная с синтаксиса и базовых типов и заканчивая интеропом и рослином.
— C# 8.0 Pocket Reference (Joseph Albahari и Ben Albahari) — просто выжимка из книги сверху, можно всегда держать рукой.
— Pro C# 8 with .NET Core 3 (Andrew Troelsen) — 1600-страничный учебник по шарпу, покрывает BCL, WPF и ASP.NET, небо и даже аллаха.
8. Более хардкорный материал
— CLR via C# (Jeffrey Richter) — это классика, это знать надо.
— C# in Depth (Jon Skeet) — написана в виде истории версий C#, начиная с C#1.0. Описываются возможности, которые были добавлены в определенной версии и далее достаточно хардкорно и подробно эти возможности расписываются.
— Writing High Performance .NET Code (Ben Watson) — отличная книга. Фокусируется на методах оптимизации приложений, профилировании. Крутейшая и достаточно детальная глава по GC. Рассматриваются достаточно известные проблемы вроде "for vs foreach", "класс vs структура", кастинг, боксинг, перфоманс регулярок, коллекций, исключений. Короче всё, что нужно, чтобы вам перезвонили.
9. Литература по WPF
— Pro WPF 4.5 in C# (Matthew MacDonald)
— Windows Presentation Foundation 4.5 Cookbook (Pavel Yosifovich)
10. Литература по ASP.NET
— Pro ASP.NET Core 3 (Adam Freeman)
— Professional ASP.NET MVC 5 (Jon Galloway, Brad Wilson, K. Scott Allen, David Matson)
11. Литература по асинхронности и параллелизму
— Concurrency in C# Cookbook (Stephen Cleary) — книга, написанная в формате "проблема - решение". Кроме базовых вещей, вроде асинков и параллелизма рассматриваются TPL Dataflows, Rx (реактивные расширения), тестирование всего этого асинхронного добра, ну и работа этого всего на более низких уровнях абстракции.
— Multithreading with C# Cookbook (Eugene Agafonov) — в основном ничего интересного, но есть довольна неплохая глава про синхронизацию, пусть и не слишком детальная.
— Pro Asynchronous Programming with .NET (Richard Blewett, Andrew Clymer) — опять же, интересного немного, но неплохие главы про асинхронность + UI и анализ дампов памяти в windbg.
12. Литература по мобильной разработке
— Creating Mobile Apps with Xamarin.Forms (Charles Petzold)
— Xamarin.Forms Projects (Johan Karlsson, Daniel Hindrikes)
— Mastering Xamarin.Forms (Ed Snider)
13. Литература по машинному обучению
— Introduction to Neural Networks for C# (Jeff Heaton) — изучение нейронных сетей с примерами кода на шарпе. Под конец пишем программу для распознавания символов и нейроботов.
— Machine Learning Using C# Succinctly (James D. McCaffrey) — довольная коротенькая книга на тему машинного обучения с примерами кода на C#. Ничего особого: k-средние, классификация, наивный байес, но с кодом, который всегда можно поразбирать, если что неясно.
14. Разработка игр
Unity-тред в /gd/
15. Но я не знаю английский, как я буду это все читать?
На некоторые из перечисленных книг есть переводы, которые можно найти на том же рутрекере, однако зачастую эти переводы неактуальны и/или содержат неточности. Кроме того, переводы обычно пилятся только для нескольких самых популярных книг, более-менее серьёзный материал не переводят. Всегда можно сесть со словарем и понемногу читать, переводя непонятные фрагменты. Это очень полезно, так как в любом случае в программировании без знания английского делать нечего. Если очень хочется, то гуглить по запросам: "C# 7.0. Справочник. Полное описание языка", "C# для профессионалов. Тонкости программирования", "Программирование на платформе Microsoft .NET Framework 4.5 на языке C#".
16. Что еще нужно знать, чтобы взяли работать за еду?
— Базы данных — подойдет любая книга по MSSQL/MySQL/PostgreSQL. DDL, DML. Джойны, индексы, нормализация. В контексте шарпа еще ORM: Entity Framework, Dapper.
— Системы контроля версий — обычно гита достаточно: add/commit/push, merge, rebase, checkout, remote, diff, разрешение конфликтов.
— GitHub — issues, пулл-реквесты, теги, релизы, Actions.
— Алгоритмы — сортировка, поиск, оценка сложности алгоритмов, рекурсия, алгоритмы на строках.
— Структуры данных — связанные списки, деревья (бинарные, красно-чёрные, b-деревья), хеш-таблицы, графы.
— Если идти в веб — HTML, CSS, JavaScript, веб-сокеты, REST, JS-фреймворки (Angular, React, Vue).
— Паттерны проектирования, стиль кода, архитектура приложения, внедрение зависимостей, MVVM (если хочется в WPF), SOLID.
17. Я не умею читать, что посмотреть?
— C# Fundamentals: Development for Absolute Beginners — https://goo.gl/meyyxO
— Набор курсов по C# от O'Reilly Media (28 часов, на английском) — http://rutracker.org/forum/viewtopic.php?t=5082978
— Канал по C# IAmTimCorey (на английском) — https://www.youtube.com/user/IAmTimCorey
Литература вторым постом
1. Ресурсы:
— https://dotnet.microsoft.com/learn
— https://docs.microsoft.com/ru-ru/dotnet/csharp/
— https://metanit.com/
2. Онлайн-компиляторы:
— https://ideone.com/
— https://dotnetfiddle.net/
3. WinForms или WPF?
Зависит от задачи. Для небольших проектов, скорее всего, будет достаточно винформочек. В случае, если разрабатываемое приложение достаточно серьёзное, то возможно его стоит писать с использованием WPF. WPF очень хорошо работает с паттерном MVVM ( https://ru.wikipedia.org/wiki/Model-View-ViewModel ), и позволяет пилить очень кастомизированные интерфейсы с помощью XAML, что в случае с WinForms делать намного сложнее.
4. Мне тут знакомый_нейм сказал, что C# умирает, это правда? Может не стоит его учить?
Неправда. C# активно развивается, недавно вышел .NET 5 и С# 9.0. Дотнет стал полностью опенсорсным и кроссплатформенным. В том же энтерпрайзе он очень даже востребован.
5. Какую IDE выбрать?
Для Windows самым очевидным вариантом будет Visual Studio ( https://visualstudio.microsoft.com/ru/downloads/ ). Бесплатной Community-версии более, чем достаточно для большинства задач. Также есть версия для macOS.
Кроссплатформенный полуредактор/полуIDE VS Code ( https://code.visualstudio.com/ ).
Кроссплатформенный IDE Rider ( https://www.jetbrains.com/rider/ ).
Также существуют C#-плагины для Atom и Sublime Text, но функциональность там достаточно сильно урезана.
6. С# для мобильной разработки
https://dotnet.microsoft.com/apps/xamarin
Новые возможности C# 9.0: https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/
Текст шапки: https://pastebin.com/pbK8CGqw
======= ВТОРОЙ ПОСТ =======
7. Что почитать?
— The C# Player's Guide, третье издание (RB Whitaker) — отличная книга для ньюфагов, всё расписывается довольно подробно, очень много примеров кода.
— C# 9 and .NET 5 – Modern Cross-Platform Development (Mark Price) — подойдёт для ознакомления с платформой. Затрагивает все технологии, имеющиеся в .NET (веб, мобильная разработка, машинное обучение), ни во что не углубляясь.
— C# 8.0 in a Nutshell (Joseph Albahari и Eric Johannsen) — огромнейший справочник, over 1000 страниц, покрывает почти все области, начиная с синтаксиса и базовых типов и заканчивая интеропом и рослином.
— C# 8.0 Pocket Reference (Joseph Albahari и Ben Albahari) — просто выжимка из книги сверху, можно всегда держать рукой.
— Pro C# 8 with .NET Core 3 (Andrew Troelsen) — 1600-страничный учебник по шарпу, покрывает BCL, WPF и ASP.NET, небо и даже аллаха.
8. Более хардкорный материал
— CLR via C# (Jeffrey Richter) — это классика, это знать надо.
— C# in Depth (Jon Skeet) — написана в виде истории версий C#, начиная с C#1.0. Описываются возможности, которые были добавлены в определенной версии и далее достаточно хардкорно и подробно эти возможности расписываются.
— Writing High Performance .NET Code (Ben Watson) — отличная книга. Фокусируется на методах оптимизации приложений, профилировании. Крутейшая и достаточно детальная глава по GC. Рассматриваются достаточно известные проблемы вроде "for vs foreach", "класс vs структура", кастинг, боксинг, перфоманс регулярок, коллекций, исключений. Короче всё, что нужно, чтобы вам перезвонили.
9. Литература по WPF
— Pro WPF 4.5 in C# (Matthew MacDonald)
— Windows Presentation Foundation 4.5 Cookbook (Pavel Yosifovich)
10. Литература по ASP.NET
— Pro ASP.NET Core 3 (Adam Freeman)
— Professional ASP.NET MVC 5 (Jon Galloway, Brad Wilson, K. Scott Allen, David Matson)
11. Литература по асинхронности и параллелизму
— Concurrency in C# Cookbook (Stephen Cleary) — книга, написанная в формате "проблема - решение". Кроме базовых вещей, вроде асинков и параллелизма рассматриваются TPL Dataflows, Rx (реактивные расширения), тестирование всего этого асинхронного добра, ну и работа этого всего на более низких уровнях абстракции.
— Multithreading with C# Cookbook (Eugene Agafonov) — в основном ничего интересного, но есть довольна неплохая глава про синхронизацию, пусть и не слишком детальная.
— Pro Asynchronous Programming with .NET (Richard Blewett, Andrew Clymer) — опять же, интересного немного, но неплохие главы про асинхронность + UI и анализ дампов памяти в windbg.
12. Литература по мобильной разработке
— Creating Mobile Apps with Xamarin.Forms (Charles Petzold)
— Xamarin.Forms Projects (Johan Karlsson, Daniel Hindrikes)
— Mastering Xamarin.Forms (Ed Snider)
13. Литература по машинному обучению
— Introduction to Neural Networks for C# (Jeff Heaton) — изучение нейронных сетей с примерами кода на шарпе. Под конец пишем программу для распознавания символов и нейроботов.
— Machine Learning Using C# Succinctly (James D. McCaffrey) — довольная коротенькая книга на тему машинного обучения с примерами кода на C#. Ничего особого: k-средние, классификация, наивный байес, но с кодом, который всегда можно поразбирать, если что неясно.
14. Разработка игр
Unity-тред в /gd/
15. Но я не знаю английский, как я буду это все читать?
На некоторые из перечисленных книг есть переводы, которые можно найти на том же рутрекере, однако зачастую эти переводы неактуальны и/или содержат неточности. Кроме того, переводы обычно пилятся только для нескольких самых популярных книг, более-менее серьёзный материал не переводят. Всегда можно сесть со словарем и понемногу читать, переводя непонятные фрагменты. Это очень полезно, так как в любом случае в программировании без знания английского делать нечего. Если очень хочется, то гуглить по запросам: "C# 7.0. Справочник. Полное описание языка", "C# для профессионалов. Тонкости программирования", "Программирование на платформе Microsoft .NET Framework 4.5 на языке C#".
16. Что еще нужно знать, чтобы взяли работать за еду?
— Базы данных — подойдет любая книга по MSSQL/MySQL/PostgreSQL. DDL, DML. Джойны, индексы, нормализация. В контексте шарпа еще ORM: Entity Framework, Dapper.
— Системы контроля версий — обычно гита достаточно: add/commit/push, merge, rebase, checkout, remote, diff, разрешение конфликтов.
— GitHub — issues, пулл-реквесты, теги, релизы, Actions.
— Алгоритмы — сортировка, поиск, оценка сложности алгоритмов, рекурсия, алгоритмы на строках.
— Структуры данных — связанные списки, деревья (бинарные, красно-чёрные, b-деревья), хеш-таблицы, графы.
— Если идти в веб — HTML, CSS, JavaScript, веб-сокеты, REST, JS-фреймворки (Angular, React, Vue).
— Паттерны проектирования, стиль кода, архитектура приложения, внедрение зависимостей, MVVM (если хочется в WPF), SOLID.
17. Я не умею читать, что посмотреть?
— C# Fundamentals: Development for Absolute Beginners — https://goo.gl/meyyxO
— Набор курсов по C# от O'Reilly Media (28 часов, на английском) — http://rutracker.org/forum/viewtopic.php?t=5082978
— Канал по C# IAmTimCorey (на английском) — https://www.youtube.com/user/IAmTimCorey
Сажи петушиному треду.
133 Кб, 658x658Перекатился в няшный тред няшного языка.
Заодно реквестирую рулетку проектов, либо идеи, что запилить такого интересного и чтобы на собесе не стыдно показать было.
Заодно реквестирую рулетку проектов, либо идеи, что запилить такого интересного и чтобы на собесе не стыдно показать было.
>>63714
Вот тебе идея.
Шифрованный блокчнйн чатик с рейтингом, который начисляется за количество друзяшек что ты привел и твою+их активность. Рейтинг можно тратить на то чтобы открывать внутренние функции, типа замутить мудака, сделать текст красненькими и т.д.
Ну, суть я думаю ясна, система строится по принципу финансовой пирамиды, но в которой все в выигрыше: приводишь друзяшек и часть их рейтинга тебе, они приводят своих и они получают рейтинг, а ты получаешь рейтинг который получили те кто привел. Рейтинг можно передавать друг-другу. При этом его нельзя купить за реал, такая-то внутренняя валюта, но, опять же, при остром желании и вере во все это - люди могут организовать так вот платежи.
Базарю 11/10 идея, все будут течь как суки, а к тебе не докапаются просто так.
Когда первый миллион заработаешь - отсыпь мне процентов 10.
Вот тебе идея.
Шифрованный блокчнйн чатик с рейтингом, который начисляется за количество друзяшек что ты привел и твою+их активность. Рейтинг можно тратить на то чтобы открывать внутренние функции, типа замутить мудака, сделать текст красненькими и т.д.
Ну, суть я думаю ясна, система строится по принципу финансовой пирамиды, но в которой все в выигрыше: приводишь друзяшек и часть их рейтинга тебе, они приводят своих и они получают рейтинг, а ты получаешь рейтинг который получили те кто привел. Рейтинг можно передавать друг-другу. При этом его нельзя купить за реал, такая-то внутренняя валюта, но, опять же, при остром желании и вере во все это - люди могут организовать так вот платежи.
Базарю 11/10 идея, все будут течь как суки, а к тебе не докапаются просто так.
Когда первый миллион заработаешь - отсыпь мне процентов 10.
303 Кб, 637x507бамп треду
Где прочитать про организацию своего собственного проекта?
Найдя dotnet и отвязавшись от ёбаной визуал студии я почувствовал частичку свободы, но и тут я сука должен создавать какой-то проект по каким-то шаблонам, которые за меня создают какие-то файлы в папке, какие-то конфигурации, которые я сам не писал и которые я нихуя не понимаю
Найдя dotnet и отвязавшись от ёбаной визуал студии я почувствовал частичку свободы, но и тут я сука должен создавать какой-то проект по каким-то шаблонам, которые за меня создают какие-то файлы в папке, какие-то конфигурации, которые я сам не писал и которые я нихуя не понимаю
>>64285
Как тебе удобно, так и организуй. Я вот, обычно, в каждом проекте - хуячу в корень.
Решение выглядит примерно так:
App
+App.sln
+docs
+docker-compose.yaml
+.gitignore
+-builds
+-Proj1
+--...
+--Proj1.csporj
+-Proj2
+--...
+--Proj2.csporj
+-Proj3
+--...
+--Proj3.csporj
Но это в моих проектах. На работе деды привыкли к тому что в решении один здоровенный проект и все по папочкам.
Как тебе удобно, так и организуй. Я вот, обычно, в каждом проекте - хуячу в корень.
Решение выглядит примерно так:
App
+App.sln
+docs
+docker-compose.yaml
+.gitignore
+-builds
+-Proj1
+--...
+--Proj1.csporj
+-Proj2
+--...
+--Proj2.csporj
+-Proj3
+--...
+--Proj3.csporj
Но это в моих проектах. На работе деды привыкли к тому что в решении один здоровенный проект и все по папочкам.
>>64560
Я имел в виду, как разобраться со всеми конфигами...
Бля хуёво объясняю, поясню на примере Си. Там всё похуй, я могу создать папку, в неё положить файл, рядом написать простенький Makefile и всё это скомпилируется.
Можно ли тут сделать похожим образом и, если можно, то как?
Я имел в виду, как разобраться со всеми конфигами...
Бля хуёво объясняю, поясню на примере Си. Там всё похуй, я могу создать папку, в неё положить файл, рядом написать простенький Makefile и всё это скомпилируется.
Можно ли тут сделать похожим образом и, если можно, то как?
Поясните по поводу DI
Как по уму делают
Вот у меня есть приложение на впф
Есть главное окно ему соотвествует MainViewModel
В этом окне хостится контрол которому соотвествует ViewModel1
В этом контроле есть боковая панель которой соотвествует ViewModel2
На этой панели есть комбобокс которым можно внутри панели перключать контролы каждому отображению тоже соотвествует своя Viemodel
то есть вложенность такая MainViewModel => ViewModel1 => ViewModel2 => Viewmodel2.1 и т д
Так вот вот этой Viewmodel2.1 нужен некий сервис чтобы выполнить комнаду
Как его прокинуть?
С главного окна тянуть через 3 вьюмодели ради четвертой вьюмодели?
У нас работе все ебашут через сервислокатор и в ус не дуют, ну я чтобы не выделяться тоже в конструктор через сервислокатор получил нужный сервис и все норм.
Как по уму делают
Вот у меня есть приложение на впф
Есть главное окно ему соотвествует MainViewModel
В этом окне хостится контрол которому соотвествует ViewModel1
В этом контроле есть боковая панель которой соотвествует ViewModel2
На этой панели есть комбобокс которым можно внутри панели перключать контролы каждому отображению тоже соотвествует своя Viemodel
то есть вложенность такая MainViewModel => ViewModel1 => ViewModel2 => Viewmodel2.1 и т д
Так вот вот этой Viewmodel2.1 нужен некий сервис чтобы выполнить комнаду
Как его прокинуть?
С главного окна тянуть через 3 вьюмодели ради четвертой вьюмодели?
У нас работе все ебашут через сервислокатор и в ус не дуют, ну я чтобы не выделяться тоже в конструктор через сервислокатор получил нужный сервис и все норм.
8 Кб, 615x199>>64581
С какими конкретно-то конфигами?
Если ты про аналог Make - то для шарпов сейчас - все описывается в XML-like файле csproj(прикриплейд). В нем ты прописываешь тип проекта, версию фреймворка, все остальное, затем можешь собрать тем же dotnet cli. Студия использует этот же формат, просто в ней у тебя отрисуется окошко, если просто кликнешь свойства, чтобы открыть этот файл и руками поковыряться - два раза кликаешь и вот он будет.
Из основных штук которые нужны для начала - в нем указывается тип SDK, версия фреймворка, тип сборки и ссылки. Остальные штуки уже по ходу сможешь гуглить и рахзбираться, потому что тут довольно много всякой хуйни и заучивать ее особого смысла нет.
Если у тебя есть dotnet cli - ты просто открываешь папку с проектом и пишешь dotnet run - все соберется и положится в папочку bin.
С какими конкретно-то конфигами?
Если ты про аналог Make - то для шарпов сейчас - все описывается в XML-like файле csproj(прикриплейд). В нем ты прописываешь тип проекта, версию фреймворка, все остальное, затем можешь собрать тем же dotnet cli. Студия использует этот же формат, просто в ней у тебя отрисуется окошко, если просто кликнешь свойства, чтобы открыть этот файл и руками поковыряться - два раза кликаешь и вот он будет.
Из основных штук которые нужны для начала - в нем указывается тип SDK, версия фреймворка, тип сборки и ссылки. Остальные штуки уже по ходу сможешь гуглить и рахзбираться, потому что тут довольно много всякой хуйни и заучивать ее особого смысла нет.
Если у тебя есть dotnet cli - ты просто открываешь папку с проектом и пишешь dotnet run - все соберется и положится в папочку bin.
>>64622
В классе Program - хуйни статичное ридонли свойство и к нему обращайся.
А вообще я нихуя не понял в чем твоя проблема. Твой MainViewModel если зависим от ViewModel1 и ViewModel2 - должен просто в конструкторе получать интерфейсы IViewModel1 и IViewModel2 и ничего знать про то как они сконфигурированны знать не должен, в свою очередь конкретные их реализации ты можешь собирать где и как хочешь, прокидывая нужные тебе сервисы прямо в них, а не таща через всю иерархию.
В классе Program - хуйни статичное ридонли свойство и к нему обращайся.
А вообще я нихуя не понял в чем твоя проблема. Твой MainViewModel если зависим от ViewModel1 и ViewModel2 - должен просто в конструкторе получать интерфейсы IViewModel1 и IViewModel2 и ничего знать про то как они сконфигурированны знать не должен, в свою очередь конкретные их реализации ты можешь собирать где и как хочешь, прокидывая нужные тебе сервисы прямо в них, а не таща через всю иерархию.
>>64825
Ну в моем случае MainViewModel зависит от ViewModel1, а уже ViewModel1 зависит от ViewModel2
То есть MainViewModel создает ViewModel1, ViewModel1 создает в себе ViewModel2
Это значит что MainViewModel ничего не знает о ViewModel2
Но это же все равно говорит о том что где-то там понадобится ViewModel2 хоть оно и под интерфейсом замаскировано, и все равно протягивается как ни одно то другое.
А если таких вьюмоделей будет 100500?
Это что получается фабрики фигачить где вьюмодели будут сгруппированы по смыслу и прокидывать их?
И я же не всегда могу знать наперед как должен будет объект скофигурирован, возможно, некоторые части конфигурации будут известны только в определенном контексте.
Ну в моем случае MainViewModel зависит от ViewModel1, а уже ViewModel1 зависит от ViewModel2
То есть MainViewModel создает ViewModel1, ViewModel1 создает в себе ViewModel2
Это значит что MainViewModel ничего не знает о ViewModel2
> в свою очередь конкретные их реализации ты можешь собирать где и как хочешь, прокидывая нужные тебе сервисы прямо в них, а не таща через всю иерархию
Но это же все равно говорит о том что где-то там понадобится ViewModel2 хоть оно и под интерфейсом замаскировано, и все равно протягивается как ни одно то другое.
А если таких вьюмоделей будет 100500?
Это что получается фабрики фигачить где вьюмодели будут сгруппированы по смыслу и прокидывать их?
И я же не всегда могу знать наперед как должен будет объект скофигурирован, возможно, некоторые части конфигурации будут известны только в определенном контексте.
Есть вот такой конфиг для log4net
<appender name="RollingFileAppender" type="log4net.Appender.RollingFileAppender">
<param name="File" value="MyLogFile."/>
<param name="AppendToFile" value="true" />
<param name="RollingStyle" value="Date"/>
<datePattern value=".yyyy.MM.dd_hh.mm.lo\g" />
<param name="StaticLogFileName" value="false"/>
<layout type="log4net.Layout.PatternLayout">
<param name="ConversionPattern" value="%d [%t] %-5p %c %m%n"/>
</layout>
</appender>
Можно как-то сделать, чтобы в имя файла писалось utcdate, а не время на компьютере? Или только кастомный аппендер писать?
<appender name="RollingFileAppender" type="log4net.Appender.RollingFileAppender">
<param name="File" value="MyLogFile."/>
<param name="AppendToFile" value="true" />
<param name="RollingStyle" value="Date"/>
<datePattern value=".yyyy.MM.dd_hh.mm.lo\g" />
<param name="StaticLogFileName" value="false"/>
<layout type="log4net.Layout.PatternLayout">
<param name="ConversionPattern" value="%d [%t] %-5p %c %m%n"/>
</layout>
</appender>
Можно как-то сделать, чтобы в имя файла писалось utcdate, а не время на компьютере? Или только кастомный аппендер писать?
> — C# 9 and .NET 5 – Modern Cross-Platform Development (Mark Price) — подойдёт для ознакомления с платформой. Затрагивает все технологии, имеющиеся в .NET (веб, мобильная разработка, машинное обучение), ни во что не углубляясь.
> — C# 8.0 in a Nutshell (Joseph Albahari и Eric Johannsen) — огромнейший справочник, over 1000 страниц, покрывает почти все области, начиная с синтаксиса и базовых типов и заканчивая интеропом и рослином.
> — C# 8.0 Pocket Reference (Joseph Albahari и Ben Albahari) — просто выжимка из книги сверху, можно всегда держать рукой.
> — Pro C# 8 with .NET Core 3 (Andrew Troelsen) — 1600-страничный учебник по шарпу, покрывает BCL, WPF и ASP.NET, небо и даже аллаха.
Есть ли смысл читать всё это, или хватит CLR via C#?
920 Кб, 3456x1944>>65703
Если ты новичек, то как раз таки лучше CLR via C# не читать, а взять что-то попроще
Я рекомендую Albahari и уже вышла C# 9.0 in a Nutshel
Сжато и по существу по всем основным и актуальным на данный момент темам.
>>65717
Сделать проект которым ты сам бы стал пользоваться, подумай что ты делаешь ежедневно за компом и что можно из этого автоматизировать.
Если лень думать вот тебе рулетка с форчана.
Если ты новичек, то как раз таки лучше CLR via C# не читать, а взять что-то попроще
Я рекомендую Albahari и уже вышла C# 9.0 in a Nutshel
Сжато и по существу по всем основным и актуальным на данный момент темам.
>>65717
Сделать проект которым ты сам бы стал пользоваться, подумай что ты делаешь ежедневно за компом и что можно из этого автоматизировать.
Если лень думать вот тебе рулетка с форчана.
>>65788
Ролл
Ролл
Возможно я задаю самый глупый вопрос за всё время существования тредов, но...
Как синхронизировать (и понять) async/await?
Итак, история.
Сегодня, при написании учебного CRUD-а, я попытался асинхронно подключиться к СУБД PostgreSQLl, используя Npgsql.
Я так понимаю, что большинство подобных драйверов/адаптеров/"я не знаю, как их правильно называть" для подключения к СУБД имеют схожий API ,похожий на ADO.NET для MS SQL Server.
Поэтому вам должно быть известно о существовании класса для подключения к СУБД, имеющего метод Open() и await OpenAsync() (класс NpgsqlConnection).
Вопрос становится очевидным - я попытался исполнить SQl-запрос (через методы await ExecuteNonQueryAsync() или await ExecuteReaderAsync() класса NpgsqlSqlCommand), но соединение с СУБД не было установлено, что приводило к NullReferenceException, причём он не отлавливался, VS выдавала ошибку на строчке, где происходил вызов тех методов, что я написал выше, хотя код выполнения SQL-команды был обёрнут в try/catch.
Я гуглил, но будто бы я абсурдный вопрос задаю, ни одного релевантного ответа нету. Не может быть такого, чтобы параллельно выполняющийся код не нужно было синхронизировать. А если не нужно, то так правильно писать все эти await методы?
И ещё один вопрос, фундаментальный.
Как вызывать async-методы? Если я в синхронном методе (как я метод обработки http-запроса в контроллере asp.net core асинхронным сделаю, это же абсурд, так?) вызову Task<SampleType> task = Task.Run(async () => await AsyncMethod()), то AsyncMethod() асинхронно выполнится? А если без async/await в лямбда-выражении? А если не async-метод? А если не async-метод и без async/await в лямбда-выражении? Я не понимаю этого потому что у меня нет фундаментального академического образования
И ещё - в Npgsql есть какой-то режим Multiplexing, и он включён по умолчанию, и если он включён, то нельзя использовать не-async методы для работы с БД. В интернете я нашёл инфу о том, что эта фича экспериментальная и отключена по дефолту. Обман, блядь. Причём в классе NpgsqlConnectionStringBuilder есть bool поле Multiplexing, и если ему присвоить false, то всё равно ничего не поменяется и будут лететь исключения об использовании не-async в Multiplexing режиме. Пришлось откатиться на версию 4.x.x, чтобы переписать код в не-async. Кто-нибудь знает, как использовать версию Npgsql посвежее и выключить Multiplexing? Хотя может проще async/await освоить, ха-ха.
И последняя проблема - почему JSON, сериализованный через new JsonResult() десериализуется GetJsonAsync() класса HttpClient, а string от JSON от JsonSerializer.Serialize() нет? Ещё мне не понятно, где в недрах фреймворка объект JsonResult превращается в набор байт для отправки по сети. Я думал, что я контроллером командую, а он там всякие 200 Ok дописывает в результаты работы методов в контроллере. Должно быть, строка тоже не просто так отправляется. Где прочитать про всё это?
Как синхронизировать (и понять) async/await?
Итак, история.
Сегодня, при написании учебного CRUD-а, я попытался асинхронно подключиться к СУБД PostgreSQLl, используя Npgsql.
Я так понимаю, что большинство подобных драйверов/адаптеров/"я не знаю, как их правильно называть" для подключения к СУБД имеют схожий API ,похожий на ADO.NET для MS SQL Server.
Поэтому вам должно быть известно о существовании класса для подключения к СУБД, имеющего метод Open() и await OpenAsync() (класс NpgsqlConnection).
Вопрос становится очевидным - я попытался исполнить SQl-запрос (через методы await ExecuteNonQueryAsync() или await ExecuteReaderAsync() класса NpgsqlSqlCommand), но соединение с СУБД не было установлено, что приводило к NullReferenceException, причём он не отлавливался, VS выдавала ошибку на строчке, где происходил вызов тех методов, что я написал выше, хотя код выполнения SQL-команды был обёрнут в try/catch.
Я гуглил, но будто бы я абсурдный вопрос задаю, ни одного релевантного ответа нету. Не может быть такого, чтобы параллельно выполняющийся код не нужно было синхронизировать. А если не нужно, то так правильно писать все эти await методы?
И ещё один вопрос, фундаментальный.
Как вызывать async-методы? Если я в синхронном методе (как я метод обработки http-запроса в контроллере asp.net core асинхронным сделаю, это же абсурд, так?) вызову Task<SampleType> task = Task.Run(async () => await AsyncMethod()), то AsyncMethod() асинхронно выполнится? А если без async/await в лямбда-выражении? А если не async-метод? А если не async-метод и без async/await в лямбда-выражении? Я не понимаю этого потому что у меня нет фундаментального академического образования
И ещё - в Npgsql есть какой-то режим Multiplexing, и он включён по умолчанию, и если он включён, то нельзя использовать не-async методы для работы с БД. В интернете я нашёл инфу о том, что эта фича экспериментальная и отключена по дефолту. Обман, блядь. Причём в классе NpgsqlConnectionStringBuilder есть bool поле Multiplexing, и если ему присвоить false, то всё равно ничего не поменяется и будут лететь исключения об использовании не-async в Multiplexing режиме. Пришлось откатиться на версию 4.x.x, чтобы переписать код в не-async. Кто-нибудь знает, как использовать версию Npgsql посвежее и выключить Multiplexing? Хотя может проще async/await освоить, ха-ха.
И последняя проблема - почему JSON, сериализованный через new JsonResult() десериализуется GetJsonAsync() класса HttpClient, а string от JSON от JsonSerializer.Serialize() нет? Ещё мне не понятно, где в недрах фреймворка объект JsonResult превращается в набор байт для отправки по сети. Я думал, что я контроллером командую, а он там всякие 200 Ok дописывает в результаты работы методов в контроллере. Должно быть, строка тоже не просто так отправляется. Где прочитать про всё это?
Возможно я задаю самый глупый вопрос за всё время существования тредов, но...
Как синхронизировать (и понять) async/await?
Итак, история.
Сегодня, при написании учебного CRUD-а, я попытался асинхронно подключиться к СУБД PostgreSQLl, используя Npgsql.
Я так понимаю, что большинство подобных драйверов/адаптеров/"я не знаю, как их правильно называть" для подключения к СУБД имеют схожий API ,похожий на ADO.NET для MS SQL Server.
Поэтому вам должно быть известно о существовании класса для подключения к СУБД, имеющего метод Open() и await OpenAsync() (класс NpgsqlConnection).
Вопрос становится очевидным - я попытался исполнить SQl-запрос (через методы await ExecuteNonQueryAsync() или await ExecuteReaderAsync() класса NpgsqlSqlCommand), но соединение с СУБД не было установлено, что приводило к NullReferenceException, причём он не отлавливался, VS выдавала ошибку на строчке, где происходил вызов тех методов, что я написал выше, хотя код выполнения SQL-команды был обёрнут в try/catch.
Я гуглил, но будто бы я абсурдный вопрос задаю, ни одного релевантного ответа нету. Не может быть такого, чтобы параллельно выполняющийся код не нужно было синхронизировать. А если не нужно, то так правильно писать все эти await методы?
И ещё один вопрос, фундаментальный.
Как вызывать async-методы? Если я в синхронном методе (как я метод обработки http-запроса в контроллере asp.net core асинхронным сделаю, это же абсурд, так?) вызову Task<SampleType> task = Task.Run(async () => await AsyncMethod()), то AsyncMethod() асинхронно выполнится? А если без async/await в лямбда-выражении? А если не async-метод? А если не async-метод и без async/await в лямбда-выражении? Я не понимаю этого потому что у меня нет фундаментального академического образования
И ещё - в Npgsql есть какой-то режим Multiplexing, и он включён по умолчанию, и если он включён, то нельзя использовать не-async методы для работы с БД. В интернете я нашёл инфу о том, что эта фича экспериментальная и отключена по дефолту. Обман, блядь. Причём в классе NpgsqlConnectionStringBuilder есть bool поле Multiplexing, и если ему присвоить false, то всё равно ничего не поменяется и будут лететь исключения об использовании не-async в Multiplexing режиме. Пришлось откатиться на версию 4.x.x, чтобы переписать код в не-async. Кто-нибудь знает, как использовать версию Npgsql посвежее и выключить Multiplexing? Хотя может проще async/await освоить, ха-ха.
И последняя проблема - почему JSON, сериализованный через new JsonResult() десериализуется GetJsonAsync() класса HttpClient, а string от JSON от JsonSerializer.Serialize() нет? Ещё мне не понятно, где в недрах фреймворка объект JsonResult превращается в набор байт для отправки по сети. Я думал, что я контроллером командую, а он там всякие 200 Ok дописывает в результаты работы методов в контроллере. Должно быть, строка тоже не просто так отправляется. Где прочитать про всё это?
Как синхронизировать (и понять) async/await?
Итак, история.
Сегодня, при написании учебного CRUD-а, я попытался асинхронно подключиться к СУБД PostgreSQLl, используя Npgsql.
Я так понимаю, что большинство подобных драйверов/адаптеров/"я не знаю, как их правильно называть" для подключения к СУБД имеют схожий API ,похожий на ADO.NET для MS SQL Server.
Поэтому вам должно быть известно о существовании класса для подключения к СУБД, имеющего метод Open() и await OpenAsync() (класс NpgsqlConnection).
Вопрос становится очевидным - я попытался исполнить SQl-запрос (через методы await ExecuteNonQueryAsync() или await ExecuteReaderAsync() класса NpgsqlSqlCommand), но соединение с СУБД не было установлено, что приводило к NullReferenceException, причём он не отлавливался, VS выдавала ошибку на строчке, где происходил вызов тех методов, что я написал выше, хотя код выполнения SQL-команды был обёрнут в try/catch.
Я гуглил, но будто бы я абсурдный вопрос задаю, ни одного релевантного ответа нету. Не может быть такого, чтобы параллельно выполняющийся код не нужно было синхронизировать. А если не нужно, то так правильно писать все эти await методы?
И ещё один вопрос, фундаментальный.
Как вызывать async-методы? Если я в синхронном методе (как я метод обработки http-запроса в контроллере asp.net core асинхронным сделаю, это же абсурд, так?) вызову Task<SampleType> task = Task.Run(async () => await AsyncMethod()), то AsyncMethod() асинхронно выполнится? А если без async/await в лямбда-выражении? А если не async-метод? А если не async-метод и без async/await в лямбда-выражении? Я не понимаю этого потому что у меня нет фундаментального академического образования
И ещё - в Npgsql есть какой-то режим Multiplexing, и он включён по умолчанию, и если он включён, то нельзя использовать не-async методы для работы с БД. В интернете я нашёл инфу о том, что эта фича экспериментальная и отключена по дефолту. Обман, блядь. Причём в классе NpgsqlConnectionStringBuilder есть bool поле Multiplexing, и если ему присвоить false, то всё равно ничего не поменяется и будут лететь исключения об использовании не-async в Multiplexing режиме. Пришлось откатиться на версию 4.x.x, чтобы переписать код в не-async. Кто-нибудь знает, как использовать версию Npgsql посвежее и выключить Multiplexing? Хотя может проще async/await освоить, ха-ха.
И последняя проблема - почему JSON, сериализованный через new JsonResult() десериализуется GetJsonAsync() класса HttpClient, а string от JSON от JsonSerializer.Serialize() нет? Ещё мне не понятно, где в недрах фреймворка объект JsonResult превращается в набор байт для отправки по сети. Я думал, что я контроллером командую, а он там всякие 200 Ok дописывает в результаты работы методов в контроллере. Должно быть, строка тоже не просто так отправляется. Где прочитать про всё это?
>>65917
Я имел ввиду формат передачи данных по HTTP, а то, где в недрах ASP.NET Core из возвращаемого значения метода в контроллере формируется HTTP-пакет и как программист может повлиять на этот процесс.
>Где прочитать про всё это?
Я имел ввиду формат передачи данных по HTTP, а то, где в недрах ASP.NET Core из возвращаемого значения метода в контроллере формируется HTTP-пакет и как программист может повлиять на этот процесс.
>>65917
1. NRE - нельзя отловить, если его бросает сама система.
2. Асмнк-эвейт в твоем кейсе - не нужно синхронизировать.
3. Асинхронный код - в контексте TPL - это стейтмашина, когда ты пишешь await - твой метод компилятор разбивает на 2 части(в зависимости от количества await в методах - может быть больше частей), и по сути у тебя простая стейтмашина, которая проверяе - выполнилась выполнился ли предыдущий шаг, если нет - передает управление наверх, если выполнился - переходит к оставшейся части кода.
Суть, асинки - вообще могут выполняться в одном потоке и у тебя будет кооперативная многозадачность, т.е. когда ты пишешь await - ты сигнализируешь коду наверху, что готов передать управление, затем, будет выполняться какой-то другой код, пока он не завершиться, либо сам не вызовет await
Просто сделаешь. Почему нет? Фреймворк умеет с этим работать нормально.
> Task<SampleType> task = Task.Run(async () => await AsyncMethod()),
Нахуя? Почему не просто:
await AsyncMethod()?
В недрах фреймворка просто есть сокет, он принимает входящие соединения, создает ConnectionContext, в котором в есть метод в духе ProcessConnection(), там просто бесконечный цикл чтения из сокета, который получает пакеты, пытается его распарсить, если распарсил - формирует HttpRequest и HttpContext, в которые пихает все что было в запросе. Затем запрос передается обработчику В asp.net - этим обработчиком является middleware(прикриплейд 1), с помощью него происходит всякая магия, например можно организовать проверку куков, логгирование запросов, роутинг и т.д. Они представляют из себя стандартную цепочку ответственности. Контроллеры - это тоже middlware - он представляет из себя просто хуйню, которая с помощью рефлексии достает из атрибутов путь и метод который к этому пути привязан, если запрос - обращается по пути который есть в контроллерах - будет вызван метод, если нет - будет передан дальше. Ты можешь не пользоваться контроллерами, а просто запилить middleware и пихнуть его самым первым в цепочке, и, например - отдавать сразу что-то, вместо того чтобы пускать дальше.
Кстати, именно из-за того что это цепочка ответственности, в Startup в void Configure - имеет значение в котором ты располагаешь использование middleware.
А вообще, я бы советовал начать с сокетов и самому попробовать что-то написать, допустим что-то типа второго-третьего прикриплейд. После даже таких простых штук - все легче понимать, чем если ты смотришь на все как на черный ящик.
1. NRE - нельзя отловить, если его бросает сама система.
2. Асмнк-эвейт в твоем кейсе - не нужно синхронизировать.
3. Асинхронный код - в контексте TPL - это стейтмашина, когда ты пишешь await - твой метод компилятор разбивает на 2 части(в зависимости от количества await в методах - может быть больше частей), и по сути у тебя простая стейтмашина, которая проверяе - выполнилась выполнился ли предыдущий шаг, если нет - передает управление наверх, если выполнился - переходит к оставшейся части кода.
Суть, асинки - вообще могут выполняться в одном потоке и у тебя будет кооперативная многозадачность, т.е. когда ты пишешь await - ты сигнализируешь коду наверху, что готов передать управление, затем, будет выполняться какой-то другой код, пока он не завершиться, либо сам не вызовет await
> как я метод обработки http-запроса в контроллере asp.net core асинхронным сделаю, это же абсурд, так?
Просто сделаешь. Почему нет? Фреймворк умеет с этим работать нормально.
> Task<SampleType> task = Task.Run(async () => await AsyncMethod()),
Нахуя? Почему не просто:
await AsyncMethod()?
> Я имел ввиду формат передачи данных по HTTP, а то, где в недрах ASP.NET Core из возвращаемого значения метода в контроллере формируется HTTP-пакет и как программист может повлиять на этот процесс.
В недрах фреймворка просто есть сокет, он принимает входящие соединения, создает ConnectionContext, в котором в есть метод в духе ProcessConnection(), там просто бесконечный цикл чтения из сокета, который получает пакеты, пытается его распарсить, если распарсил - формирует HttpRequest и HttpContext, в которые пихает все что было в запросе. Затем запрос передается обработчику В asp.net - этим обработчиком является middleware(прикриплейд 1), с помощью него происходит всякая магия, например можно организовать проверку куков, логгирование запросов, роутинг и т.д. Они представляют из себя стандартную цепочку ответственности. Контроллеры - это тоже middlware - он представляет из себя просто хуйню, которая с помощью рефлексии достает из атрибутов путь и метод который к этому пути привязан, если запрос - обращается по пути который есть в контроллерах - будет вызван метод, если нет - будет передан дальше. Ты можешь не пользоваться контроллерами, а просто запилить middleware и пихнуть его самым первым в цепочке, и, например - отдавать сразу что-то, вместо того чтобы пускать дальше.
Кстати, именно из-за того что это цепочка ответственности, в Startup в void Configure - имеет значение в котором ты располагаешь использование middleware.
А вообще, я бы советовал начать с сокетов и самому попробовать что-то написать, допустим что-то типа второго-третьего прикриплейд. После даже таких простых штук - все легче понимать, чем если ты смотришь на все как на черный ящик.
>>65917
1. NRE - нельзя отловить, если его бросает сама система.
2. Асмнк-эвейт в твоем кейсе - не нужно синхронизировать.
3. Асинхронный код - в контексте TPL - это стейтмашина, когда ты пишешь await - твой метод компилятор разбивает на 2 части(в зависимости от количества await в методах - может быть больше частей), и по сути у тебя простая стейтмашина, которая проверяе - выполнилась выполнился ли предыдущий шаг, если нет - передает управление наверх, если выполнился - переходит к оставшейся части кода.
Суть, асинки - вообще могут выполняться в одном потоке и у тебя будет кооперативная многозадачность, т.е. когда ты пишешь await - ты сигнализируешь коду наверху, что готов передать управление, затем, будет выполняться какой-то другой код, пока он не завершиться, либо сам не вызовет await
Просто сделаешь. Почему нет? Фреймворк умеет с этим работать нормально.
> Task<SampleType> task = Task.Run(async () => await AsyncMethod()),
Нахуя? Почему не просто:
await AsyncMethod()?
В недрах фреймворка просто есть сокет, он принимает входящие соединения, создает ConnectionContext, в котором в есть метод в духе ProcessConnection(), там просто бесконечный цикл чтения из сокета, который получает пакеты, пытается его распарсить, если распарсил - формирует HttpRequest и HttpContext, в которые пихает все что было в запросе. Затем запрос передается обработчику В asp.net - этим обработчиком является middleware(прикриплейд 1), с помощью него происходит всякая магия, например можно организовать проверку куков, логгирование запросов, роутинг и т.д. Они представляют из себя стандартную цепочку ответственности. Контроллеры - это тоже middlware - он представляет из себя просто хуйню, которая с помощью рефлексии достает из атрибутов путь и метод который к этому пути привязан, если запрос - обращается по пути который есть в контроллерах - будет вызван метод, если нет - будет передан дальше. Ты можешь не пользоваться контроллерами, а просто запилить middleware и пихнуть его самым первым в цепочке, и, например - отдавать сразу что-то, вместо того чтобы пускать дальше.
Кстати, именно из-за того что это цепочка ответственности, в Startup в void Configure - имеет значение в котором ты располагаешь использование middleware.
А вообще, я бы советовал начать с сокетов и самому попробовать что-то написать, допустим что-то типа второго-третьего прикриплейд. После даже таких простых штук - все легче понимать, чем если ты смотришь на все как на черный ящик.
1. NRE - нельзя отловить, если его бросает сама система.
2. Асмнк-эвейт в твоем кейсе - не нужно синхронизировать.
3. Асинхронный код - в контексте TPL - это стейтмашина, когда ты пишешь await - твой метод компилятор разбивает на 2 части(в зависимости от количества await в методах - может быть больше частей), и по сути у тебя простая стейтмашина, которая проверяе - выполнилась выполнился ли предыдущий шаг, если нет - передает управление наверх, если выполнился - переходит к оставшейся части кода.
Суть, асинки - вообще могут выполняться в одном потоке и у тебя будет кооперативная многозадачность, т.е. когда ты пишешь await - ты сигнализируешь коду наверху, что готов передать управление, затем, будет выполняться какой-то другой код, пока он не завершиться, либо сам не вызовет await
> как я метод обработки http-запроса в контроллере asp.net core асинхронным сделаю, это же абсурд, так?
Просто сделаешь. Почему нет? Фреймворк умеет с этим работать нормально.
> Task<SampleType> task = Task.Run(async () => await AsyncMethod()),
Нахуя? Почему не просто:
await AsyncMethod()?
> Я имел ввиду формат передачи данных по HTTP, а то, где в недрах ASP.NET Core из возвращаемого значения метода в контроллере формируется HTTP-пакет и как программист может повлиять на этот процесс.
В недрах фреймворка просто есть сокет, он принимает входящие соединения, создает ConnectionContext, в котором в есть метод в духе ProcessConnection(), там просто бесконечный цикл чтения из сокета, который получает пакеты, пытается его распарсить, если распарсил - формирует HttpRequest и HttpContext, в которые пихает все что было в запросе. Затем запрос передается обработчику В asp.net - этим обработчиком является middleware(прикриплейд 1), с помощью него происходит всякая магия, например можно организовать проверку куков, логгирование запросов, роутинг и т.д. Они представляют из себя стандартную цепочку ответственности. Контроллеры - это тоже middlware - он представляет из себя просто хуйню, которая с помощью рефлексии достает из атрибутов путь и метод который к этому пути привязан, если запрос - обращается по пути который есть в контроллерах - будет вызван метод, если нет - будет передан дальше. Ты можешь не пользоваться контроллерами, а просто запилить middleware и пихнуть его самым первым в цепочке, и, например - отдавать сразу что-то, вместо того чтобы пускать дальше.
Кстати, именно из-за того что это цепочка ответственности, в Startup в void Configure - имеет значение в котором ты располагаешь использование middleware.
А вообще, я бы советовал начать с сокетов и самому попробовать что-то написать, допустим что-то типа второго-третьего прикриплейд. После даже таких простых штук - все легче понимать, чем если ты смотришь на все как на черный ящик.
>>65996
- стоит различать HTTP/1.1 и HTTP/2
- на втором скрине работа не с сокетами, а с хай лвл обертками над сокетами
- в последней версии C# можно упростить код, убрав фигурные скобки у using, как сделано на следующих строчках, не говоря о асинхронном using
- using разворачивается в try-finally, где в блоке finally вызывается метод Dispose/DisposeAsync, т.е. нефиг руками диспозить клиента
- реализация на втором скрине крайне хреновая по ряду причин: не показывает подноготные работы с пакетами и их особенности, сокет может разорваться в середине, бывают кодировки отличные от UTF-8, много аллокаций памяти, смешивание абстракций разных уровней, выборочная венгерская нотация, нарушение S в SOLID, нарушение DRY и других практик, схренали Print вообще что-то возвращает, еще и имя метода конченное ProcessClient (на уровне ISuperManager, пойди разбери хули он вообще делает)
- на третьем скрине вообще хуй пойми что происходит и что такое -1, отличный пример того как не следует писать код
>А вообще, я бы советовал начать с сокетов и самому попробовать что-то написать, допустим что-то типа второго-третьего прикриплейд.
- стоит различать HTTP/1.1 и HTTP/2
- на втором скрине работа не с сокетами, а с хай лвл обертками над сокетами
- в последней версии C# можно упростить код, убрав фигурные скобки у using, как сделано на следующих строчках, не говоря о асинхронном using
- using разворачивается в try-finally, где в блоке finally вызывается метод Dispose/DisposeAsync, т.е. нефиг руками диспозить клиента
- реализация на втором скрине крайне хреновая по ряду причин: не показывает подноготные работы с пакетами и их особенности, сокет может разорваться в середине, бывают кодировки отличные от UTF-8, много аллокаций памяти, смешивание абстракций разных уровней, выборочная венгерская нотация, нарушение S в SOLID, нарушение DRY и других практик, схренали Print вообще что-то возвращает, еще и имя метода конченное ProcessClient (на уровне ISuperManager, пойди разбери хули он вообще делает)
- на третьем скрине вообще хуй пойми что происходит и что такое -1, отличный пример того как не следует писать код
>>65996
Код падает, если коннект к БД ещё не установился. Что делать тогда?
Как синхронизировать, если нужно будет?
Я с эти тоже столкнулся. Так и не понял тогда, почему в дебаге выполнение возвращается в вызывающий метод, приводя к ещё одному исключению.
Как я могу вызвать await из не-async метода? Я вижу способ только через Task. Как тогда с async-await работать? И вообще ничего не понятно. Task делит код, await делит код, thread делит код. Как работает параллельное выполнение кода я догадываюсь. И ещё догадываюсь, что это выполнение нужно синхронизировать. В чём разница работы шарповских возможностей параллелизма?
Я попробую. Благодарю за ответ.
Я сделал вывод, что метанит - дерьмо. Пойду покупать книги по computer science и CLR via c#.
Хотя crud я написал, но он синхронный и роутинг через атрибуты, хотя так вроде бы не принято делать
>2. Асмнк-эвейт в твоем кейсе - не нужно синхронизировать.
Код падает, если коннект к БД ещё не установился. Что делать тогда?
Как синхронизировать, если нужно будет?
>которая проверяе - выполнилась выполнился ли предыдущий шаг, если нет - передает управление наверх, если выполнился - переходит к оставшейся части кода.
Я с эти тоже столкнулся. Так и не понял тогда, почему в дебаге выполнение возвращается в вызывающий метод, приводя к ещё одному исключению.
>Нахуя? Почему не просто: await AsyncMethod()
Как я могу вызвать await из не-async метода? Я вижу способ только через Task. Как тогда с async-await работать? И вообще ничего не понятно. Task делит код, await делит код, thread делит код. Как работает параллельное выполнение кода я догадываюсь. И ещё догадываюсь, что это выполнение нужно синхронизировать. В чём разница работы шарповских возможностей параллелизма?
> я бы советовал начать с сокетов и самому попробовать что-то написать
Я попробую. Благодарю за ответ.
Я сделал вывод, что метанит - дерьмо. Пойду покупать книги по computer science и CLR via c#.
Хотя crud я написал, но он синхронный и роутинг через атрибуты, хотя так вроде бы не принято делать
>>66231
Ну да, тебе нужно всю цепочку методов помечать как асинк в таком случае
Await это не про параллельное выполнение кода
Это асинхронное выполнение кода, которое не блокирует поток из котрого был вызван асинхронный метод.
> ак я могу вызвать await из не-async метода?
Ну да, тебе нужно всю цепочку методов помечать как асинк в таком случае
> Task делит код, await делит код, thread делит код.
Await это не про параллельное выполнение кода
Это асинхронное выполнение кода, которое не блокирует поток из котрого был вызван асинхронный метод.
Антоны, собираюсь повторять сишарп начиная с Рихтера и че там для вашего новомодного нужно прочесть
>>66380
Ну и да, не обновил ли Рихтер свое чтиво для новых версий? А то не очень застревать на .net framework 4.5
Много ли после него мне вообще нагонять надо? Я в C# раньше умел более-менее на уровне джуна, а сейчас подзабыл, за месяца 3-4 бы подготовиться и на работку выйти
Ну и да, не обновил ли Рихтер свое чтиво для новых версий? А то не очень застревать на .net framework 4.5
Много ли после него мне вообще нагонять надо? Я в C# раньше умел более-менее на уровне джуна, а сейчас подзабыл, за месяца 3-4 бы подготовиться и на работку выйти
>>66092
Потому что я уже писала код с сокетами и мне не особо интересно это.
В данном случае - нет
И не нужно. В контексте HTTP/1.1 сервера мы можем воспринимать пакет как набор строк, метод TryParseRequest - делает все что нужно для парсинга, не ответственность метода ProcessClient парсить пакеты или читать напрямую из сокета, если есть удобная обертка
И таска просто выкинет ошибку, которую я словлю на уровне выше
И? Я пишу сервер который отдает Hello World, блядь, мне срать на остальные кодировки
Пусть покупают сервак помощнее
Ее там нет
Глаза протри, там нет венгерской нотоции нигде
Осознанное и оправданное в контексте Http-фреймворка в >200 строк
Если ты про два SendAsync - то это более понятный код, чем если бы там был тернарник возвращающий реквест
И вообще - напиши ты HTTP-сервер в 200 строк, который умеет, при этом в роутинг и файлы отдавать(мой-то умеет), а потом выебывайся.
> на втором скрине работа не с сокетами, а с хай лвл обертками над сокетами
Потому что я уже писала код с сокетами и мне не особо интересно это.
> в последней версии C# можно упростить код, убрав фигурные скобки у using, как сделано на следующих строчках, не говоря о асинхронном using
В данном случае - нет
> не показывает подноготные работы с пакетами и их особенности,
И не нужно. В контексте HTTP/1.1 сервера мы можем воспринимать пакет как набор строк, метод TryParseRequest - делает все что нужно для парсинга, не ответственность метода ProcessClient парсить пакеты или читать напрямую из сокета, если есть удобная обертка
> сокет может разорваться в середине
И таска просто выкинет ошибку, которую я словлю на уровне выше
> бывают кодировки отличные от UTF-8
И? Я пишу сервер который отдает Hello World, блядь, мне срать на остальные кодировки
> много аллокаций памяти
Пусть покупают сервак помощнее
> смешивание абстракций разных уровней,
Ее там нет
> выборочная венгерская нотация
Глаза протри, там нет венгерской нотоции нигде
> нарушение S в SOLID
Осознанное и оправданное в контексте Http-фреймворка в >200 строк
> нарушение DRY
Если ты про два SendAsync - то это более понятный код, чем если бы там был тернарник возвращающий реквест
И вообще - напиши ты HTTP-сервер в 200 строк, который умеет, при этом в роутинг и файлы отдавать(мой-то умеет), а потом выебывайся.
>>66231
А насчет нейминга - он спизжен из кестрелла. Все претензии к майкрософту.
А насчет нейминга - он спизжен из кестрелла. Все претензии к майкрософту.
>>66534
У тебя не веб-сокеты, ты изначально решил задачу неправильно.
>напиши ты HTTP-сервер в 200 строк
У тебя не веб-сокеты, ты изначально решил задачу неправильно.
>>66534
О, писькомерство за строчки - первый признак профана.
> И вообще - напиши ты HTTP-сервер в 200 строк
О, писькомерство за строчки - первый признак профана.
>>66534
А может лучше тебя на улицу выкинуть и взять более компетентного программиста?
Это дешевле будет
> Пусть покупают сервак помощнее
А может лучше тебя на улицу выкинуть и взять более компетентного программиста?
Это дешевле будет
>>66885
Я получаю 15к в месяц. Давай посчитаем сколько будет стоить заменить меня, при условии что у меня 5 лет опыта работы, на человека который хотя бы так же сможет.
Ну давай я за тебя это сделаю:
- Премия рекрутеру за удачный хант - половина годовой ЗП кодера
- Рабочее место новенькому - 200к
- Его ЗП - очевидно будет больше, потому что хуй ты найдешь такого же еблана, который за 15к будет работать
А теперь - купить план подороже - в среднем, это +500 бачей в год.
Я не думаю что заменить меня будет дешевле)))
> Это дешевле будет
Я получаю 15к в месяц. Давай посчитаем сколько будет стоить заменить меня, при условии что у меня 5 лет опыта работы, на человека который хотя бы так же сможет.
Ну давай я за тебя это сделаю:
- Премия рекрутеру за удачный хант - половина годовой ЗП кодера
- Рабочее место новенькому - 200к
- Его ЗП - очевидно будет больше, потому что хуй ты найдешь такого же еблана, который за 15к будет работать
А теперь - купить план подороже - в среднем, это +500 бачей в год.
Я не думаю что заменить меня будет дешевле)))
>>66828
Мешают перспективы дальнейшей поддержки.
Мешают перспективы дальнейшей поддержки.
>>66761
При чем тут профан? Цель - написать рабочий HTTP-сервер, используя как можно меньше строк, при этом чтобы можно было и маршрутизацию какую-то иметь и отдавать файлы. Если бы я пилил что-то интерарайзное, то я бы не экономил строчки.
При чем тут профан? Цель - написать рабочий HTTP-сервер, используя как можно меньше строк, при этом чтобы можно было и маршрутизацию какую-то иметь и отдавать файлы. Если бы я пилил что-то интерарайзное, то я бы не экономил строчки.
НОРМАЛЬНЫЙ ПЕРЕКАТ С ТЕГОМ
НОРМАЛЬНЫЙ ПЕРЕКАТ С ТЕГОМ
НОРМАЛЬНЫЙ ПЕРЕКАТ С ТЕГОМ
>>2067562 (OP)
>>2067562 (OP)
>>2067562 (OP)
НОРМАЛЬНЫЙ ПЕРЕКАТ С ТЕГОМ
НОРМАЛЬНЫЙ ПЕРЕКАТ С ТЕГОМ
>>2067562 (OP)
>>2067562 (OP)
>>2067562 (OP)
>>63714
локальную систему контроля версий, c отслеживанием через события, плюс добавить сжатие старых данных, если есть желание подумать как ветки добавить и откатываться, закатываться и мержить
локальную систему контроля версий, c отслеживанием через события, плюс добавить сжатие старых данных, если есть желание подумать как ветки добавить и откатываться, закатываться и мержить
>>72496
ето был мой тестовый проект, на моей стажировке из 36 человек сделали только 6, так что идея интересная есть и на подумать тоже
ето был мой тестовый проект, на моей стажировке из 36 человек сделали только 6, так что идея интересная есть и на подумать тоже
Тред утонул или удален.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 30 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.