Новые возможности .NET для классических приложений
Это содержимое является отрывком из электронной книги, модернизации классических приложений на Windows с .NET 6, доступной в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
Сборку классических приложений, например Windows Forms и WPF, можно выполнить с помощью различных платформ .NET: .NET Framework, .NET Core, .NET 5, .NET 6. В этой главе мы расскажем об истории каждой платформы, опишем различия между ними и покажем, какие новые функции доступны разработчикам классических приложений в .NET 6.
Если вы имеете большой опыт разработки приложений Windows Forms или WPF, вы наверняка знакомы с .NET Framework. Несколько лет назад в новой платформе .NET Core (а именно версия 3.0) была реализована поддержка классических приложений. Следующая версия .NET Core была переименована в .NET 5, и теперь мы выпускаем ее обновление — .NET 6. Аналогично тому, как существуют различные версии .NET Framework, например 4.6, 4.7 и 4.8, существуют и различные версии .NET Core: .NET Core 3, .NET 5 и .NET 6. Мы рекомендуем использовать последнюю версию, .NET 6, особенно потому, что это версия с долгосрочной поддержкой, которую корпорация Майкрософт будет поддерживать в течение трех лет.
Теперь ознакомимся с историей каждой платформы, чтобы понять различие между ними и их преимущества.
Мотивы создания .NET Core
С момента своего запуска в 2002 году платформа .NET Framework продолжала развиваться для поддержки многих технологий, таких как Windows Forms, ASP.NET, Entity Framework, Windows Store и других. Все они разные по своей природе. Поэтому корпорация Майкрософт двигалась в направлении этой эволюции, беря части .NET Framework и создавая свой стек приложений для каждой технологии. Таким образом, возможности разработки можно было настраивать для нужд конкретного стека, что максимально увеличивало потенциал каждой платформы. Это привело к фрагментации версий .NET Framework, поддерживаемых разными независимыми командами. Все эти стеки имеют общую структуру, содержащую модель приложения, платформу и среду выполнения, но реализованы эти части по-разному.
Если вас интересует только одна из этих платформ, вы можете использовать данную модель. Однако во многих случаях в одном решении может требоваться более одной целевой платформы. Например, ваше приложение может иметь классическую административную часть, ориентированный на клиентов веб-сайт, который использует ту же логику, работающую на сервере, и даже мобильный клиент. В этом случае вам понадобится единый процесс кодирования, который может охватывать все эти вертикали .NET.
К тому времени, когда была выпущена Windows 8, родилась концепция переносимых библиотек классов (PCL). Первоначально платформа .NET Framework создавалась исходя из предположения, что она всегда будет разворачиваться как единое целое, поэтому проблема факторинга не стояла. Обратить внимание на проблему разделения кода между вертикалями заставил вопрос рефакторинга платформы. Идея контрактов заключается в предоставлении качественно разделенной поверхности API. Контракты — это просто сборки, которые вы компилируете и проектируете с учетом соответствующего факторинга, не забывая о зависимостях между ними.
Это приводит к оценке различий API между вертикалями на уровне сборки, а не на уровне отдельных API, которая практиковалась ранее. Этот аспект породил концепцию библиотеки классов, которая может работать с несколькими вертикалями. Такие библиотеки называются переносимыми библиотеками классов (PCL).
Благодаря PCL процесс разработки унифицирован по вертикалям на основе структуры API. Кроме того, разрешается самая актуальная потребность в создании библиотек, работающих в разных вертикалях. Но существует сложная проблема: интерфейсы API переносимы только тогда, когда реализация продвигается по всем вертикалям.
Лучший подход заключается в унификации реализаций по вертикалям путем предоставления хорошо продуманной реализации вместо хорошо продуманного представления. Гораздо проще попросить каждую команду, владеющую конкретным компонентом, заранее обдумать работу их API во всех вертикалях, чем пытаться задним числом предоставить согласованный стек API на верхнем уровне. И здесь на помощь приходит .NET Standard. Подробнее об этом говорится в следующем разделе.
Еще одна большая проблема связана с порядком развертывания .NET Framework. .NET Framework — это платформа уровня компьютера. Любые внесенные в нее изменения влияют на все зависимые от нее приложения. Хотя эта модель развертывания имеет много преимуществ, таких как сокращение занимаемого дискового пространства и централизованный доступ к службам, в ней имеются и кое-какие подводные камни.
Во-первых, разработчикам приложений сложно полагаться на недавно выпущенную платформу. Им приходится либо зависеть от последней версии ОС, либо предоставлять установщик приложения, который устанавливает .NET Framework вместе с приложением. Если вы веб-разработчик, у вас может даже не быть этой возможности, так как ИТ-отдел устанавливает версию, поддерживаемую сервером.
Даже если вы готовы проработать проблему предоставления установщика, включающего установку .NET Framework, вы можете столкнуться с тем, что обновление .NET Framework нарушает работу других приложений.
И хотя предпринимались попытки предоставления обратно совместимых версий платформы, существуют совместимые изменения, которые тем не менее могут нарушать работу приложений. Например, добавление интерфейса в существующий тип может изменить способ сериализации этого типа и вызвать критические проблемы, зависящие от существующего кода. Поскольку установленная база NET Framework огромна, борьба с этими разрушительными сценариями замедляет темпы инноваций внутри .NET Framework.
Для решения всех этих проблем корпорация Майкрософт разработала .NET Core, чтобы двигаться в направлении развития платформы .NET.
Введение в .NET Core
.NET Core — это развитие технологии Майкрософт .NET в модульную кроссплатформенную среду с открытым кодом, готовую к развертыванию в облаке. Эта среда работает в Windows, macOS и Linux, и планируется, что она также будет работать в архитектурах на базе ARM, таких как Android и IoT.
Целью .NET Core является обеспечение единой платформы для всех типов приложений, в том числе приложений Windows, кроссплатформенных и мобильных приложений. .NET Standard обеспечивает это, предоставляя общие базовые API, необходимые каждой модели приложения, и исключая API, связанные с конкретной моделью приложения.
Такая платформа обеспечивает множество преимуществ с точки зрения эффективности и производительности приложений, упрощая упаковку и развертывание на различных поддерживаемых платформах.
Преимущества .NET Core проистекают из следующих трех характеристик.
- Кроссплатформенность: позволяет запускать приложения на разных платформах (Windows, macOS и Linux).
- Открытый код: платформа .NET Core имеет открытый код и доступна через GitHub, что способствует прозрачности и позволяет сообществам вносить свой вклад.
- Поддерживаемость: корпорация Майкрософт официально поддерживает .NET Core.
Начиная с .NET Core 3.0 помимо уже существующей поддержки Интернета и облака появилась также поддержка настольных компьютеров, IoT и ИИ. Цель этой платформы впечатляет: охватить все типы разработки .NET, как существующие, так и те, которые появятся в будущем. Майкрософт планирует реализовать это видение с помощью .NET 5 в конце 2020 года. Чтобы подчеркнуть уникальность этой платформы в мире .NET, слово «Core» из названия было удалено.
.NET 5 — это .NET Core vNext
.NET 5 — это дальнейшее развитие .NET Core. .NET 5 предназначена для улучшения .NET в нескольких ключевых направлениях:
- создание одной среды выполнения и платформы .NET, которую можно использовать везде, с единообразными возможностями для разработчиков и поведением во время выполнения;
- расширение возможностей .NET за счет лучших функций .NET Core, .NET Framework, Xamarin и Mono;
- создание продукта на основе единой базы кода, которую разработчики (корпорация Майкрософт и участники сообщества) могут улучшать и развивать вместе.
Этот новый выпуск и его направленность — настоящий прорыв для .NET. С .NET 5 ваш код и файлы проекта будут выглядеть одинаково независимо от того, какое приложение вы создаете. У вас будет доступ к одной и той же среде выполнения, API и языковым возможностям для каждого приложения. Это включает и новые улучшения производительности, которые вносятся во время выполнения практически ежедневно. Дополнительные сведения см. в статье о новых возможностях .NET 5.
.NET 6 — это версия с долгосрочной поддержкой
Корпорация Майкрософт перешла на новую модель выпусков, в рамках которой в ноябре каждого года мы выпускаем новую версию .NET. Каждая версия с четным номером будет выпуском с долгосрочной поддержкой (LTS), то есть корпорация Майкрософт будет поддерживать ее в течение трех лет.
В .NET 6 мы реализовали множество улучшений надежности, производительности, новые API и функции языка. Это новая, улучшенная и более стабильная версия для классических приложений, которую мы будем поддерживать несколько лет. Поэтому мы рекомендуем вам обновить свои приложения до этой версии, и в следующей главе вы узнаете, как сделать это.
Различия .NET Framework и .NET
Теперь, когда вы понимаете важность .NET, вам может быть интересно, что происходит с .NET Framework. Возможно, у вас возникли вопросы, например: не пора ли отказаться от этой платформы? Не исчезнет ли она? Как модернизировать свои приложения, разработанные в .NET Framework?
В 2019 году была выпущена последняя версия .NET Framework — 4.8. В нее вошли три следующих важных усовершенствования для классических приложений.
- Современный браузер и элементы управления мультимедиа. В настоящее время классические приложения .NET используют Internet Explorer и Windows Media Player для отображения HTML и воспроизведения файлов мультимедиа. Так как устаревшие элементы управления не работают с последней версией HTML и не воспроизводят новейшие файлы мультимедиа, были добавлены новые элементы управления, которые используют преимущества Microsoft Edge и новых проигрывателей мультимедиа, поддерживающих самые современные стандарты.
- Доступ к элементам управления UWP. UWP содержит новые элементы управления, использующие преимущества новейших функций Windows и сенсорных дисплеев. Вам не нужно переписывать свои приложения, чтобы использовать эти новые функции и элементы управления — можно просто применять эти новые функции в существующем коде WPF или Windows Forms.
- Усовершенствования для HDPI. Разрешение современных экранов выросло до 4K и 8K. Поэтому в .NET Framework 4.8 добавлены новые усовершенствования HDPI, чтобы ваши существующие приложения Windows Forms и WPF отлично смотрелись на этих новых экранах.
Так как платформа .NET Framework установлена на миллионах компьютеров, Майкрософт продолжит ее поддерживать, но новые функции добавляться не будут.
.NET 5 — это кроссплатформенная и быстро развивающаяся версия семейства .NET с открытым кодом. Так как она изначально параллельна, внесение изменений не влечет за собой риск нарушения работы какого-либо приложения. Это означает, что в .NET со временем будут появляться новые API и языковые функции, которых не будет в .NET Framework. Кроме того, в .NET уже есть функции, недоступные для .NET Framework, например следующие.
- Параллельные версии .NET, поддерживающие Windows Forms и WPF: это решает проблему побочных эффектов при обновлении версии платформы компьютера. На одном компьютере можно установить несколько версий .NET, и каждое приложение указывает, какую версию .NET оно должно использовать. Более того, теперь вы можете разрабатывать и запускать Windows Forms и WPF поверх .NET.
- Встраивание .NET непосредственно в приложение. Вы можете развертывать .NET как часть своего пакета приложения. Это позволяет вам использовать все преимущества, функции и API последней версии, не дожидаясь установки этой версии на компьютере.
- Использование преимуществ возможностей .NET. .NET Core — это быстро развивающаяся версия .NET с открытым кодом. Ее параллельный характер позволяет быстро внедрять новые передовые API и улучшения библиотек базовых классов (BCL) без риска нарушения совместимости. Теперь приложения Windows Forms и WPF могут использовать преимущества новейших функций .NET, которые также включают более фундаментальные исправления для повышения производительности среды выполнения, поддержки высокого разрешения и т. д.
В плане Майкрософт также большое значение придавалось стремлению облегчить разработчикам перенос приложений на .NET Core, а затем и на .NET 5. Но если у вас есть существующие приложения .NET Framework, вас никто не принуждает переходить на .NET 5. .NET Framework будет полностью поддерживаться и всегда будет частью Windows. Тем не менее, если в будущем вы захотите использовать новейшие языковые функции и API, вам придется перенести свои приложения в .NET.
Что касается разработки совершенно новых классических приложений, мы рекомендуем сразу начинать с .NET 5. Эта удобная и универсальная платформа, поддерживающая параллелизм, отличается высокой производительностью и идеально подходит для архитектур контейнеров и микрослужб.
Сравнительный анализ .NET Standard и PCL
.NET Standard — это официальная спецификация API .NET, которые должны быть доступны во всех реализациях .NET. .NET Standard используется для обеспечения согласованности экосистемы .NET. .NET Standard — это спецификация интерфейсов API в .NET, которые составляют единый набор контрактов для компиляции вашего кода. Эти контракты реализованы в каждом варианте .NET, что обеспечивает переносимость между разными реализациями .NET.
.NET Standard предоставляет следующие важные возможности:
- Определяет унифицированный набор API библиотек базовых классов для всех необходимых реализаций .NET, независимо от рабочей нагрузки.
- Позволяет разработчикам создавать переносимые библиотеки, которые могут использоваться в разных реализациях .NET, с помощью одного набора API-интерфейсов.
.NET Standard — это развитие PCL, и в следующем списке показаны фундаментальные различия между .NET Standard и PCL.
- .NET Standard — это набор курируемых API, выбранных Майкрософт. PCL — нет.
- API, содержащиеся в PCL, зависят от платформ, которые вы выбираете при создании. Это позволяет использовать PCL только в определенных целях, выбранных вами.
- .NET Standard не зависит от платформы и может работать где угодно: в Windows, macOS, Linux и т. д.
- Библиотеки PCL также могут работать на разных платформах, но их охват более ограничен. PCL могут быть предназначены только для ограниченного ряда платформ.
Новые возможности классических приложений в .NET
Поддержка Windows Forms и WPF
Windows Forms и WPF являются частью .NET Core начиная с версии 3.0. Обе платформы представления предназначены только для Windows, поэтому они не являются кроссплатформенными. WPF можно представить как обширный слой над DirectX, а Windows Forms — как более тонкий слой над GDI+. WPF и Windows Forms отлично справляются с предоставлением и применением большей части функциональных возможностей классических приложений в Windows. Таким образом, Windows Forms и WPF доступны для .NET Core и .NET Framework. Теперь вы можете запускать новые классические приложения, ориентированные на .NET Core, и переносить существующие приложения с .NET Framework на .NET Core.
Новая версия .NET Standard 2.1 была выпущена одновременно с .NET Core 3.0. Как и ожидалось, версии .NET Core 3.x поддерживают .NET Standard 2.1 и более ранние версии.
Также важно отметить, что реализации Windows Forms и WPF для .NET Core имеют открытый код.
XAML Islands
XAML Islands — это набор компонентов, позволяющих разработчикам использовать новые элементы управления Windows 10 (элементы управления XAML UWP) в своих текущих приложениях WPF, Windows Forms и собственных приложениях Win32 (таких как MFC). Вы можете располагать свои «острова» элементов управления XAML UWP где угодно внутри ваших приложений Win32.
Эти острова XAML стали возможны потому, что в Windows 10 версии 1903 появился набор API, которые позволяют размещать содержимое XAML UWP в окнах Win32 с помощью обработчиков окон (HWnds). Обратите внимание, что использовать XAML Islands могут только приложения, работающие в Windows 10 версии 1903 и более поздних версий.
Чтобы упростить создание XAML Islands для разработчиков Windows Forms и WPF, в набор инструментов сообщества Windows был включен ряд программ-оболочек .NET в нескольких пакетах NuGet. Эти программы-оболочки представляют собой элементы управления упаковкой и размещением.
- Элементы управления упаковкой WebView, WebViewCompatible, InkCanvas, MediaPlayerElement и MapControl переносят некоторые элементы управления XAML UWP в элементы управления Windows Forms или WPF, скрывая концепции UWP для их разработчиков.
- Элемент управления WindowsXamlHost для Windows Forms и WPF позволяет загружать в остров XAML другие элементы управления XAML UWP и пользовательские элементы управления, не заключенные в оболочку.
Доступ ко всем API Windows 10
В Windows 10 имеется множество API, с которыми могут работать разработчики. Эти API предоставляют доступ к широкому спектру функций, таких как проверка подлинности, Bluetooth, встречи и контакты. Теперь эти API доступны через .NET Core и позволяют разработчикам Windows создавать мощные классические приложения, использующие возможности Windows 10.
Поддержка параллельного выполнения и автономные EXE-файлы
Модель развертывания .NET Core — представляет одно из самых больших преимуществ, которые разработчики классических приложений Windows получат от .NET Core. Возможность глобальной установки .NET Core обеспечивает многие из тех же преимуществ централизованной установки и обслуживания, что и .NET Framework, при этом не требуя обновлений на месте.
После выпуска новой версии .NET Core вы можете обновлять каждое приложение на компьютере по мере необходимости, не беспокоясь о влиянии на другие приложения. Новые версии .NET Core устанавливаются в свои собственные каталоги и существуют «параллельно» друг с другом.
Если вам нужно выполнить развертывание с изоляцией, вы можете развернуть .NET Core вместе со своим приложением. .NET Core объединит ваше приложение со средой выполнения .NET Core в пакет как в один исполняемый файл.
Подобные варианты развертывания запрашивались разработчиками довольно давно, но их было сложно реализовать с помощью .NET Framework. Модульная архитектура, используемая .NET Core, сделала эти гибкие варианты развертывания возможными.
Производительность
С момента своего создания, ориентированного на рабочие нагрузки в Интернете и облаке, .NET Core имеет внутренне присущую производительность. Серверный код должен быть достаточно производительным, чтобы выполнять сценарии с высоким уровнем параллелизма, а платформы семейства .NET Core, в том числе .NET 6, сегодня оцениваются как самые производительные веб-платформы из представленных на рынке.
В .NET 5 и .NET 6 мы рефакторингировали старый код Windows Forms, что привело к сокращению выделения памяти для рисования форм и элементов управления, поэтому просто обновление с платформа .NET Framework до .NET 6 ваших приложений становится гораздо быстрее. Вы можете воспользоваться преимуществами этих улучшений производительности, создавая на базе .NET классические приложения нового поколения.
Преимущества открытого кода
Несколько слов об открытом коде .NET Core. Создание кроссплатформенного стека — сложная задача, требующая взаимодействия специализированных команд на каждой из целевых платформ. Для этого необходимо активное сотрудничество как в самой корпорации Майкрософт, так и за ее пределами. Открытый код делает возможным самое широкое сотрудничество, в результате обеспечивая идеальный стиль гибкой разработки и поднимая планку качества, так как проблемы выявляются огромным и активным сообществом разработчиков.
Это ключевой фактор успеха .NET Core, который продолжит ускорять реализацию упомянутой ранее стратегии: создать единую платформу .NET, которая будет нужна каждому разработчику для создания любого приложения.
В чем разница между NetFramework и NetCore
При попытке подключить библиотеку к uwp приложению получил вот такое предупреждение: «Проект предназначен для «.NetCore», в то время как ссылка файла предназначена для «.NetFramework»» 
Вроде, и то платформа, и то платформа, так в чем разница, зачем их две и возможна ли связь между ними (подключать одно к другому и наоборот)?
.NET Framework — это старая платформа, работающая только под Windows.
.NET Core — это новая платформа, которая может работать как под Windows, так и под Linux. Но она еще довольно «сырая» — множество инструментов еще не перенесены на нее.
Подключить одно к другому не получится, потому что у них разные системные библиотеки (а также разные системы сборки если вы используете Visual Studio версии 2015 или ниже).
Кроме них, есть еще платформы:
Mono — может работать как под Windows, так и под Linux. Пытается быть совместимой с .NET Framework.
UWP — платформа для написания Windows-приложений, использующих WinRT. Не знаю про совместимость с .NET Framework.
Silverlight — старая платформа (застряла примерно на уровне .NET 4.5), предназначенная для работы в браузере (вроде java-апплетов). Не так давно была серьезно ранена гуглом, который перестал поддерживать NPAPI в своем Хроме. Не совместима с .NET Framework.
.NET Compart Framework — несовместимая вариация .NET Framework для Windows CE. Сейчас находится на той же свалке, куда был выброшен Windows CE.
Unity — форк Mono, платформа для написания графических (в том числе 3D) приложений. Есть вариант встраивания в браузер (не работает в Хроме из-за отказа от NPAPI в Хроме работает благодаря технологии Web Assembly).
PCL (Portable Class Library) — общее подмножество разных версий .NET Framework, UWP и Silverlight. Совместима с ними в одну сторону (PCL-библиотеку можно использовать на перечисленных платформах).
.NET Standard — новая реинкарнация PCL. От PCL отличается подходом к версионированию: если для PCL разработчик библиотеки выбирает список поддерживаемых платформ, то для .NET Standard выбирается версия стандарта (а для платформ известно какие версии ими поддерживаются).
Что такое .NET Core?
.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.
Опыт разработчиков
Есть ещё один, возможно, неожиданный фактор, влияющий на целесообразность портирования приложений в другую операционную систему. — Это накопленный опыт разработчиков.
Да, конечно, люди способны к обучению и переобучению. Но и то, и другое требует времени, а значит и расходов. Если нужно быстро воспроизвести функциональность, уже реализованную в другой операционной системе, можно либо сформировать новую команду разработчиков, либо воспользоваться средствами портирования приложения.
Достаточно очевидно, что при наличии необходимых средств портирование будет намного быстрее и экономические эффективнее.
Заключение
Формально модульная архитектура снижает быстродействие системы в целом. Но при этом увеличивается её гибкость, повышается надёжность, сокращается срок её разработки, особенно при использовании уже готовых модулей.