.NET Core — это горизонтальное развитие программной платформы .NET в другие операционные системы, в которых она обеспечивает возможность использования приложений, разработанных для Windows.
Несколько слов о .NET
Одна из существенных причин головной боли программистов — непредсказуемость условий, в которых будут запускаться написанные ими приложения. — Разная конфигурация аппаратной части, разные версии операционных систем, разные наборы библиотек, разные устройства, разные драйверы, …
Попытки как-то унифицировать среду выполнения приложений предпринимались, предпринимаются и будут предприниматься.
Мощной и довольно успешной попыткой унификации программной среды в операционной системе Windows является платформа .NET («дот нет»), разработанная компанией Microsoft в начале 2000-х годов.
Основная идея состояла в том, чтобы между операционной системой и приложением поместить программную прослойку, которая сглаживала бы особенности конкретного экземпляра операционной системы, обеспечивая приложению «идеальную» среду исполнения.
В рамках статьи мы не будем углубляться в технические детали этой прослойки. Желающие могут обратиться к её технической документации.
Очень упрощённо устройство .NET можно проиллюстрировать следующим рисунком.
Открытость
Как уже было сказано, платформа .NET является разработкой и собственностью компании Microsoft, но была и остаётся бесплатной в использовании.
В 2014 году для дальнейшей популяризации этой платформы была учреждена независимая организация: .NET Foundation. Программный код платформы был размещён в публичном репозитории GitHub и теперь распространяется как продукт с открытым исходным кодом.
Кроссплатформенность
Плохо ли, хорошо ли, но в компьютерном мире существует много разных операционных систем. Сегодня на потребительском рынке наиболее распространены три: Windows, macOS и Linux (с вариациями).
Разработчик удачного, востребованного пользователями приложения заинтересован в его распространении в разных операционных системах. Однако в большинстве случаев просто так запустить приложение, разработанное для другой операционной системы, невозможно — требуется его «портировать».
В каких-то ситуациях можно просто перекомпилировать исходный текст программы для новой операционной системы. Но в большинстве случаев такой трюк не проходит, и требуется переписывать программу целиком или какие-то её части. Именно так пришлось действовать компании Microsoft, когда в середине 90-х она захотела сделать свой Office доступным в MacOS.
Но адаптации исходного кода приложения можно избежать, если между ним и операционной системой будет находиться «стандартизирующая» прослойка. Например, … .NET. Тогда приложение, разработанное в одной операционной системе, можно будет без проблем запускать в другой. То есть вместо портирования отдельных приложений, можно портировать саму программную прослойку.
Так Microsoft и поступила. Правда, портировала она не текущую версию платформы .NET, существующую в ОС Windows, а некую производную от неё, которую назвала .NET Core.
В значительной степени её функциональность совпадает с функциональностью исходной .NET, но одновременно — в чём-то шире, а в чём-то уже. В целом, можно считать, что .NET и .NET Core совместимы друг с другом.
Несколько слов о .NET Core
Сейчас платформа .NET Core существует для трёх операционных систем: Windows, Linux и macOS. То есть приложение, разработанное на базе .NET Core, может быть без изменения запущено во всех операционных системах, в которых имеется указанная платформа.
Не будем лукавить, идеальная 100-процентная совместимость трудно достижима. В настоящее время на платформе .NET Core не реализованы Windows Forms, Windows Presentation Foundation (WPF), WebForms. Это означает, что приложения с развитым графическим интерфейсом портироваться таким способом в настоящее время не могут. Однако в информационных системах существует много задач, решение которых не требует пользовательского графического интерфейса.
А зачем что-то портировать?
Этот вопрос совсем не праздный. Ведь любые прослойки и надстройки снижают эффективность работы приложения. Они добавляют к нему программный код, который нужно исполнять и тратить дополнительное время. Кроме того, для своей устойчивой работы дополнительный код проектируется максимально универсальным, что также снижает его эффективность.
Что же подталкивает разработчиков переносить свои наработки в новую среду, вместо того, чтобы написать там новый «чистый» код с нуля?
Скорость разработки
Самые «быстрые» программы пишутся в машинных кодах. Точнее, на языке ассемблера, максимально приближенном к командам конкретного процессора. Этот язык используется и сейчас при разработке низкоуровневых системных элементов, например, драйверов разных устройств.
Однако решать таким способом высокоуровневые задачи абсолютно нереально. — Требуется агрегировать! Ведь при разработке автомобиля или холодильника никто двигатели заново не проектирует, а применяет подходящие из имеющихся в ассортименте, предлагаемом контрагентами.
Использование в программирование готовых элементов из ранее разработанных библиотек — обычная и правильная практика. Да, это снижает удельную эффективность программного кода, но позволяет решать сложные прикладные задачи в разумные сроки.
Побочное снижение эффективности кода с лихвой перекрывается продолжающимся ростом быстродействия вычислительной техники, повышением архитектурной гибкости и устойчивости приложений, возможностью групповой разработки.
Чем больше готовых агрегатов вы сможете использовать в своём проекте, тем быстрее он будет реализован.
Зрелость технологии
Уже в течение долгого периода компьютерный мир развивается колоссальными темпами. Во многом это связано с модульностью его устройства. Его элементы разрабатываются большим числом специалистов параллельно.
В любой текущий момент времени какие-то технологии уже достигли определённого совершенства, а другие — только зарождаются. Причём, степень зрелости одной и той же технологии в разных операционных системах может быть существенно разной.
В качестве примера такого асинхронного развития можно привести контейнеры приложений. Они доступны и в Windows, но исторически раньше возникли в ОС Linux, и там они более отработаны. Там их экосистема сейчас более развита.
Контейнеры широко применяются при реализации концепции микросервисов. Если ваши приложения, которые вы хотите использовать в режиме микросервисов, были изначально разработаны в Windows на основе .NET, у вас может возникнуть мысль упаковать их в контейнеры и запускать в Linux.
Опыт разработчиков
Есть ещё один, возможно, неожиданный фактор, влияющий на целесообразность портирования приложений в другую операционную систему. — Это накопленный опыт разработчиков.
Да, конечно, люди способны к обучению и переобучению. Но и то, и другое требует времени, а значит и расходов. Если нужно быстро воспроизвести функциональность, уже реализованную в другой операционной системе, можно либо сформировать новую команду разработчиков, либо воспользоваться средствами портирования приложения.
Достаточно очевидно, что при наличии необходимых средств портирование будет намного быстрее и экономические эффективнее.
Заключение
Формально модульная архитектура снижает быстродействие системы в целом. Но при этом увеличивается её гибкость, повышается надёжность, сокращается срок её разработки, особенно при использовании уже готовых модулей.
P.S. О чём ещё мы пишем в нашем блоге: