Pull to refresh

Comments 17

Думаю единственное что меня разочаровало в 2.0 так это то что до сих пор не допилили DirectoryServices.


Обещали в след релизе. Но я думаю затянут как всегда !

А меня в core разочаровал Entity Framework Core. Недавно столкнулся с тем что там GROUP BY очень ограничен, и не конвертируется нормально в SQL запрос.


Обещают в 2.1 добавить.

А меня порадовало то что он раза так в 2-3 шустрее чем 6ой
По ощущениям, да и по официальным бенчам
В .net core повсюду в примерах и книгах пишут код с async/await. Это прям дает мощный прирост скорости или просто модно/молодежно/хайп? (для маленьких и средних сайтов)

Core или нет, а неблокирующий вебсервер лучше блокирующего.

Можно и не писать, если у вас весь стек обработки запроса синхронный. А вот если асинхронный, то лучше потоку другие запросы пообрабатывать, чем, скажем, на IO у базы сидеть, в ожидании ответа.
Не в .net core дело: асинхронный код пишут практически повсеместно начиная с .net 4.5, с момента появления TAP (до этого было мягко говоря неудобно). Писать асинхронный код в вебе — это хорошая практика. Особенно актуально, когда у вас в рамках обработки запроса имеются IO-операции или сложные cpu вычисления. Позволяет не блокировать поток в ожидании ответа от операции, а передать его в пул, чтобы он мог заниматься другими полезными вещами (например обрабатывать другие запросы). Наглядный пример асинхронной обработки: кассир в макдональдсе, он начинает принимать заказ у следующего посетителя, пока предыдущий посетитель ожидает, когда же его заказ будет сформирован и упакован.
Async\await в свою очередь позволяет писать асинхронный код в виде синхронного кода, что облегчает чтение и понимание, ну и отладка гораздо проще.
Думаю тут все зависит. Await просто позволяет высвободить тред (пока задача пошла ждать чего-нибуть) для обработки другого запроса, так что теоретически, если нагрузка, т.е. число запросов небольшое, то и прироста никакого. С другой стороны, если у сервера вообще три треда в пуле, которые постоянно грузятся ожиданием ответа, скажем, медленного перфоратора что тот дырку закончил пробивать, то производительность, в смысле скорость отвера на другие запросы, вырастет. Думаю этот вопрос обсуждался триллион раз в инетах, но я не изучал.
Entity Framework Core и все же деградирует товарищи
Перерыл весь интернет так не нашел событие на шутдаун. Не подскажите?

А нельзя просто в Program.Main добавить код после вызова .Run()?


public static void Main(string[] args)
{
    BuildWebHost(args).Run();
    System.Console.WriteLine("Some code to execute on quit");
}
Скорее всего это не достижимый участок кода. Я так понял Run() занимает поток до конца жизни приложения. Но в конце жизни, потоки могут быть закрыты принудительно. Поэтому и нужно пользоваться предусмотренными функциями. А еще может быть эксепшн до вашего кода…

Я на простом проекте пробовал — текст печатался, так что код доступен. Про другие потоки не подумал, тут не подскажу к сожалению

Насчёт "Явное указание файлов является необязательным для добавления их в проект": да, структура проекта стала проще и это хорошо. Плохо теперь, что в папке Migrations (и без того немаленькой) будет в два раза больше файлов.

Sign up to leave a comment.

Articles