Перейти к основному содержимому

Типы приложений на платформе .NET

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Разработчику Архитектору

Типы приложений в .NET​

Сводная таблица​

ПриложениеОписаниеКогда использовать
Консольное приложениеПростейший тип, выводит результат в командную строкуДля обучения, CLI-утилит, демонов
ASP.NET CoreВеб-приложения и APIДля разработки сайтов, микросервисов, REST API
Razor PagesУпрощённая модель MVC с файлами .cshtmlДля небольших сайтов, где не нужен сложный контроллер
BlazorВеб-приложения на C# (в браузере через WebAssembly или серверный вариант)Для фронтенд-разработки на C#
Windows Forms (WinForms)Классические GUI-приложения WindowsДля легковесных десктоп-приложений
WPF (Windows Presentation Foundation)Современный подход к созданию десктоп-приложенийДля богатого интерфейса, MVVM-архитектуры
MAUI (Multi-platform App UI)Кроссплатформенные мобильные и десктоп-приложенияДля iOS, Android, Windows, macOS
XamarinПредшественник MAUI, позволяет писать под мобильные устройстваДля проектов, которые ещё не перешли на MAUI
ASP.NET MVCТрадиционный веб-фреймворк с разделением на модели, представления и контроллерыДля крупных сайтов
Worker ServiceФоновые сервисы (демоны)Для фоновой обработки данных, очередей
Class LibraryБиблиотека классовДля повторного использования кода между проектами
Unit Test ProjectПроект модульных тестовДля автоматизированного тестирования
Windows ServiceСервисы WindowsДля запуска в фоне без пользователя

Разбор​

Среда .NET, изначально задуманная как платформа для построения Windows-приложений, к настоящему времени трансформировалась в открытую, кроссплатформенную экосистему, способную поддерживать разработку приложений самого разного назначения — от простейших утилит командной строки до высоконагруженных распределённых систем. При этом ключевым архитектурным принципом остаётся целевая направленность: каждый тип приложения в .NET представляет собой осмысленную инженерную модель, определяющую структуру жизненного цикла, способ взаимодействия с окружением, границы ответственности и даже стиль проектирования кода.

Выбор типа приложения — это стратегическое решение, которое закладывает основу для всей последующей разработки. Неправильный выбор может привести к избыточной сложности, нарушению принципов разделения ответственности, неоптимальному использованию ресурсов или невозможности реализовать требуемую функциональность без радикальной перестройки архитектуры. Поэтому важно понимать что такое каждый тип, почему он существует, как он связан с другими, и в каких условиях его применение будет оправданным.

Ниже рассматриваются основные типы приложений, поддерживаемых в современной (.NET 6 и выше) и ближайшей предшествующей (.NET Framework, .NET Core) экосистемах, с акцентом на концептуальную ясность и практическую применимость.

Консольное приложение​

Консольное приложение — это наиболее простая и фундаментальная форма исполнения кода в .NET. Его суть сводится к запуску управляемого процесса, входной точкой которого является статический метод Main, и взаимодействию с внешней средой исключительно через стандартные потоки ввода-вывода: stdin, stdout, stderr. Такое приложение не создаёт окон, не требует графического интерфейса, не зависит от циклов обработки событий и не поддерживает прямое взаимодействие с пользователем, кроме как посредством текстовых команд и ответов.

Несмотря на кажущуюся примитивность, консольное приложение обладает рядом уникальных практических достоинств. Прежде всего — это полная изоляция от графической подсистемы операционной системы, что делает его легко портируемым на любую платформу с поддержкой .NET, включая серверные дистрибутивы Linux без графической оболочки. Во-вторых, консольные приложения легко интегрируются в цепочки командной строки, скрипты автоматизации и системы оркестрации — они естественным образом вписываются в Unix-подобные концепции «маленьких утилит, выполняющих одну задачу хорошо». Наконец, они чрезвычайно удобны для отладки, профилирования и тестирования, поскольку их поведение полностью детерминировано и легко наблюдаемо через логи и коды возврата.

Консольные приложения применяются в трёх основных сценариях. Первый — обучение и экспериментирование: именно с Console.WriteLine("Hello, World!") начинается путь большинства разработчиков, и именно в таком контексте проще всего изучать синтаксис языка, базовые конструкции, работу с типами и исключениями без дополнительной нагрузки от сложных фреймворков. Второй — создание CLI-утилит: инструментов командной строки для генерации кода, миграции баз данных, проверки конфигураций, конвертации форматов и так далее. Такие утилиты становятся частью повседневного инструментария разработчиков и DevOps-инженеров. Третий — реализация фоновых процессов, демонов или служб, которые запускаются по расписанию или в ответ на системные события и работают без прямого участия пользователя. В этом случае консольное приложение может быть обёрнуто в системную службу (например, в Windows — через sc create, в Linux — через systemd), либо выполняться в контейнере как основной процесс.

С технической точки зрения, в .NET 6 и выше консольное приложение может быть реализовано как в традиционной форме (с явным определением Main и класса), так и в «минимальной» форме — с использованием top-level statements. Это не просто синтаксический сахар: такая запись отражает архитектурную истину — в консольной утилите действительно нет необходимости в сложной иерархии классов. Логика может быть выражена последовательностью выражений, что повышает читаемость и уменьшает накладные расходы на инициализацию.

