Что такое .NET Core?

15.06.2018

.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. О чём ещё мы пишем в нашем блоге:

Зарегистрироваться