У дизайнеров было два выбора: либо молча сглатывать неохват паттерна делая default-init (иначе говоря, возвращать default(T) из свича у которого не замэтчился ни один паттерн) или же бросать исключение. Микрософт выбрали второе...
Во многих ФП языках ветка по умолчанию обязательна, и это тот третий и самый, на мой взгляд, логичный вариант.
Помню, в ранних черновиках для “Nullable Reference Types” было совершенно здравое предложение просто добавить символ “!” ко всем полям, переменным и тд. которые не могут быть null. По сути, это был бы аналог атрибута [NotNull]. Это решало бы проблему с null ref там, где ее надо решить и не ломало бы обратной совместимости.
Это совершенно не значит что код «процедурный». В функциональном программировании логика и данные всегда идут раздельно. Физически их можно запихать в один класс, но смысла в этом особого нет, т.к. все объекты этого класса неизменяемы.
У коллег по цеху уже сложилась четкая ассоциация, что модель — это в первую очередь модель данных. “Модель предметной области” это настолько размытое понятие, что вряд ли ему можно найти значимое практическое применение.
Причина почему НЕ надо хранить бизнес логику внутри модели, заключается в том, что эта самая логика сильно варьируется в разных сценариях (use cases), число и вариативность которых невозможно предсказать (если, конечно, у вас не “водопад”). Например, есть модель “Пользователь”: {id, login, name}. Субъект “Пользователь” может поменять только “name”, субъект “Администратор”, может поменять еще и “login”, но только в том случае если он уникальный, а какая-нибудь утилита интеграции может менять вообще все.
В модели должны быть представлены только абсолютные ограничения, которые в 99% случаев выражаются в виде отношений между моделями и типов атрибутов.
Судя по обилию минусов, то ли я не понял что-то, то ли не поняли меня.
В будущем останется только один .NET, и вы сможете использовать его для разработки под Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и другие платформы.
Насколько я понял, будет один набор API для всех платформ, но .Net Standard как раз и решал проблему, что разные фреймворки (Core, Mono и т.д.) не были полностью совместимы на уровне API.
Если будет один .Net на всех, то зачем тогда .Net Standard?
Я бы не сказал, что это не «основная», a другая проблема. И проблема ли — это вообще? Для простенькой CRUD админки можно создать API, который более-менее соответствует идеологии REST, или когда у нас API работает только как read-only, но если нужно предоставить доступ к сложной логике, то тут идиоматический REST часто буксует. Например, есть кнопка «Перевести неактивных пользователей в архив», а пользователей у нас 100 миллионов, и понятие «неактивный», тоже можно сделать очень сложными.
Я пробовал создавать self-contained приложение: dotnet publish -c release -r linux-arm64
Падало оно с теми же ошибками, что и рантайм. Собственно, почему должно быть иначе? Self-Contained просто тащит с собой рантайм, который не работает на целевой платформе.
WCF это не протокол и не стандарт. Это фреймворк позволяющий организовать коммуникацию между различными модулями одной системы или разными системами, и при этом эта коммуникация не зависит от какого-то одного протокола, и может подстраиваться под конкретные нужды так, например, если модули находятся на одной машине, то они могут общаться, используя named pipes и бинарный формат сообщений (очень быстрая сериализация).
Если надо разнести их по разным серверам, то заменяем в конфигурационном файле named pipes на tcp/ip и все работает.
Если нужен доступ извне, то добавляем новую точку доступа, работающую по SOAP over HTTP.
Поддержку gRPC тоже можно добавить в теории, и все это без необходимости менять код приложений.
вы имеете ввиду middleware asp.net core?
Да. +Еще создал свою реализацию IServer, которая собственно и слушала TCP порты.
Подобное позиционирование, с точки зрения заказчика, можно рассматривать как рекламу решения на GO, который занял свою нишу (веб-сервисы, dev-ops утилиты) и смотрится в ней очень привлекательно:
1. Низкий порог вхождения
2. Высокая производительность
3. Простота внедрения (один исполняемый файл, который работает практически везде)
Пример из жизни: захотел я для своего новенького домашнего роутера (ARM64) сделать небольшое веб приложение. Первым делом подумал поставить туда .Net core, но промучившись несколько дней, бросил это занятие – существующие сборки под ARM64 работать отказывались, оставалось только самому собирать .Net Core из исходников под операционную систему роутера. Я на это плюнул и решил искать альтернативы. PHP, NodeJS… и тут я вспомнил про GO, который без проблем (к моему удивлению) заработал на роутере, и вместо танцев с бубном я сразу начал писать свое приложение (попутно изучая новый для себя язык).
Теперь (хоть душою я за .Net) думаю, что в этой нише .Net вряд ли удастся сильно потеснить GO.
Вообще совершенно не обязательно тащить WCF как есть – можно адаптировать его для ASP.Net core. Я в свое время, забавы ради, написал свой Middleware который симулировал WCF сервис с net.tpc binding-ом и какие-то простые сценарии заработали.
Даже такая адаптация помогла бы перевести существующие WCF проекты на .Net 5, но Майкрософт, как всегда, забила на поддержку своих решений, которые в свое время преподносились как “Универсальное решение на все века, которое надо срочно начать всем использовать”.
«с нуля» это возможно слишком сильное определение, но я бы не назвал это «форком» в классическом понимании- все же в .Net Core 1 не было многих API из Framework, которые позже были добавлены в Core 2-3
Спасибо за схему! Только .Net Core не был ответвлением от .Net Framework, он был создан фактически с нуля.
.Net Core 2 и .Net Framework 4.7.2 стали совместимы через .Net Standard (можно нарисовать как мостик между двумя независимыми ветками)
Жаль, что WCF не попадет туда. Очень хотел бы его увидеть в будущем, пусть даже и в урезанном виде. Например, net.tcp чертовски удобен для внутреннего межсерверного взаимодействия.
Во многих ФП языках ветка по умолчанию обязательна, и это тот третий и самый, на мой взгляд, логичный вариант.
Нормальный паттерн матчинг — это единственное нововведение, среди пречисленных в статье, которое у меня вызывает однозначно положительную реакцию.
В модели должны быть представлены только абсолютные ограничения, которые в 99% случаев выражаются в виде отношений между моделями и типов атрибутов.
Насколько я понял, будет один набор API для всех платформ, но .Net Standard как раз и решал проблему, что разные фреймворки (Core, Mono и т.д.) не были полностью совместимы на уровне API.
Если будет один .Net на всех, то зачем тогда .Net Standard?
dotnet publish -c release -r linux-arm64Падало оно с теми же ошибками, что и рантайм. Собственно, почему должно быть иначе? Self-Contained просто тащит с собой рантайм, который не работает на целевой платформе.
Если надо разнести их по разным серверам, то заменяем в конфигурационном файле named pipes на tcp/ip и все работает.
Если нужен доступ извне, то добавляем новую точку доступа, работающую по SOAP over HTTP.
Поддержку gRPC тоже можно добавить в теории, и все это без необходимости менять код приложений.
Да. +Еще создал свою реализацию IServer, которая собственно и слушала TCP порты.
1. Низкий порог вхождения
2. Высокая производительность
3. Простота внедрения (один исполняемый файл, который работает практически везде)
Пример из жизни: захотел я для своего новенького домашнего роутера (ARM64) сделать небольшое веб приложение. Первым делом подумал поставить туда .Net core, но промучившись несколько дней, бросил это занятие – существующие сборки под ARM64 работать отказывались, оставалось только самому собирать .Net Core из исходников под операционную систему роутера. Я на это плюнул и решил искать альтернативы. PHP, NodeJS… и тут я вспомнил про GO, который без проблем (к моему удивлению) заработал на роутере, и вместо танцев с бубном я сразу начал писать свое приложение (попутно изучая новый для себя язык).
Теперь (хоть душою я за .Net) думаю, что в этой нише .Net вряд ли удастся сильно потеснить GO.
Исходники лежат на гит хабе под MIT лицензией.
Вообще совершенно не обязательно тащить WCF как есть – можно адаптировать его для ASP.Net core. Я в свое время, забавы ради, написал свой Middleware который симулировал WCF сервис с net.tpc binding-ом и какие-то простые сценарии заработали.
Даже такая адаптация помогла бы перевести существующие WCF проекты на .Net 5, но Майкрософт, как всегда, забила на поддержку своих решений, которые в свое время преподносились как “Универсальное решение на все века, которое надо срочно начать всем использовать”.
Собрать (скомпилировать), кстати, может и можно будет, но запустить — не выйдет.
.Net Core 2 и .Net Framework 4.7.2 стали совместимы через .Net Standard (можно нарисовать как мостик между двумя независимыми ветками)
Вот хороший вопрос! Так и хочется вставить картинку про 15 конкурирующих стандартов…