Важно подчеркнуть: консольное приложение не обязательно «простое». Оно может включать полноценные DI-контейнеры, логгирование, конфигурацию через appsettings.json, работу с базами данных и сетевыми API — всё это поддерживается штатными средствами .NET. Разница лишь в том, что отсутствует инфраструктура для обработки HTTP-запросов, отрисовки UI или реакции на пользовательские события.

ASP.NET Core​

ASP.NET Core — это кроссплатформенный, высокопроизводительный фреймворк для построения веб-приложений и сервисов. Он не является «версией ASP.NET для .NET Core» или «обновлённым ASP.NET» — это принципиально новая архитектура, созданная с нуля, хотя и сохраняющая совместимость с некоторыми концепциями предшественника. Ключевая особенность ASP.NET Core — модульность. В отличие от классического ASP.NET, где многие компоненты были «вшиты» в платформу, ASP.NET Core построен на основе композиции middleware — небольших программных компонентов, каждый из которых отвечает за определённый этап обработки HTTP-запроса.

Жизненный цикл приложения в ASP.NET Core начинается с хоста — объекта, отвечающего за инициализацию среды выполнения, загрузку конфигурации, настройку логгера и запуск сервера. Хост может быть универсальным (Generic Host), поддерживающим как веб-, так и невеб-сценарии (например, фоновые службы), или специализированным (Web Host), используемым только для веб-приложений. После инициализации хоста управление передаётся пайплайну middleware: запрос проходит через цепочку компонентов, каждый из которых может обработать его, изменить, передать следующему или завершить обработку. Именно здесь реализуются такие функции, как маршрутизация, аутентификация, сжатие, CORS, обработка статических файлов и, наконец, вызов пользовательского кода — контроллера, страницы Razor или компонента Blazor.

ASP.NET Core не диктует единой архитектуры приложения. Он предоставляет несколько программных моделей, позволяя разработчику выбрать ту, которая лучше соответствует задаче: MVC, Razor Pages, Minimal APIs, Blazor Server/Blazor WebAssembly. При этом все они работают поверх единого ядра, что упрощает миграцию между моделями и смешение подходов в рамках одного проекта.

Производительность ASP.NET Core — одна из его сильнейших сторон. Оптимизации на уровне Kestrel (встроенного кроссплатформенного HTTP-сервера), эффективное использование памяти, поддержка асинхронного ввода-вывода и возможность размещения без IIS делают его конкурентоспособным даже по сравнению с нативными решениями. Бенчмарки от TechEmpower регулярно показывают ASP.NET Core в числе лидеров по пропускной способности и времени отклика.

ASP.NET Core применяется везде, где требуется обработка HTTP-трафика: от корпоративных порталов и интернет-магазинов до микросервисов, API-шлюзов и облачных функций. Он поддерживает как традиционную серверную отрисовку страниц, так и SPA (Single Page Application) через предоставление RESTful или GraphQL API. Важно понимать, что ASP.NET Core — это платформа, а не фреймворк высокого уровня. Это значит, что разработчик может отказаться от всей логики маршрутизации и контроллеров и написать обработчик на уровне middleware — например, для обработки WebSockets или кастомного бинарного протокола поверх HTTP.

Razor Pages​

Razor Pages представляет собой программную модель веб-разработки, появившуюся в ASP.NET Core 2.0 как альтернатива традиционному MVC для сценариев, где логика страницы тесно связана с её представлением. В отличие от MVC, где контроллер отвечает за обработку запроса к набору страниц (например, ProductsController обслуживает /products/list, /products/create, /products/edit/5), Razor Pages следует принципу «одна страница — один файл-контроллер». Каждая страница — это пара файлов: .cshtml (представление с встроенным Razor-синтаксисом) и .cshtml.cs (файл кода, содержащий класс страницы, наследуемый от PageModel).

Такая структура устраняет избыточность, присущую MVC в простых случаях. Например, страница «Контакты», содержащая статическую информацию и простую форму обратной связи, не требует создания отдельного контроллера, трёх представлений (Index, Success, Error) и настройки маршрутов. В Razor Pages всё это размещается в одном логическом узле: файл /Pages/Contact.cshtml содержит HTML-разметку, а /Pages/Contact.cshtml.cs — обработку GET и POST-запросов, валидацию модели, вызов сервисов.

Razor Pages не отвергает принципы разделения ответственности. Напротив, он укрупняет границу ответственности до уровня отдельной страницы, что часто соответствует реальной бизнес-логике: пользователь взаимодействует со «страницей редактирования продукта». При этом сложная логика по-прежнему выносится в сервисы, внедряемые через DI, а PageModel остаётся тонким посредником между представлением и доменом.

Razor Pages особенно эффективен при разработке информационных сайтов, внутренних корпоративных приложений, административных панелей — там, где основной акцент делается на контенте и простых формах, а не на сложных SPA-взаимодействиях. JavaScript можно свободно подключать, а Razor может генерировать JSON для инициализации клиентского состояния. Однако ключевое преимущество — минимизация количества файлов и упрощение навигации в кодовой базе при сохранении всех преимуществ ASP.NET Core: маршрутизации, DI, конфигурации, безопасности.

Razor Pages - осознанный архитектурный выбор, поддерживаемый командой Microsoft как полноценная и рекомендуемая модель для соответствующих сценариев. Даже в крупных приложениях часто встречается гибридный подход: основная часть — на MVC или Blazor, а административные разделы — на Razor Pages.

