Привет гуру .NET и в особенности те кто в теме Core.
Поделитесь пожалуйста своими наблюдениями по использованию данной технологии.
Конкретно сейчас меня интересуют вопросы производительности и прожорливости web приложений на ASP.NET Core.
По вашим наблюдениями сколько может кушать простое web приложение (с учетом пустой DB) памяти и как по производительности (если есть какие-то интересные ссылки на бенчмарки буду сильно признателен).
Как обычно происходит сборка и деплой web приложений на сервер? (может есть какие-то ваши личные лучшие практики)
Наткнулся на отличную статью с реальных примеров использования .NET Core в продакшене достаточно большого сервиса. Но статья намного шире и будет полезна все для общего понимания современного мира web разработки.
Первый негатив от .net
Сегодня столкнулся с такой проблемой - заметил что Entity Framework создает колонки в последовательности абсолютно хаотичной. Мелочь, а неприятно. Стал разбираться - всплыли советы обновить мою текущую версию либы на более новую. Сделал и тут понеслось. Начали сыпаться непонятные ошибки. Новые миграции начали генерироваться с ошибками. И это при том что у меня еще минимальная тестовая база. Попробовал обновить версии других используемых либ до последних - вообще посыпался зоопарк ошибок которые даже не гуглятся. Короче полдня гугления ничего не дали, только попоболь. Откатил все версии в файле csproj на то что было изначально и вот сейчас сижу пытаюсь понять - что это было? Как вообще можно тогда работать с версиями пакетов? Про обратную совместимость чтоли не слышали? Особенно удивило что при попытке устаносить новую версию по проекту помыпались ошибки в строках с using. И так ипешься под маком с разруливанием зависимостей а тут еще и то что раньше работало внезапно перестает работать. Я все больше склоняюсь к тому что без полноценной VS в .net делать нечего.
Ну и всетаки расстраивает процесс разработки.
dotnet watch run
просто убивает. После сохранения изменений можно идти пить чай до того момента как приложение перезапустся. Второго SF мне не хочется иметь :(.
Ну и апофиозом стало глюк в dotnet cli 
При попытке запустит
dotnet restore
валилась просто какая-то непонятная ошибка.
/usr/local/share/dotnet/sdk/2.1.4/Microsoft.Common.targets(127,3): error MSB4024: The imported project file "/Users/dmnbrest/Documents/dotnet2/M33/obj/M33.csproj.EntityFrameworkCore.targets" could not be loaded. Data at the root level is invalid. Line 25, position 7. [/Users/dmnbrest/Documents/dotnet2/M33/M33.csproj]
Даже откат на 100% рабочий .csproj ничего не дал.
Не помню что помогла, но пришлось удалять все левые папки и файлы с проекта которые не имели непосредственное отношение к исходному коду. Короче магия!
На самом деле магии нету. Net Core по производительности достаточно веселая штука. Без базы данных пустой проект в отладке с линком на браузер в памяти занимает мегабайт 80-100. С EF Core - примерно 300. Но там надо учитывать, что в студии разворачивается браузер в режиме отладки, SQL сервер в режиме отладки + сама студия в режиме отладки. Просто при запуске проекта вылазит окошко, где можно посмотреть что и как жрет и на сколько просаживает систему + можно закинуть нагрузочное тестирование, скажем одновременный запрос 10000 пользователей, поставить сковородку на процессор и зажарить там быка.
Сейчас мелкие готовят к выходу Core 3.0 - в плане жора ресурсов они там продвинулись конкретно вперед. Тот же Angular по сравнению с Blazor или Razor Components - это ребенок-даун, который в песочнице нюхает клей.
Пока что, для нормальной работы с бэкэндом Core лучше использовать студию. Все остальное - жалкое подобие правой руки. Долгий запуск - не видел. У меня проекты без базы данных на полной пересборке запускаются секунд за 15-30. С базой данных намного дольше, ибо тут не в сборке проблема, а в самом EF core. Мелкософт откровенно не хочет замечать, или не знает решения проблемы - это раскачка кэша. Первый запуск и пока EF разогреет кэш для работы - может пройти пару-тройку минут, перед тем как он начнет на запросы отвечать.
Но, конкретно по студии, работаешь на фронте - перезапускать каждый раз не надо. Все изменения гипертекста и скрипта принимаются браузером без перезапуска системы, или перезапуск страницы или студия сама обновит все в браузере.
Теперь по твоей проблеме. При таких глюках тут надо реально видеть. При работе с ASP.NET не то что рекомендуется, а настоятельно требуется использование middleware и DI. При работе в студии она автоматом подтягивает нужные пакеты для работы. VS Code для мака - не самое лучшее решение работать с бэкендом Core. А вот фронтенд там работается даже быстрее, а с ангуляром и прочими JS-фреймворками и легче.
Если ставишь EF Core, тогда сразу надо добавлять
Microsoft.EntityFrameworkCore.Tools - для полноценной работы с сущностями базы данных, их миграции и т.д.
Microsoft.EntityFrameworkCore.SqlServer - это middleware, с ним вообще забываешь о наличии у тебя SQL и полностью работаешь только со своей структурой базы. Есть для других серверов.
Я смотрю ты так же готов клеймить .NET индусскими проклятиями на суахили, как я ругаю SF за его безразмерную тупость и трату ресурсов.
Если интересно поковыряться не в пустом проекте, а в котором уже что-то есть, то могу скинуть тебе тестовое задание, которое делал. Core 2.2 + EF Core + Angular7 + material. Реализован REST, CRUD, MVC, WebApi, middleware над сервером и базой данных, связь контроллеров с БД через DI.
Спасибо за полезную информацию, yurick!
НО небольшой проектик на .net закончился (был успешно реализован), но я понял для себя что больше я с .net связываться не хочу. Все-таки это слишком большая тема для моего мозга - не потяну. Мне на сегодняшний день хватит Salesforce, Python, NodeJS(бэкенд) и Angular (фронтенд). Думаю я остановился на это идеально смеси технологий. Прыгать по новым языкам я закончил. .Net был последний в списке чего надо было попробовать и я его попробовал 
Кстати интересный вопрос. Я давно говорю что Salesforce программисты (если чисто сидят на SF) слабые как настоящие программисты, потому что платформа сильно все упрощает. Чисто для сравнения было бы интересно увидеть какое тестовое задание предлагают на .Net на такую же позицию junior. Я бы с удовольствием показывал его начинающим чтобы они не говорили что SF это тяжело.
Никого не хочу обидеть, сужу по себе. Имея огромный опыт в SF и постоянно практикуя другие языки на реальных проектах я не перестаю офуевать как все сложно за пределами SF. Уже где-то год сижу на Python+NodeJS проекте и честно заявляю что я тут максимум продвинутый Juniоr. Тут можно тратить по полдня пытаясь понять почему твой запрос в базу длится полчаса. Или почему на сервере закончилась память. Или почему отдельные потоки конфликтуют между собой. Развернуть проект локально это вообще тот еще квест. Нужно думать про всякие нагрузки, знать разные фреймворки, как рыба в воде чувствовать себя в консоли линукса. Вот это я понимаю разработка. Каждый день какие-то ребусы. На SF ребусы быстро заканчиваются и начинается монотонное формошлепство или исправление индусского кода.
Попробуй 1С версии 7.7 и тогда про питон ты будешь вспоминать теплыми словами и плакать с умилением, что где-то поставил лишний пробел и от этого упал код.
А с другой стороны, в ASP слабая сторона - это база данных. Ставишь SF как хранилище данных и делай охрененный проект под чем правится и как угодно.
Не удивил. С него начиналась моя карьера. Все было хорошо (обучение), пока я не дошел до того места где надо было понимать что такое дебиты и кредиты. И меня переклинило. Я в этом плане крайне специфический программист. Я все могу сделать в плане кода и инфраструктуры, но как только вопрос касается бизнес логики клиента у меня случается полный ступор. Когда мне втирают про всякие пейменты, инвойсы, заказы я сразу сливаюсь. А все потому что код и инфрастукрута серверов поддается хоть какой-то логике, а бизнес логика клиента можно объяснить только так
Архитектор от разработчика отличается тем что знает доменную область и может клиенту рассказать как должен работать его бизнесс.
А разработчик от архитектора отличается тем что знает технологии и ЯП и может написать то что навыдумывали клиент с архитектором
Всегда в обсуждениях вижу 2 точки зрения на тему кто такой архитектор:
1) просто консультант, который умеет ездить по ушам клиенту и знающий платформу в общем
2) супер опытный разработчик со знанием всего что только можно по его платформе. В итоге может выбирать самое оптимальное решение или отвечать, что данное требование невозможно сделать, если это действительно так.
п.с. я придерживаюсь 2й точки зрения.
Недавно статья на Онлайнере была про чувака, который впаривал людям фильтра и пошел в IT. Три года отработал и уже тимлид, при этом год как не пишет ничего. Я думаю это первый вариант. Ну, при этом, работают же как-то, прибыль получают....
Вот как раз продажников толковых в ИТ не хватает.
Что толку от 100 программистов которые день и ночь пишут супер код.
Другое дело когда есть один продажник который умудряется продать продукт которого еще нет!
Идеальных программистов перфекционистов ещё меньше, т.к. это почти нигде не ценится.
Все стараются продать кучку говна слепленную вчерашними стажёрами, чтобы максимум прибыли получить.
+
Серьезно? Человек, который знает как должно быть построено ПО будет рассказывать владельцу молочного комбината, как продавать молочные продукты и сколько они и при какой температуре должны храниться? Это чушь. Максимум, что ИТ специалист может сделать это поделиться информацией о том, как реализованы бизнес процессы на другом таком же молочном комбинате. И то... Это под вопросом... Коммерческая тайна.
АХАХАХА! А Андрей чертовки прав.
Исходя из его пояснения у меня родился новое определение для архитектор VS разработчик
Архитектор этот тот кто может понять клиента и перевести его хотелки на язык программиста.
У разработчиков с пониманием клиентов сложнее. Он может написать логику исходя из требования на его родном (программистском) языке, которые ему предоставляет архитектор.
Не соглашусь. Если брать ЧИСТО Архитектора, то он должен строить Архитектуру ПО, а не общаться с клиентом. Для трындежов есть Бизнес Оналитеги, который после общения с клиентом пишет:"
Пользователь должен мочь:
1) открыть бровзер, вбить login.salesforce.com, заполнить логин/пароль и попасть на Home Page, на которой должен быть расположен Dashboard с количеством Qualified Leads за текущий месяц.
2) ...
"
А вот Архитектор должен программисту написать, как эта задача должна решаться. Мол, ссделать сначала Репорт, птм Дашбоард, птм этот Дашбоард на Home Page запулить, настроить там профили и т.д. Но с клиентом никакого общения.
В том то же и смысл КОНСУЛЬТАНТА, что он и швец, и жнец, и на дуде игрец. Он один всё это делает. А в больших компаниях на каждый чих-пых есть отдельные люди.
У меня как у радового, хоть и продвитого программиста иногда сильно бомбит когда ко мне по цепочке нескольких архитекторов спускают требования типа "Для вип клиентов цена должна считаться с учетом скидок, для обычных без скидок". Ну как так-то? Если между мной и клиентом есть хоть одно звено, я сразу возвращаю такие требования на доработку. Я как разработчик должен видеть требования типа "Есть объект Client. На нем есть поле (boolean) bили его надо создать, исходя из которого надо взять объект Discount и вычесть из FinalPrice которое возвращает метод getPriceForItems()" Отличное понятное требоваени, которое можно легко реализовать. Вот этим должен заниматься разработчик. А архитектор должен сделать этот сурдоперевод.
Ха!
На счет Архитектора. Во многих источниках таки пишут, что общение с клиентом входит в их обязанности. Хорошо.
В роли консультантов у нас часто выступают девочки ПМ которые А+Б связать не могут, не то что понять что говорит клиент. Уже сто раз с этим сталкивался. 2-3 дня и клиент доведенный до белого каления из-за задачи которая решается за 10 минут.
Хороший консультант это уже Архитектор
Я про таких Консультантов как я говорю :-)
Девочка ПМ, которая ни разу не видела СФ в глаза и общаться с склиентом на тему разработки в СФ - это Double Facepalm.
СФ проект, в который пришел в компанию, где начал заниматься СФ, был под "крылом" ПМа, который сам не знал, что такое СФ. Он к нам приходил и просил всё показать и объяснить. Первые месяцы он приходил и всё у нас выпытывал, пока не познал СФ на достаточном уровне.
И че? реально познал?
Хороший Консультант - это всё :-)
Ну как ты можешь давать консультации, если не знаешь, как правильно/хорошо реализовать хотелку клиента.
Ну вот пример задачи.
Надо инфу о Лидах в момент конвертации высылать на стороний сервис. Если сервис вернет ошибку - не конвертировать Лида на стороне СФ.
Консусльтант должен понимать, что с спомощью стандартного диалога и отсылкой запроса на стороний сервис из триггера дело не решится. Надо сделать свою страничку, в контролере которой можно сделать API Callout, обработать его и решить, конвертировать Лида или нет.
Горе-консусльтант может же предложить делать API Callout из триггера, а птм в какой-нить Scheduled Job проверять, не вернул ли запрос ошибку и откатывать Лида назад, высылая уведомления владельцу Лида. Ну или ещё какую ересь.
Создавать записи, отчеты и понимать, что после сохранения записи, в эту запись может прилететь новые данные (из трегера/workflow) он уяснил. Как посмотреть возможные значения в picklist для определенного объекта/поля... Не, там всё в порядке было. Хоть мы и на прямую общались с клиентами :-)
Проект по-этому и закрылся, что компания пыталась навязать ПМ, БА, тестировщиков. А клиенту этого не надо было. Ему нужны были всего-навсего 2-3 программера.