Blazor​

Blazor — это программная модель для построения интерактивных веб-интерфейсов с использованием C# и .NET, а не JavaScript. Это продуманная архитектурная альтернатива, позволяющая перенести значительную часть клиентской логики на язык, уже используемый на сервере, при этом сохраняя совместимость с современными веб-стандартами.

Существуют два режима хостинга Blazor-приложений: Blazor Server и Blazor WebAssembly. Несмотря на внешнее сходство — один и тот же C#-код компонентов, единая модель компонентов, одинаковый набор директив Razor — эти режимы принципиально различаются по архитектуре, требованиям к инфраструктуре и характеристикам производительности.

Blazor Server использует SignalR для установления постоянного двунаправленного соединения между браузером и сервером. Вся логика компонентов исполняется на сервере: при взаимодействии пользователя (нажатие кнопки, ввод текста) событие сериализуется и отправляется на сервер, там обрабатывается, обновляется состояние компонента, и изменения DOM-дерева (в виде дельты) возвращаются клиенту и применяются с помощью лёгкого JavaScript-движка (Blazor Boot). Преимущества такого подхода — минимальный размер клиентской загрузки (только HTML, CSS и небольшой JS-бандл), полный доступ к серверным API и .NET-библиотекам без необходимости их портирования, высокая скорость выполнения C# по сравнению с интерпретируемым JS. Недостатки — зависимость от стабильного соединения (повторное подключение приводит к пересозданию компонентов), увеличенная нагрузка на сервер (каждое соединение удерживает память и поток), и потенциально большая задержка при высоких значениях latency.

Blazor WebAssembly, напротив, полностью переносит выполнение на сторону клиента. Специальная версия .NET — Mono, скомпилированная в WebAssembly — загружается в браузер и исполняет C#-код непосредственно в песочнице браузера. Это означает, что приложение работает автономно после начальной загрузки: все взаимодействия происходят локально, без постоянного соединения с сервером. Для обращения к внешним данным используются стандартные HTTP-запросы (через HttpClient) или WebSockets. Преимущества — высокая отзывчивость (отсутствие round-trip на каждое событие), масштабируемость (сервер несёт нагрузку только при вызове API), возможность работы offline (при соответствующей настройке кэширования). Недостатки — большой первоначальный размер загрузки (несколько мегабайт: runtime, BCL, сборки приложения), более низкая производительность вычислений по сравнению с нативным кодом или Blazor Server, ограничения безопасности (код виден в DevTools, нет прямого доступа к файловой системе или другим ресурсам вне песочницы).

Оба режима используют единую компонентную модель. Компонент Blazor — это переиспользуемый, самодостаточный блок пользовательского интерфейса, инкапсулирующий разметку (в формате Razor — HTML с C#-вставками), состояние (поля и свойства класса) и логику (методы обработки событий, жизненного цикла). Компоненты могут быть вложенными, параметризованными и взаимодействовать через события и привязки данных. Эта модель вдохновлена подходами React и Vue, но реализована на основе .NET-концепций: компонент — это класс, наследуемый от ComponentBase, а не функция или объект.

Blazor не требует отказа от JavaScript. Для интеграции с существующими JS-библиотеками (например, картами, графиками, медиаплеерами) предусмотрен механизм JavaScript Interop: вызов JS-функций из C# и наоборот, передача данных в обе стороны. Это позволяет постепенно внедрять Blazor в существующие проекты или использовать лучшие инструменты из обоих миров.

Применяется Blazor там, где важна единая технологическая стек-платформа: когда команда уже владеет C#, но нуждается в богатом клиентском интерфейсе. Это особенно ценно в корпоративных средах, где разработчики часто специализируются на бэкенде, а фронтенд остаётся «узким местом». Blazor позволяет им писать клиентский код без глубокого погружения в экосистему JavaScript, при этом не жертвуя современными возможностями веба. Он подходит как для внутренних инструментов (админки, дашборды), так и для публичных приложений — при условии учёта особенностей выбранного режима хостинга.

Windows Forms (WinForms)​

Windows Forms — это программная модель для создания настольных приложений с графическим интерфейсом, появившаяся ещё в .NET Framework 1.0 (2002 г.) и остающаяся актуальной в .NET 6+. Это зрелая, стабильная и крайне практичная платформа, основанная на концепции контролов и событийной модели.

Архитектура WinForms построена на обёртке над нативным Windows API, в первую очередь — над компонентом User32. Каждый элемент интерфейса (кнопка, текстовое поле, список) — это экземпляр класса, наследуемого от Control, который в свою очередь управляет жизненным циклом соответствующего HWND (handle окна). Это обеспечивает высокую производительность и полную совместимость с другими Windows-приложениями, но накладывает ограничения: внешний вид элементов управления определяется операционной системой и темой оформления, а не приложением. WinForms не поддерживает современные графические эффекты (тени, анимации, векторную графику) «из коробки» — для этого требуются сторонние библиотеки или ручная реализация через GDI+.

Процесс разработки в WinForms обычно происходит в два этапа. Сначала — визуальное проектирование: разработчик перетаскивает элементы с панели Toolbox на форму в конструкторе Visual Studio. Конструктор генерирует код инициализации (обычно в *.Designer.cs), скрывающий детали создания и размещения контролов. Затем — написание логики: обработка событий (клик по кнопке, изменение текста), работа с данными, вызов сторонних сервисов. Модель событий здесь прямолинейна: каждое взаимодействие пользователя порождает событие, подписка на которое выглядит как метод-обработчик с префиксом EventHandler.

Особенность WinForms — это отсутствие строгой привязки к архитектурным паттернам. Приложение может быть написано в стиле «код за формой» (всё в одном классе), а может использовать MVVM, MVP или MVC при помощи сторонних фреймворков или ручной реализации. Это даёт гибкость, но требует дисциплины: без явного разделения слоёв легко получить «спагетти-код», где логика бизнес-правил переплетается с обработкой ввода и обновлением UI.

WinForms применяется там, где требуется быстро создать рабочее приложение для Windows с минимальными затратами. Это типично для внутренних инструментов: утилит миграции данных, конфигураторов, отладчиков, панелей мониторинга. Его сильные стороны — скорость разработки (особенно для UI-прототипов), низкий порог входа для .NET-разработчиков, стабильность (редкие и обратно совместимые изменения), и почти полное отсутствие внешних зависимостей. Приложение на WinForms — это один или несколько исполняемых файлов и DLL, не требующих установки среды выполнения помимо .NET.

Важно не путать WinForms с «простыми» или «непрофессиональными» приложениями. Многие промышленные системы, ERP-модули, медицинские и инженерные программы построены именно на этой платформе — и продолжают успешно развиваться в .NET 6/7/8 благодаря активной поддержке Microsoft и сообщества (например, через проект WinForms Community Toolkit).

WPF (Windows Presentation Foundation)​

WPF — это следующее поколение графических приложений для Windows, представленное в 2006 году как часть .NET Framework 3.0. В отличие от WinForms, WPF не является обёрткой над User32. Он построен на собственном графическом движке, использующем DirectX для рендеринга, что позволяет реализовывать сложные визуальные эффекты: прозрачность, тени, анимации, 3D-преобразования, векторную графику и произвольные шейдеры. Но ключевое отличие — в архитектурной философии.

Основа WPF — это декларативный язык разметки XAML (eXtensible Application Markup Language). Вместо imperative-кода создания контролов («создать кнопку, установить ей позицию, назначить обработчик»), интерфейс описывается как древовидная структура элементов: <Window><StackPanel><Button Content="OK"/></StackPanel></Window>. XAML — это полноценный способ выражения объектной модели приложения, с поддержкой привязок данных, ресурсов, стилей, шаблонов и поведений. Компилятор XAML генерирует C#-код, который затем объединяется с «code-behind», обеспечивая строгую типизацию и поддержку IntelliSense.

Центральной концепцией WPF является привязка данных (data binding). Вместо ручного копирования значений между моделью и UI (textBox.Text = user.Name), данные связываются декларативно: <TextBox Text="{Binding Name}"/>. Механизм привязки автоматически следит за изменениями (при реализации INotifyPropertyChanged), поддерживает конвертеры, валидацию, режимы (OneWay, TwoWay, OneTime) и работает с текстом и со сложными свойствами вроде Visibility, Background, ItemsSource.

Это делает WPF идеальной платформой для реализации MVVM (Model–View–ViewModel) — архитектурного паттерна, разделяющего:

  • Model — бизнес-логику и данные,
  • View — XAML-разметку, пассивное отображение,
  • ViewModel — посредник, представляющий данные и команды в форме, удобной для привязки, без прямой зависимости от UI.

WPF предоставляет встроенные средства для MVVM: ICommand для обработки действий (вместо событий), ICollectionView для сортировки и фильтрации, DataTemplate для динамического отображения типов. Это позволяет писать тестируемый, переиспользуемый код, где UI становится «тонкой оболочкой» над логикой.

Ещё одно фундаментальное преимущество WPF — стилизация и шаблонизация. Элементы управления в WPF не имеют жёстко заданного внешнего вида. Кнопка — это контейнер, содержимое которого определяется через ControlTemplate. Это позволяет полностью переопределить внешний вид любого элемента, сохранив его поведение, или создавать кастомные контроля из базовых примитивов (Border, ContentPresenter, VisualStateManager). Система ресурсов (ResourceDictionary) и наследование стилей позволяют централизовать оформление и обеспечивать консистентность интерфейса.

WPF применяется в сценариях, где важны богатый пользовательский опыт, сложная визуализация данных (графики, диаграммы, карты), высокая степень кастомизации интерфейса или строгие требования к архитектуре и тестируемости. Это типично для профессиональных десктоп-приложений: CAD-систем, финансовых терминалов, медицинских визуализаторов, мультимедийных редакторов. Несмотря на то, что WPF ограничен Windows, его стабильность, зрелость и мощь делают его выбором №1 для проектов, где UI — ключевой элемент продукта.

Следует отметить, что WPF активно поддерживается в .NET 6+ (включая сборку под .NET 7 и 8), и его развитие продолжается: появляются новые API, улучшается производительность, добавляется поддержка современных стандартов (например, DPI-awareness). Отсутствие кроссплатформенности — осознанное ограничение, а не признак устаревания.

MAUI (Multi-platform App UI)​

MAUI — это эволюция Xamarin.Forms, ставшая частью .NET 6 и официально выпущенная в 2022 году как кроссплатформенный UI-фреймворк первого класса. Название расшифровывается как .NET Multi-platform App UI, и ключевое слово здесь — multi-platform: MAUI позволяет создавать одно приложение, которое компилируется и запускается на четырёх основных платформах — Android, iOS, macOS и Windows — с использованием единой кодовой базы на C# и XAML.

MAUI — это единая модель пользовательского интерфейса для всех платформ, включая настольные. Это принципиальный сдвиг по сравнению с Xamarin, где основной фокус делался на мобильных устройствах, а поддержка Windows и macOS была добавлена позже и оставалась второстепенной. В MAUI все платформы равноправны: один и тот же элемент управления, например Button, имеет унифицированное API, но при компиляции транслируется в нативные эквиваленты — UIButton на iOS, android.widget.Button на Android, NSButton на macOS и Button из WinUI на Windows. Это обеспечивает естественный внешний вид и поведение, соответствующее платформенным гайдлайнам (Human Interface Guidelines, Material Design и т.д.).

Архитектура MAUI строится вокруг трёх ключевых слоёв:

  1. Общий слой (Shared Layer) — содержит логику приложения: модели, ViewModel’ы, сервисы, бизнес-правила, а также XAML-разметку общих страниц и контролов. Здесь реализуется ядро приложения, независимое от платформы.
  2. Слой адаптации (Platform-Specific Layer) — позволяет писать код, специфичный для одной или нескольких платформ: обращение к нативным API (камера, геолокация, биометрия), кастомизация внешнего вида, оптимизация под особенности ОС. Это достигается через механизмы partial class, #if-директивы, DependencyService (устаревший, но поддерживаемый), и современный подход — handlers.
  3. Слой хостинга (Host Layer) — это проекты, специфичные для каждой платформы (.Android, .iOS, .MacCatalyst, .Windows), которые содержат только минимальные файлы инициализации (например, MainActivity.cs, AppDelegate.cs, App.xaml.cs) и подключают общий код. Именно они компилируются в нативные приложения.

Одним из главных нововведений MAUI по сравнению с Xamarin.Forms является единая модель ресурсов и оформления. Вместо дублирования стилей, цветов, шрифтов и изображений в каждом платформенном проекте, всё это теперь централизуется в общем Resources-каталоге. Система Styles и Control Templates унаследована от WPF/Xamarin.Forms, но дополнена поддержкой Semantic Properties — абстрактных свойств вроде SemanticOrder, Accessibility, FontSize, которые могут по-разному интерпретироваться на разных платформах (например, увеличенный шрифт на iOS автоматически включит Dynamic Type).

MAUI также вводит концепцию Single Project — одного CSPROJ-файла для всего решения, в котором через <TargetFrameworks> указываются поддерживаемые платформы. Это упрощает управление зависимостями, сборкой и развертыванием, устраняя необходимость вручную синхронизировать пакеты между проектами.

Несмотря на амбициозные цели, MAUI пока не лишён ограничений. Производительность UI в сложных сценариях (например, длинные списки с кастомными элементами) может уступать нативной разработке, хотя Microsoft активно работает над оптимизациями (Composition API, Blazor Hybrid). Не все нативные API доступны «из коробки» — для некоторых требуется написание кастомных handlers или platform-specific renderers. Тем не менее, для подавляющего большинства бизнес-приложений — от корпоративных инструментов до потребительских сервисов — MAUI предлагает наилучшее соотношение скорости разработки, стоимости поддержки и пользовательского опыта.

MAUI применяется там, где требуется охват нескольких платформ при сохранении единой бизнес-логики. Это особенно выгодно для компаний, уже владеющих C#-экосистемой: разработчики могут использовать привычные инструменты (Visual Studio, Roslyn, DI, logging), а код из Class Library или даже из ASP.NET Core-проектов (например, shared DTO и validation) может быть переиспользован без изменений.

Xamarin​

Xamarin — это технологическая платформа, появившаяся в 2011 году как независимый проект, а в 2016 году приобретённая Microsoft и интегрированная в .NET-экосистему. До появления MAUI Xamarin был де-факто стандартом для кроссплатформенной разработки на C#. Он состоит из двух основных компонентов: Xamarin.iOS и Xamarin.Android, а также более позднего Xamarin.Forms.

Xamarin.iOS и Xamarin.Android — это нативные привязки к соответствующим SDK. Они позволяют писать приложения для iOS и Android на C#, но при этом использовать официальные API Apple и Google без посредников. Компилятор AOT (Ahead-of-Time) для iOS преобразует C# в нативный ARM-код, минуя JIT (запрещённый Apple), а для Android используется стандартный JIT (или AOT при необходимости). Это обеспечивает производительность, сопоставимую с Objective-C/Swift и Java/Kotlin, и полный доступ ко всем возможностям платформы — от ARKit до WorkManager.

Xamarin.Forms — это отдельный UI-фреймворк, построенный поверх Xamarin.iOS и Xamarin.Android. Он вводит абстрактные элементы управления (Button, ListView, Entry) и компилирует их в нативные аналоги во время выполнения. Это позволяет писать UI один раз на XAML или C#, достигая высокой степени переиспользования кода (до 90% в идеальных сценариях).

Различие между Xamarin.Forms и «чистым» Xamarin (часто называемым Xamarin.Native) критически важно. Первая — это платформа унификации, вторая — платформа привязки. В Xamarin.Native разработчик сам решает, какую часть кода сделать общей (обычно бизнес-логику и модели), а какую — платформенно-зависимой (UI и низкоуровневые сервисы). Это даёт максимальный контроль и производительность, но требует двойной реализации интерфейса. Xamarin.Forms экономит время на UI, но может потребовать дополнительных усилий для кастомизации и оптимизации.

Почему же сейчас рекомендуется MAUI, а не Xamarin? Потому что MAUI — это логическое продолжение и унификация этих технологий внутри .NET. Xamarin.iOS и Xamarin.Android постепенно интегрируются в .NET как workloads (.ios, .android), а Xamarin.Forms официально объявлен устаревшим в пользу MAUI. Это не означает, что существующие Xamarin-приложения перестанут работать — они будут поддерживаться ещё годы. Но для новых проектов Microsoft рекомендует MAUI как более современное, единое и поддерживаемое решение.

Тем не менее, Xamarin остаётся актуальным в двух случаях:

  • когда требуется поддержка старых версий Android/iOS, не покрываемых MAUI;
  • когда проект уже написан на Xamarin и миграция на MAUI нецелесообразна по срокам или бюджету.

Xamarin доказал жизнеспособность идеи: разработка на C# может быть конкурентоспособной даже в мобильной сфере. Его наследие — это код, сообщество, библиотеки (например, Prism, FreshMvvm), и сам факт, что .NET сегодня — полноценная кроссплатформенная платформа.

ASP.NET MVC​

ASP.NET MVC — это программная модель веб-разработки, впервые представленная в 2009 году как альтернатива Web Forms в экосистеме .NET Framework. Её появление стало ответом на растущий спрос на более прозрачный, тестируемый и гибкий подход к построению веб-приложений, вдохновлённый фреймворками вроде Ruby on Rails и Spring MVC.

Суть MVC — в строгом разделении ответственности на три слоя:

  • Model — полная модель предметной области, включающая валидацию, бизнес-логику, взаимодействие с хранилищем. В современных реализациях Model часто представлена как набор DTO, а логика вынесена в сервисы, но принцип остаётся: это слой, инкапсулирующий состояние и правила.
  • View — шаблон отображения, обычно на Razor, отвечающий только за преобразование данных в HTML. View не содержит логики принятия решений, циклов сложнее foreach, и не обращается напрямую к базе данных. Единственное, что ей «разрешено» — получать модель от контроллера и выводить её.
  • Controller — посредник, обрабатывающий HTTP-запрос, координирующий взаимодействие между Model и View. Он извлекает данные, вызывает сервисы, формирует модель представления (ViewModel) и выбирает, какая View будет отрендерена.

ASP.NET MVC вводит понятие маршрутизации (routing) как центрального механизма навигации. Вместо жёсткой привязки URL к физическому файлу (как в Web Forms), маршрут определяет правило сопоставления URL с парой контроллер/действие. Это обеспечивает «чистые» URL, SEO-дружелюбность и гибкость в проектировании API.

Ключевое преимущество MVC — тестируемость. Поскольку контроллеры — это обычные классы без прямой зависимости от HttpContext (они работают через абстракции вроде IHttpContextAccessor или ControllerContext), их можно легко покрыть unit-тестами. View, будучи пассивными шаблонами, тестируются через интеграционные тесты или проверку сгенерированной разметки.

ASP.NET MVC эволюционировал от .NET Framework к .NET Core: в ASP.NET Core MVC был переработан как часть единого хоста и пайплайна middleware, но сохранил совместимость по API. Однако начиная с .NET 6, Microsoft активно продвигает Minimal APIs и Razor Pages как более легковесные альтернативы для простых сценариев, а Blazor — для интерактивных приложений. Тем не менее, ASP.NET MVC остаётся рекомендуемым выбором для крупных, сложных веб-приложений, где важны:

  • чёткая архитектурная дисциплина,
  • разделение зон ответственности между командами (фронтенд vs бэкенд),
  • необходимость одновременной поддержки серверной отрисовки и REST API,
  • интеграция с enterprise-паттернами (CQRS, MediatR, Domain-Driven Design).

Важно не путать ASP.NET MVC с «устаревшим». Это зрелая, стабильная и мощная модель, активно используемая в тысячах production-систем по всему миру. Её «тяжеловесность» — это плата за структуру и масштабируемость.

Worker Service​

Worker Service — это шаблон приложения в .NET, предназначенный для выполнения длительных, фоновых, неинтерактивных задач. В отличие от веб-приложений или десктоп-утилит, Worker Service не имеет UI, не обрабатывает HTTP-запросы и не реагирует на пользовательский ввод. Его единственная задача — работать — отсюда и название.

Архитектурно Worker Service построен на Generic Host — том самом хосте, который используется и в ASP.NET Core, но без подключения веб-специфичных компонентов (Kestrel, middleware). Это позволяет использовать всю инфраструктуру .NET: DI-контейнер, логгирование, конфигурацию, параметры, health checks — без избыточности веб-стека.

Основная единица логики в Worker Service — это реализация интерфейса IHostedService или, чаще, наследование от базового класса BackgroundService. BackgroundService предоставляет асинхронный метод ExecuteAsync, который запускается при старте хоста и работает до тех пор, пока не будет получено уведомление об остановке (через CancellationToken). Внутри этого метода разработчик реализует цикл или асинхронную последовательность операций: опрос очереди сообщений, обработка файлов, периодический вызов API, агрегация метрик.

Особенность Worker Service — это управление жизненным циклом. ОС (или оркестратор, например, Kubernetes) может запросить остановку процесса в любой момент. Хост гарантирует, что перед завершением будут вызваны методы StopAsync у всех hosted-сервисов, давая им время на корректное завершение (сохранение состояния, закрытие соединений, подтверждение обработки сообщения). Это критически важно для надёжности: без этого фоновая задача может быть прервана посреди транзакции, что приведёт к потере данных.

Worker Service применяется в сценариях, где требуется:

  • обработка асинхронных задач вне контекста веб-запроса (отправка email, генерация отчётов),
  • потребление сообщений из очередей (RabbitMQ, Azure Service Bus, Kafka),
  • выполнение периодических заданий (аналог cron, но с логгированием и DI),
  • мониторинг внешних систем (health probes, polling API),
  • интеграция с legacy-системами через файлы или FTP.

Worker Service может быть развёрнут как:

  • Windows Service (через IHostBuilder.UseWindowsService()),
  • systemd-сервис в Linux,
  • фоновый процесс в Docker-контейнере (основной PID 1),
  • Azure WebJob или Function (в режиме длительного выполнения),
  • Kubernetes Deployment/Pod.

Его сила — в простоте и устойчивости. Это полноценный компонент .NET-инфраструктуры, отвечающий современным требованиям к отказоустойчивости, наблюдаемости и управляемости.

Class Library​

Class Library — это единица компиляции и распространения кода, предназначенная исключительно для повторного использования. Её выход — сборка (.dll), которая не может быть запущена напрямую, но может быть подключена к другим проектам как зависимость.

Существует несколько видов библиотек в .NET, и их различие принципиально важно:

  • .NET Standard Library — это спецификация. Она определяет набор API, которые должны быть доступны на всех совместимых платформах (.NET Framework, .NET Core, Xamarin, UWP и др.). Библиотека, скомпилированная под .NET Standard, может быть использована в любом проекте, поддерживающем эту версию стандарта. Однако с выходом .NET 5 и выше, где унификация платформ завершена, .NET Standard уступает место…

  • .NET Class Library (multi-targeting или single-target) — в современной экосистеме (.NET 5+) рекомендуется создавать библиотеки, нацеленные непосредственно на конкретную версию .NET (например, net8.0). Это даёт доступ ко всем возможностям платформы без ограничений стандарта. При необходимости поддержки нескольких версий используется multi-targeting: в .csproj указываются несколько <TargetFrameworks>, и при сборке генерируются отдельные DLL под каждую платформу.

  • Source Library (в виде NuGet-пакета с contentFiles или Source Link) — это продвинутый вариант, где библиотека распространяется как исходный код. Это позволяет компилятору встраивать реализацию напрямую в вызывающий проект, включая полную поддержку отладки и устранение накладных расходов на границе сборок. Такой подход используется в высокопроизводительных сценариях (например, библиотеки-хелперы для работы с памятью) или в инструментах, требующих генерации кода на лету.

Функционально Class Library может содержать:

  • Ядро домена — сущности, агрегаты, правила валидации, спецификации (в DDD-подходе);
  • Общие вспомогательные утилиты — расширения строк, методы сериализации, математические функции, конвертеры;
  • Контракты — интерфейсы сервисов, DTO, сообщения для шины событий, определения ошибок;
  • Инфраструктурные абстракции — интерфейсы для работы с базами данных, кэшем, внешними API, позволяющие легко заменять реализации (например, IEmailSender, IDataContext);
  • Плагины и расширения — код, который загружается динамически во время выполнения (через AssemblyLoadContext).

Важнейшее правило проектирования библиотеки — отсутствие побочных эффектов при загрузке. Конструкторы статических классов, инициализация DI-контейнера, обращение к файловой системе или сети при простом подключении сборки — это нарушение контракта. Библиотека должна быть пассивной: она предоставляет возможности, но не инициирует действия без явного вызова со стороны приложения-хоста.

Class Library — это основа модульной архитектуры. Без неё невозможно построить:

  • многоуровневые решения (Presentation → Application → Domain → Infrastructure),
  • микросервисы с общими контрактами,
  • пакеты для NuGet.org,
  • внутренние компоненты, переиспользуемые между проектами в одном репозитории (monorepo).

Class Library — это архитектурный кирпич, из которого строится устойчивость, тестируемость и долговечность системы.

Unit Test Project​

Unit Test Project — это специализированный тип проекта, предназначенный для автоматизированного подтверждения корректности поведения отдельных единиц кода. Здесь «единица» — это наименьший тестируемый фрагмент логики, имеющий чётко определённые входные данные, выходные данные и побочные эффекты.

Метод может содержать несколько логических ветвей (условия, циклы, исключения), и каждая из них требует отдельного тестового случая. Цель юнит-тестирования — зафиксировать ожидаемое поведение и защитить его от неявных изменений в будущем.

В .NET для написания unit-тестов используются фреймворки:

  • xUnit.net — современный, лёгкий, идиоматичный для .NET подход. Основан на атрибутах Fact (для параметризованных и непараметризованных тестов) и Theory, с поддержкой фикстур (IClassFixture, ICollectionFixture), параллельного выполнения и строгой изоляции между тестами.
  • NUnit — зрелый, мощный фреймворк с богатой историей, поддержкой продвинутых сценариев (setup/teardown на разных уровнях, категоризация, параметризация через TestCaseSource).
  • MSTest — встроенный фреймворк от Microsoft, тесно интегрированный с Visual Studio и Azure DevOps, но исторически более многословный и менее гибкий.

Независимо от выбора фреймворка, качественный unit-тест обладает тремя свойствами — FIRST:

  • Fast — выполняется за миллисекунды, без сетевых вызовов, доступа к диску, базе данных;
  • Isolated — не зависит от других тестов, не оставляет следов в окружении;
  • Repeatable — даёт один и тот же результат при любом количестве запусков в одной среде;
  • Self-Validating — не требует ручной интерпретации: результат — либо pass, либо fail;
  • Thorough (или Timely) — пишется одновременно с кодом (TDD) или сразу после, тестирует пограничные и ошибочные состояния, а не только «счастливый путь».

Для соблюдения этих принципов широко применяются:

  • Моки (mocks) и стабы (stubs) — через библиотеки вроде Moq, NSubstitute, FakeItEasy — для замены зависимостей, которые невозможно или нежелательно использовать в тесте (например, HttpClient, DbContext);
  • Тестовые фикстуры — предварительно подготовленные объекты, ускоряющие инициализацию;
  • Генераторы данных — для проверки поведения на широком диапазоне входных значений (property-based testing через FsCheck или NUnit’s Random).

Unit Test Project — это неотъемлемая часть кода. Он:

  • служит живой документацией: читая тесты, можно понять, как использовать класс;
  • ускоряет рефакторинг: уверенность в том, что изменения не сломали логику;
  • выявляет дефекты на ранней стадии — до попадания в интеграцию или production;
  • формирует культуру качества в команде.

Важно: unit-тесты не заменяют интеграционные, end-to-end или нагрузочные тесты. Это первый и самый дешёвый уровень защиты. Их отсутствие — признак технического долга, который неизбежно приведёт к росту стоимости изменений.

Windows Service​

Windows Service — это специальный тип исполняемого приложения, предназначенное для длительного выполнения в фоновом режиме без необходимости входа пользователя в систему. Такие процессы управляются Service Control Manager (SCM) — компонентом Windows, отвечающим за запуск, остановку, приостановку и восстановление служб.

Технически Windows Service — это консольное приложение, расширенное взаимодействием с SCM через специальные API (в .NET — через классы ServiceBase, ServiceInstaller). При установке (через sc create или инсталлятор) в системный реестр записываются метаданные: имя службы, путь к исполняемому файлу, тип (interactive/non-interactive), зависимости, учётная запись (LocalSystem, NetworkService, конкретный пользователь), политики восстановления.

Жизненный цикл службы управляется событиями:

  • OnStart — вызывается при запуске службы; здесь инициализируются ресурсы, запускаются фоновые потоки или IHostedService, но не должно быть долгих операций — SCM ожидает ответа в течение ограниченного времени (по умолчанию 30 секунд), иначе служба будет помечена как «не отвечающая»;
  • OnStop — вызывается перед остановкой; здесь освобождаются ресурсы, завершаются задачи, сохраняется состояние;
  • OnPause / OnContinue — для приостановки и возобновления (не все службы их поддерживают);
  • OnShutdown — при выключении системы.

Современный подход к созданию Windows Service в .NET — это обёртка вокруг Generic Host. Приложение пишется как Worker Service (с IHostedService), а затем добавляется поддержка хостинга в виде службы:

Host.CreateDefaultBuilder(args)
    .UseWindowsService() // ← ключевая строка
    .ConfigureServices(services => { /* ... */ })
    .Build()
    .Run();

Это позволяет использовать всю инфраструктуру .NET (DI, logging, config) без дублирования логики.

Ограничения Windows Service:

  • Нет интерфейса пользователя. Попытка показать окно или MessageBox приведёт к ошибке (кроме случая AllowServiceToInteractWithDesktop, запрещённого в новых версиях Windows по соображениям безопасности).
  • Ограниченный доступ к ресурсам. По умолчанию служба работает от имени LocalSystem или NetworkService, у которых нет профиля пользователя — нет AppData, Desktop, сетевых дисков, прокси-настроек. Для доступа к таким ресурсам требуется явно указать учётную запись пользователя.
  • Жёсткие требования к надёжности. Сбой в OnStart приведёт к падению всей службы. Поэтому критически важно обрабатывать исключения и логгировать всё подряд.

Windows Service применяется там, где:

  • требуется непрерывная работа вне зависимости от сессии пользователя (мониторинг, синхронизация, приём событий);
  • нужен системный уровень привилегий (взаимодействие с драйверами, реестром, процессами);
  • интеграция с корпоративной инфраструктурой Windows (Active Directory, Group Policies, Event Log);
  • отсутствие возможности использовать более современные оркестраторы (Kubernetes, systemd) — например, в legacy-средах.

Хотя в облаке и контейнерах фоновые задачи чаще реализуются через Worker Service в Docker или Azure Functions, Windows Service остаётся единственным стандартным способом запуска долгоживущих процессов на «голом» Windows-сервере без дополнительных зависимостей.

Освоение главы0%