C# Magazine

К - команда

2025-06-29T17:13:29.830Z

Что самое главное в любой организации? Конечно же люди. Люди, которые увлечены своим делом, работают продуктивнее. Люди, которые работают в окружении единомышленников, близких по духу, "на одной волне", работают в разы продуктивнее.

В этой статье мы расскажем о нашей команде, о людях, которые делают наши курсы такими, какими их видите вы, и немного о том, "как мы провели этим летом* ".

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

В современных условиях непросто собрать команду людей, не разделенных географически. По крайней мере для сферы, где удалёнка уже становится неотъемлемой частью. Поэтому удивляться тому, что у нас команда не только в разных городах располагается, но и в разных странах, конечно, не приходится. И тем не менее, мы вместе!

Идея встретиться в Осетии принадлежит... тоже команде. Но родилась, как полагается, из шутки. Возможно это будет неочевидно, но мы много времени проводим в обсуждениях того, как сделать курсы лучше: какие задачи упростить, какие добавить, что улучшить или вообще удалить. И вы наверняка замечали, что количество задач в курсах постоянно меняется. Это и есть результат командной работы в том числе.

И конечно нельзя быть всегда серьезными, не зря же выше мы упомянули про "быть на одной волне". В какой-то момент Иосиф сказал: "Вот бы вас увидеть вместе". Посмеялись, пошутили, а потом прозвучало заветное: "а давайте..". И вот мы 21 июня съехались во Владикавказ, родные места Иосифа и Школы в целом.

В ожидании прилетающих в аэропорту Владикавказа.

Да, современные реалии таковы, что лучшая (по нашему мнению) школа программирования родом из Владикавказа. И это должно повлиять на тех, кто считает, что программирование и IT в целом - это только про столицы. Отнюдь. Найти применение своим навыкам и знаниям можно в любой точке мира, было бы желание.

Мы ехали на машинах, добирались на поезде, летели самолетами, каждый со своими впечатлениями и приключениями. Но мы собрались, встретились и дальше были незабываемые дни, когда команда стала по-настоящему одним целым. И даже супруги некоторых наших коллег, не побоимся этого слова, породнились с остальной командой. Привет Мише - специалисту по 1С, Артему-питонисту и великолепной творческой Кате!

О том, что мы видели и где мы были словами не рассказать, пером не описать. Но мы старательно фотографировали то, что могли сфотографировать и снимали на видео, то, что можно было снять, а потому чуть дальше можно будет посмотреть на нас вместе.

Всё рассказать невозможно, равно как и показать, и уж тем более передать все эмоции, которые мы испытали. Но если коротко, то:

ходили в горы;
поднимались выше облаков;
спускались к водопаду;
купались в бассейне;
жарили шашлыки и готовили плов;
играли в настолки;
дарили подарки;

Но и о работе не забывали: отвечали в комментариях, кое-что исправляли, невидимое глазу со стороны и самое большое рабочее мероприятие: мозговой штурм-совещание провели по развитию школы и курсов.

По итогу, мы знаем куда двигаться, мы знаем с кем мы работаем и мы знаем, что делать. И вас, наши любимые ученики, мы не разочаруем!

А теперь приоткроем завесу тайны (хотя и не тайна это вовсе) о том, кто же мы. Коротко и по делу.

Итак, основатель и руководитель, идейный вдохновитель, учитель и просто хороший человек - Иосиф Дзеранов.

Иосиф Дзеранов. Основатель и руководитель школы программирования IRON PROGRAMMER

Мастер переговоров и ведения дел, бизнес-ассистент Иосифа Анастасия Матюшко.

Анастасия Матюшко, бизнес-ассистент

Начальник отдела продукта: властительница курсов и повелительница модераторов - Юлия Головинская

Юлия Головинская, Начальник отдела продукта.

Предводитель направления PRO Go. Александр Павлович

Александр Павлович, руководитель направления PRO Go

Модератор нестандартных решений и мастер ответов на комментарии Ангелина Кемза

Ангелина Кемза, модератор Основ и Коллекций

Старший куратор в потоковых курсах, гроза отстающих и ошибающихся: Светлана Козырева

Светлана Козырева, Старший куратор в потоковых курсах, куратор на курсе по ASP.

Человек мощнейшей энергетики, открывший миру курс по базам данных: Кирилл Фисенко

Кирилл Фисенко, создатель и модератор курса PRO C#. Базы данных.

Танк (в лучшем смысле этого слова), человек, способный, если и не свернуть, то покорить любую вершину, по совместительству модератор: Евгений Вишняков.

Евгений Вишняков. Модератор курсов.

Разработчик внутренней платформы для аналитики и куратор на потоковых курсах по ASP и Телеграм ботам: Алексей Миронов

Алексей Миронов. Куратор потоковых курсов Asp и Создание Телеграм ботов.

Это мы - команда Школы IRON PROGRAMMER. К нам всегда можно обратиться с любым вопросом, касающимся обучения на наших курсах и мы обязательно ответим и поможем.

Наши контакты:

Команда IRON PROGRAMMER

* отсылка к фильму "Как я провел этим летом", не опечатка! ))

Боремся с "union types"

2025-04-17T16:55:47.679Z

Когда чуть-чуть поднимаешь голову как разработчик, начинают встречаться на твоем пути всякие задачи, о существовании которых не всегда мог предположить. Часто эти проблемы вызваны сторонними разработчиками и даже не столько в своем проекте, сколько в чужом, от которого что-то зависит. Например, данные.

Еще интереснее, когда твой код работает, а потом, в какой-то момент, перестает или встречает наконец ту проблему, которая была заложена когда-то, кем-то, потому что технологии, которыми там пользуются, позволяют это сделать. О чем же мы говорим?

Начнем, как водится с проблемы.

Допустим, мы разрабатываем приложение, которое получает данные по api из стороннего сервиса. Предположим (хотя это и не редкость), api плохо задокументирован и ориентироваться в получаемых объектах приходится "на ощупь".

Итак, мы написали модели для объектов, начинаем работать с api и в какой-то момент ловим исключение (мы же не эти, мы обрабатываем исключения). Смотрим в логах, а там ошибка в парсинге данных. Странно, вроде все было правильно на этапе подготовки моделей. Вникаем в проблему глубже и оказывается, что объект, который приходит в большой модели может принимать не два состояния: либо он есть, либо null, а целых четыре! (тут можно подставить другое число, но принцип останется тем же).

Справедливости ради, с точки зрения получаемого значения разницы между пустым объектом {} и null нет, они равнозначно игнорируются (или нет, в зависимости от конфигурации) конвертером.

Вот живой пример, с которым пришлось столкнуться нашей команде в процессе разработки:

Есть некая модель, отвечающая за шаги (задачи). А есть другая модель, которая отвечает за наполнение и настройку шагов (задач), называется моделька StepSource. Это не особо важно в контексте рассказа, просто знайте.
У этой модельки много есть всякого, но что нас сегодня интересует - объект Block, а внутри него объект Source. Пока все нормально, модель с несколькими вложениями.
Дальше, у модели Source есть свойство (поле, параметр, you-name-it) options, которое:

// может принимать форму массива с объектами:
"options": [
                        {
                            "is_correct": false,
                            "text": "a + b = 5",
                            "feedback": "В данном случае числа будут читаться как строки и не сложатся"
                        },
                        {
                            "is_correct": true,
                            "text": "a + b = 23",
                            "feedback": ""
                        },
                        {
                            "is_correct": false,
                            "text": "a + b = 2",
                            "feedback": "Посмотрите внимательно на код"
                        },
                        {
                            "is_correct": false,
                            "text": "a + b = 3",
                            "feedback": "Посмотрите внимательно на код"
                        },
                        {
                            "is_correct": false,
                            "text": "a + b = 32",
                            "feedback": "Посмотрите внимательно на код"
                        },
                        {
                            "is_correct": false,
                            "text": "Будет ошибка",
                            "feedback": "Код верный"
                        }
                    ]

//может быть просто объектом с несколькими полями
"options": {
                        "is_checkbox": false,
                        "is_randomize_rows": true,
                        "is_randomize_columns": false,
                        "sample_size": -1
                    }

// может быть пустым объектом:
"options": {}

4. А может и отсутствовать вовсе!

И вот впервые встретившись с таким... многообразием вариантов, почему-то первым на ум приходит мем:

Но, если отбросить эмоции, то проблему надо решать. А как правильно? Или даже по-другому: а как её решить? Как обработать четыре абсолютно разных варианта?

Решение

Самое простое, что может прийти в голову в таком случае — это представить тип свойства Source как object. Но проблему это не решит, так как внутри тоже могут быть варианты.

Можно представить его как dynamic, но проблема останется и все равно надо будет заморачиваться с парсингом входящих в него объектов, что в свою очередь принесет множество других проблем.

Прежде чем мы обратимся к нашему решению, пару слов о том, с чем мы имеем дело. Это — так называемые union types, части объектов, которые используются в составных объектах в языках программирования, которые это позволяют. Из популярного это JavaScript и Python. А вот в языках со строгой типизацией, вроде C#, Java и других придется выкручиваться, обрабатывая все многообразие форм, которое может вернуться из такого не строгого api.

Итак, непосредственно решение.

Для начала, общая структура получаемого объекта:

public class StepSource
{
    [JsonProperty("id")]
    public int? Id { get; set; }

    [JsonProperty("block")]
    public Block? Block { get; set; }
    // другие свойства
}

public class Block
{
    [JsonProperty("name")]
    public string? Name { get; set; }
    
    [JsonProperty("options")]
    public BlockOptions? Options { get; set; }
    
    [JsonProperty("source")]
    public Source? Source { get; set; }
	
	// другие свойства
}

public class Source
 {
     [JsonProperty("options")]
     public OptionsWrapper? Options { get; set; }
     
     // другие свойства
 }

На этом этапе немного задержимся. Как видно, и у Block и у Source есть свойство Options, которое в некоторых деталях схоже между собой. Это порождает желание объединить их. Но так делать не надо. Потом это может сыграть злую шутку в самый неподходящий момент.

Продолжим. Проблема, обозначенная выше, касается свойства Options у объекта Source. Значит, нам нужно на этапе парсинга правильно определить тип получаемого значения и привести его к нужному объекту.

Для этой задачи определим следующий класс:

[JsonConverter(typeof(OptionsConverter))]
public class OptionsWrapper
{
    public List<OptionItem>? OptionsList { get; set; }
    public OptionSettings? Settings { get; set; }
    public bool IsEmpty => OptionsList == null && Settings == null;
}

Здесь обратим внимание на два момента:

Мы определяем сразу возможные варианты:

когда внутри находится список объектов
когда внутри только один объект (другого типа)
когда внутри ничего нет

Наличие аннотации [JsonConverter(typeof(OptionsConverter))]

Теперь рассмотрим, что у нас получается.

 public class OptionItem
 {
     [JsonProperty("is_correct")]
     public bool IsCorrect { get; set; }
     
     [JsonProperty("text")]
     public string Text { get; set; }
     
     [JsonProperty("feedback")]
     public string Feedback { get; set; }
 }

 public class OptionSettings
 {
     [JsonProperty("is_checkbox")]
     public bool IsCheckbox { get; set; }
     
     [JsonProperty("is_randomize_rows")]
     public bool IsRandomizeRows { get; set; }
     
     [JsonProperty("is_randomize_columns")]
     public bool IsRandomizeColumns { get; set; }
     
     [JsonProperty("sample_size")]
     public int SampleSize { get; set; }
 }

И самое главное, кастомный (самописный) JsonConverter:

Картинкой оказалось нагляднее.

Он решает несколько задач. Во-первых, теперь можно и прочитать и записать значение. То есть, можно как получить, так и отправить объект; полноценно его использовать.

Во-вторых, внутри он определяет, что получено и какой тип должен получиться на выходе.

Пройдемся по блокам код:

var token = JToken.Load(reader); — получаем неопределенный объект
Определяем, является ли полученный объект списком (коллекцией), если да, то сериализуем в список объектов OptionItem и возвращаем новый объект OptionsWrapper со свойством List<OptionItem>.

if (token.Type == JTokenType.Array)
{
    var list = token.ToObject<List<OptionItem>>(serializer);
    return new OptionsWrapper { OptionsList = list };
}

if (token.Type == JTokenType.Object)
{
    var obj = (JObject)token;
    if (!obj.HasValues)
        return new OptionsWrapper(); 
    var props = obj.Properties()
                   .Select(p => p.Name)
                   .ToList();
    if (props.Contains("is_checkbox") 
     || props.Contains("is_randomize_rows") 
     || props.Contains("sample_size"))
    {
        var settings = obj.ToObject<OptionSettings>(serializer);
        return new OptionsWrapper { Settings = settings };
    }
}

А если это объект, то продолжаем проверку.

Если у объекта нет значений, то возвращаем пустой объект OptionsWrapper.

А если у объекта есть свойства с именами (указаны внутри блока if), то создается и возвращается новый объект OptionsWrapper с созданным свойством OptionSettings

В обратную сторону это работает так же: проверяем, что в себе "несет" OptionsWrapper и в зависимости от этого сериализуем объект, список или пустое объявление json ('{}')

Отметим так же, что это работает с библиотекой Newtonsoft.Json и не работает (не работало) с System.Text.Json, увы

По такому же принципу можно обрабатывать и бОльшее число вариантов от внешних сервисов. Однако, пожелаем вам пореже с такими "чудесами" сталкиваться.

SOLID простым языком

2024-09-27T17:27:35.361Z

Термины «чистый код», и «чистая архитектура» знакомы многим. Действительно, очень известные понятия, но такие непонятные для тех, кто только погружается в мир разработки. И, если в случае с чистым кодом можно догадаться о чем речь, то с чистой архитектурой все сложнее. Впрочем, как и в разработке в целом проектирование приложения гораздо более сложная и ответственная задача, нежели просто написание кода. Не зря же следующей ступенью после старшего разработчика и тимлида зачастую вырастают в системного архитектора. И далеко не все. Значит, спроектировать всю систему, выстроить ее таким образом, чтобы она не только работала, но работала быстро и правильно, а главное могла быть расширяема и в целом поддерживаема, действительно непростое дело.

В то же время, понимать, как выстроить взаимосвязь между элементами в своем приложении надо каждому разработчику. Иначе результат его трудов рискует стать огромной кучей сложно поддерживаемого, не расширяемого кода.

Одним из принципов построения правильной архитектуры приложений в ООП является принципы, а точнее принципы SOLID. SOLID – это не столько самостоятельное слово, а акроним, составленный из первых букв пяти принципов, кстати, далеко не всех, описанных Робертом Мартином. И в рамках этой статьи мы посмотрим по внимательнее на них и разберем на практике, где и как их применять. Стоит оговориться, что одной статьи для полного погружения в «чистую архитектуру» будет мало, но старт, пожалуй, вполне хороший.

S. Single Responsibility Principle (Принцип единственной ответственности)

Очень часто упоминание этого принципа сводится к следующей парадигме:

– каждый класс должен выполнять одну задачу

– каждый метод должен выполнять только одну функцию,

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

Но, есть нюанс. Сам Боб Мартин в книге «Чистая архитектура» пишет о том, что такое толкование термина «единственная ответственность» некорректно. Этот термин не столько описывает внутреннюю структуру определённого класса, сколько указывает на его предназначение для конкретного потребителя. Его цель — не просто выполнять определённую функцию, а изменяться только под нужды конкретного потребителя, для которого он предназначен.

Что это означает на практике? В практическом смысле все обстоит таким образом: если у нас есть некий сервис (класс), формирующий какой-то результат, то все действия с этим сервисом (добавление/изменение/удаление логики) должны производиться только для того одного «потребителя», для которого он предназначен. Пожалуй, в этом случае стоит привести пример, который раскроет тему на практике.

Итак, разберем пример из, все той же, «Чистой архитектуры», слегка модернизированный: есть некий класс Employee в котором три публичных метода:

CalculatePay();
ReportHours();
Save();

Каждый из этих методов используется разными «потребителями»:

бухгалтерия пользуется методом CalculatePay();
отдел кадров использует ReportHours();
а методом Save() пользуются администраторы баз данных.

Чем же плох такой подход? Давайте представим, что есть метод GetRegularHours(), который рассчитывает рабочие часы для сотрудников и используется в этих методах. Пусть это будет приватный метод и находится в том же классе.

В какой-то момент, в бухгалтерии решили обновить систему расчета заработной платы и им стало необходимо поменять алгоритм учета рабочего времени. Разработчик, приглашенный бухгалтерией внес изменения в метод GetRegularHours() и вроде бы все довольны.

И только спустя n-времени отдел кадров обратил внимание, что показатели рабочего времени у всех сотрудников сильно изменились, что повлекло огромные убытки. Вот это и есть нарушение принципа единственной ответственности, когда класс был изменен в пользу одного потребителя, а предоставлял результаты нескольким.

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

O. Open-Closed Principle (Принцип открытости-закрытости)

Принцип открытости-закрытости звучит в обсуждениях не так часто, как Принцип единственной ответственности, однако с точки зрения проектирования архитектуры приложения он крайне важен. Кстати, сформулирован он был в 1988 г. Бертраном Мейером и звучит он так: «Программные сущности должны быть открыты для расширения и закрыты для изменения». Что же это означает?

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

Для того чтобы добиться такого состояния приложения, нужно более гибко подходить к реализации с самого начала. Рассмотрим пример для наглядности.

Предположим, есть организация, в которой формируется финансовый отчет в виде PDF файла. В какой-то момент, в организации начали внедрять новое ПО, предоставляющее визуальное отображение различных показателей компании с графиками и метриками. Использование pdf документа в таких условиях не представляется удобным. Значит нужно сформировать данные для передачи во внедряемую систему. Текущий код, при правильной организации не будет изменен, если реализована возможность на определенном этапе получить «сырые» данные и использовать их для формирования нового представления и отправки в обновленную систему.

На схеме выше изображены все уровни взаимодействия, где каждый шаг расширяет, но не изменяет текущую функциональность приложения. Фин. репозиторий забирает данные из БД и отдает их в генератор отчетов. Генератор отчетов собирает воедино все данные и передает потребителям. Раньше это был только сервис по генерации pdf документов. После добавления нового сервиса по генерации визуальных отчетов поведение других компонентов системы не изменились. Таким образом соблюдается принцип открытости-закрытости. Принцип единственной ответственности тоже соблюдается, поскольку все действия по обработке финансовых данных происходят в отдельных классах и их результат не зависит друг от друга.

L. Liskov substitute principle (Принцип подстановки Барбары Лисков)

Все в том же 1988 году Барбара Лисков написала так:

«Здесь требуется что-то вроде следующего свойства подстановки: если для каждого объекта o1 типа S существует такой объект o2 типа T, что для всех программ P, определенных в терминах T, поведение P не изменяется при подстановке o1 вместо o2, то S является подтипом T.»

Иными словами, если у класса есть классы, его наследующие, то при замене объекта базового класса на объект класса, его наследующего не должно повлечь изменений в поведении приложения. Стоит рассмотреть схематично, как это выглядит.

Приложение использует класс Shape у которого есть один метод. Два класса: квадрат и прямоугольник наследуют класс Shape и могут быть использованы вместо него там, где базовый класс вызывается, при этом не произойдет изменение поведения приложения.

Другой пример, более близкий к реальному применению. Представим интернет магазин, где можно приобрести как товар, так и услугу. С точки зрения объектной модели они отличаются не сильно, у них есть много общего – название, цена, описание. На изображении ниже приведен код этих классов:

Как видим, в корзину добавляются элементы CartItem, в которых содержится информация об элементе и его количестве, а так же, в зависимости от количества получается цена. В корзине так же есть метод CalculateSum(), который считает общую стоимость элементов в корзине. Здесь очень хорошо видно, как именно подставляются объекты разных классов (Product и Service) в CartItem, но при этом поведение методов у CartItem и Cart не меняется в зависимости от содержимого. Это и есть то самое правило подстановки Барбары Лисков.

I. Interface Segregation principle (Принцип разделения интерфейсов)

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

Предположим, у нас есть класс Human, который реализует интерфейс IWorker. И есть класс Robot, который также реализует интерфейс IWorker. Пока все правильно, но, взгляните на схему:

У интерфейса IWorker есть методы, которые не используются классом Robot, однако мы вынуждены их реализовывать из-за того, что реализуем интерфейс. Более того, при использовании приложения может возникнуть ситуация, когда исключение будет вызвано, поскольку вместо Human метод Eat был вызван у Robot. Кроме того, явная реализация заведомо ненужных методов вынуждает писать много дополнительного «мертвого» кода.

Выходом из данной ситуации может стать разделение интерфейсов на более узконаправленные. Пример на изображении ниже:

В таком виде каждый класс реализует только те интерфейсы, методы которых он будет использовать.

Таким образом, разделив интерфейсы, мы можем вызвать метод ManageWork() и использовать в нем как Human, так и Robot. При этом Robot реализует только один интерфейс, а Human все три. Однако это никак не сказывается на работе приложения.

D. Dependency Inversion principle (Принцип инверсии зависимостей)

Этот принцип говорит, что наиболее правильно для построения гибкой системы, в которых в качестве зависимостей используются абстракции, а не конкретные реализации.

Сразу же посмотрим, как это реализуется. Для примера рассмотрим использование DI контейнера в приложении, реализующем Телеграм бота:

Есть интерфейс IUserRepository, в котором описаны методы стандартного CRUD-репозитория. Есть класс UserRepository его реализующий. В контейнер зависимостей мы добавили интерфейс и класс его реализующий, а в классе ClientActiveSessionUpdatesHandler используется в качестве зависимости IUserRepository.

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

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

Заключение

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

Принцип единственной ответственности в ASP .NET Core MVC

2024-09-12T20:16:26.424Z

В этой статье поговорим про одну из важных составляющих ООП в целом и приложений на C# в частности - про принцип единственной ответственности.

Принцип единственной ответственности гласит, что каждый класс должен иметь одну четко определенную задачу. Рассмотрим на примере, где этот принцип не соблюдается:

Пример кода, где не соблюдается принцип единой ответственности.

Вроде в коде все нормально, а что не так?

А не так в нем то, что контроллер, который отвечает за взаимодействие передаваемых из фронта (интерфейса сайта) или api данных и другими компонентами приложения, в данном случае, выполняет много дополнительных, не свойственных действий.

То есть, контроллер - некий диспетчер. Принял данные, отдал их на обработку, получил результат обработки и отдал обратно во фронтенд или api. Он не производит вычислений, формирований строк и т.д. И контроллер не должен знать о внутреннем устройстве приложения дальше, чем на один шаг. Соответственно, он никак не может взаимодействовать напрямую с базой данных, в данном случае с контекстом.

Упрощенная схема взаимодействия выглядит так:

Схема взаимодействия классов в приложении ASP .Net Core

Контроллер "общается" только с сервисами. Сервисы взаимодействуют с контроллером, другими сервисами и репозиториями. Репозитории взаимодействуют только с базой данных и сервисами их использующими.

Такой подход позволяет:

четко упорядочить структуру приложения;
упростить тестирование;
определить задачи для каждого компонента приложения;

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

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

Теперь рассмотрим первоначальный пример, но уже с разделением ответственности:

public class UserController : Controller
{
    private readonly IUserService _userService;

    public UserController(IUserService userService)
    {
        _userService = userService;
    }

    public IActionResult Index()
    {
        var users = _userService.GetUsers();
        return View(users);
    }

    public IActionResult Create(string fullName, int age, string email)
    {
        if (!ModelState.IsValid)
        {
            return View();
        }

        _userService.CreateUser(fullName, age, email);
        return RedirectToAction("Index");
    }

    public IActionResult Delete(int id)
    {
        _userService.DeleteUser(id);
        return RedirectToAction("Index");
    }
}

public interface IUserService
{
    IEnumerable<User> GetAll();
    void Create(string fullName, int age);
    void Delete(int id);
}

public class UserService : IUserService
{
    private readonly UserRepository _repository;
    private readonly EmailService _emailService;

    public UserService(UserRepository repository, EmailService emailService)
    {
        _repository = repository;
        _emailService = emailService;
    }

    public IEnumerable<User> GetAll()
    {
        return _repository.GetAll();
    }

    public void Create(string fullName, int age, string email)
    {
        var user = new User(fullName, age, email)
        
        _repository.Save(user);

        _emailService.SendWelcomeEmail(email);
    }

    public void Delete(int id)
    {
        var email = _repository.Get(id).Email;
        
        _repository.Delete(id);

        _emailService.SendGoodByeEmail(email);
    }
}

public class UserRepository
{
    private readonly DbContext _dbContext;

    public UserRepository(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public IEnumerable<User> GetAll()
    {
        return _dbContext.Users.ToList();
    }

    public User Get(int id)
    {
        return _dbContext.Users.Where(u => u.id == id).First();
    }

    public void Save(User user)
    {
        _dbContext.Users.Add(user);
        _dbContext.SaveChanges();
    }

    public void Delete(int id)
    {
        var user = _dbContext.Users.Find(id);
        if (user != null)
        {
            _dbContext.Users.Remove(user);
            _dbContext.SaveChanges();
        }
    }
}

public class EmailService
{
    public void SendWelcomeEmail(string email)
    {
        // код отправки электронной почты
    }

    public void SendGoodByeEmail(string email)
    {
        // код отправки электронной почты
    }
}

Теперь в репозитории происходит только выполнение CRUD операций, в сервисе вызываются методы репозитория и сервиса отправки электронной почты, и отдаются данные в контроллер , а контроллер занимается передачей запросов и возвратом результата в пользовательский интерфейс.

В таком подходе может быть больший по объему код, но он лучше тестируется, каждый компонент выполняет свою роль, а код в целом менее связан.

Таким образом, соблюдения принципа единственной ответственности делает код более читаемым, легко поддерживаемым, обновляемым и тестируемым. Пишите чистый код, до встречи!

Сравнение технологий для написания оконных приложений.

2024-08-13T20:46:51.858Z

Как-то раз в одном чате прозвучала идея сравнить разные технологии для написания оконных приложений. В частности, под Windows. Используя средства языка C#. То есть, конечно, можно это сделать и с помощью C++, Python, Rust, JS и других языков, но мы же шарписты, нам интереснее именно то, что мы можем сами использовать, не меняя язык программирования.

Итак, оконные приложения на C#. Их можно написать, используя:

Windows Forms
WPF
WinUI
.NET MAUI
Avalonia
Uno Platform

Такое многообразие фреймворков обусловлено тем, что язык развивался, менялись подходы, совершенствовались технологии. А в какой-то момент к разработке подключились сторонние разработчики и к средствам Microsoft добавились Avalonia и Uno.

Таким образом, для того чтобы начать писать оконные приложения надо решить, какую технологию использовать. Но, кроме того, неплохо бы понимать, где будет приложение использоваться – только на Windows или есть необходимость в запуске на MacOS и Linux. А может быть еще и на IOS и Android?

В общем, в этой статье попробуем разобраться в возможностях этих фреймворков и сравним их. Сравнивать будем по таким критериям:

Платформы, в которых можно запустить приложение
Сложность разработки
Потребляемые ресурсы
Скорость запуска

Для корректности сравнения будем использовать одну логику для всех приложений. Более того, попытаемся сделать их максимально похожими друг на друга.

Часть 1. Логика

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

Весь код логики практически один в один переходит из приложения в приложение, за исключением некоторых особенностей в разных фреймворках. Например, в Авалонии нет встроенного механизма отображения всплывающих окон (Message Box) и для того, чтобы он появился надо установить дополнительный пакет. Не сложно, но нюанс. В некоторых фреймворках нельзя напрямую посчитать кнопки из интерфейса и надо придумывать обходные пути.

Важно также отметить, что везде, кроме WinForms по-хорошему следует использовать паттерн MVVM, однако для простейшего приложения заморачиваться не стал и работает все напрямую.

Часть 2. Пользовательский интерфейс

Разработка UI в приложениях C# отличается не очень сильно друг от друга. Выделяется разве что WinForms, где элементы интерфейса размещаются обычно вручную в графическом редакторе, что в свою очередь весьма дружелюбно по отношению к людям без опыта.

Еще можно размещать элементы вручную в WPF, однако рекомендуется все же выстраивать интерфейс вручную задавая параметры в коде страницы.

Осложняет процесс разработки внешнего вида отсутствие интерактивного отображения получаемого результата в MAUI и WinUI – там посмотреть на результат можно только после сборки и запуска. Да, есть такая функция как Hot Reload, когда изменения будут появляться после горячей перезагрузки без перезапуска всего приложения, но тоже не без нюансов. Во-первых, при горячей перезагрузке теряется состояние приложения (если оно отдельно не сохраняется где-то), например при игре уже есть несколько крестиков и ноликов, то после Hot Reload они «забываются». Во-вторых, бывает, что изменения не отображаются и все равно приходится перезапускать приложение. Не баг, а фича, как говорится.

В целом же привыкнуть можно ко всему и даже потом возвращаться к WinForms становится тяжко – хочется все настраивать самому.

В конечном итоге интерфейс готовых приложений получился таким:

Windows Forms

WinForms

WPF

WinUI

MAUI

Avalonia

Uno Platform

Я не сильно старался сделать их идентичными, потому что и задачи такой не было, да и на последующие измерения цвет кнопочек не повлияет. Более того, можно обратить внимание, что некоторые между собой похожи. Это результат применения в них компонентов WinUI. В MAUI дополнительно используются фирменные шрифты и Material Design – поэтому кнопки со скругленными углами. А еще WinUI подтягивает основную тему из системы и поэтому все, кроме WinForms и WPF темные. Соответственно в первых двух нужно отдельно добавлять обработку светлой/темной темы.

Часть 3. Платформы

Тут мы подходим к глобальным возможностям всех фреймворков. Итак, таблица ниже показывает, под какие платформы может быть собрано приложение.

Как видим, что вполне логично, все шесть фреймворков позволяют писать оконные приложения для Windows. Но есть и различия. Они кроются как в кроссплатформенности MAUI, Avalonia и Uno, так и в компонентах, которые используются для отрисовки графического интерфейса.

Углубляться сильно не будем в дебри, но стоит знать, что MAUI Авалония используют компоненты WinUI, Uno в свою очередь может реализовывать оконное приложение как в WPF варианте, так и WinUI. Это может быть полезно в отдельных случаях.

Кроме того, нативные фреймворки WinForms, WPF и WinUI отличаются технически:

- Windows Forms использует GDI+ для отрисовки интерфейса

- WPF использует DirectX для рендеринга

- WinUI использует для рендеринга DirectX/DirectComposition

Так же, есть различие в используемых компонентах, библиотеках и подходах. Иными словами, все технологии, представленные в статье, имеют множество различий при схожей функциональности даже в рамках одной целевой платформы.

Часть 4. Ресурсы и скорость запуска

Сейчас мы подошли к той части «исследования», когда в дело вступают цифры. В данной части посмотрим на то, сколько приложения занимают места в оперативной памяти. Сравнивать будем в двух режимах: в Visual Studio в режиме Debug и в диспетчере задач запущенное опубликованное приложение (конфигурация Release).

Эти значения получены из Visual Studio при запуске отладки каждого приложения по отдельности.

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

Для сбора данных я написал скрипт для PowerShell, который запускает приложение, ждет, когда оно загрузится (станет отзывчивым), дополнительно ждет пару секунд на случай неполной загрузки и выключает приложение. И так 100 раз подряд для каждого приложения. Попутно скрипт собирает данные об используемом объеме памяти и вычисляет скорость запуска.

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

Код скрипта:

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8 $apps = @( "PATH_TO_TicTacToeUno.exe", "PATH_TO_TicTacToeMAUIApp.exe", "PATH_TO_TicTacToeWPF.exe", "PATH_TO_TicTacToeAvalonia.Desktop.exe", "PATH_TO_TicTacToeWinUI.exe", "PATH_TO_TicTacToeWinForms.exe" ) $results = @{} foreach ($app in $apps) { $appName = [System.IO.Path]::GetFileNameWithoutExtension($app) $times = @() $memoryUsages = @() for ($i = 1; $i -le 100; $i++) { Write-Host "Starting $appName (Iteration $i of 100)..." $start = Get-Date $process = Start-Process $app -PassThru # Ждем, пока главное окно приложения не станет отзывчивым while (-not $process.MainWindowHandle) { Start-Sleep -Milliseconds 100 } $end = Get-Date $duration = ($end - $start).TotalSeconds $times += $duration # Измеряем использование памяти Start-Sleep -Seconds 2 # Даем приложению время полностью загрузиться $memory = (Get-Process -Id $process.Id).PrivateMemorySize64 / 1MB $memoryUsages += $memory # Закрываем приложение Stop-Process $process.Id -Force while (-not $process.HasExited) { Start-Sleep -Milliseconds 100 } # Освобождение ресурсов и сборка мусора $process.Dispose() [System.GC]::Collect() [System.GC]::WaitForPendingFinalizers() # Ждем немного перед следующим запуском Start-Sleep -Seconds 5 } $averageTime = ($times | Measure-Object -Average).Average $averageMemory = ($memoryUsages | Measure-Object -Average).Average $results[$appName] = @{ Time = $averageTime Memory = $averageMemory } } # Вывод результатов Write-Host "`nResults after 100 launches:" $results.GetEnumerator() | Sort-Object {$_.Value.Time} | ForEach-Object { Write-Host ("{0,-30} : StartUp Time: {1:N3} seconds, Memory Usage: {2:N2} Mb" -f $_.Key, $_.Value.Time, $_.Value.Memory) }

Дополнительно отмечу, что скрипт я запускал по несколько раз с некоторыми изменениями, в частности брал данные о памяти как из process.WorkingSet64 так и process.PrivateMemorySize64, а так же для подстраховки продублировал тесты в Python-скрипте. Суммарно вышло что-то около 500-600 запусков каждого приложения, что в общем дает вполне понятную картину.

Еще, прежде чем показать результаты, оговорюсь относительно WinUI приложения — оно доставило больше всех хлопот, как ни странно, поскольку запускалось уверенно в VS и даже тесты проходили в уже готовом и установленном приложении, однако по факту не запускалось. Ошибка с Windows.ui.xaml.dll вызываемая непонятно по какой причине, не давала мне покоя несколько дней. Несколько тестов были проведены с этой “особенностью”. Тем не менее глобально, после того, как проблема была решена, ничего в цифрах не поменялось кардинально.

Итак, ниже скриншоты из PowerShell:

1 запуск:

5 запусков

10 запусков:

100 запусков:

10 запусков на Python:

Результаты интересные. По скорости запуска различия есть, но по сути на уровне погрешности — все запускаются быстро. Причем, когда наблюдаешь вживую за процессом выполнения скрипта, заметно, что первые 3-5 раз загрузка UI происходит дольше, чем последующие. Связано это с кэшированием на уровне ОС. Правда актуально это для ClickOnce-сборок в большей степени, но заметно и на WInUI, которую запускал без установки.

Гораздо интереснее ситуация с памятью. Тут и явный лидер — неожиданно - Uno Platform, и явный аутсайдер - WPF.

Самый последний тест, при котором все уже работало и не падало - 100 итераций в PowerShell. Там же и минимальное значение задействованных ресурсов - в среднем 1,46 Мб. Тоже, скорее всего, связано с каким-то кэшированием, потому что в других тестах стабильно требовал ~ 8Мб.

Но всегда, во всех тестах, больше всего памяти отъедал WPF. Скорее всего это связано с тем, что учитываются “общие ресурсы” используемые другими приложениями в это же время в системе. По-крайней мере именно из-за этого вносил изменение в скрипт для получения данных из PrivateMemorySize64, однако тесты показали, что разницы нет. Возможна ли тут ошибка? Да, вполне может быть. Но и Python-скрипт показал такие же данные, поэтому я склоняюсь все же к тому, что WPF действительно самый ресурсоемкий фреймворк.

Но я предполагал, что им окажется MAUI. И по используемым ресурсам, MAUI лишь WPF уступил в объеме задействованной памяти. В это же время, скорость запуска во всех тестах у MAUI была самой низкой.

Часть 5. Сложность разработки

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

Но совершенно точно WinForms - самый простой из представленных фреймворков в освоении. Тому есть два объяснения — графический редактор (дизайнер) и отсутствие необходимости в использовании MVVM паттерна и бесконечного числа биндингов.

Но, опять же, все зависит от сложности проекта. В моем тестовом проекте везде было одинаково несложно. Даже с учетом того, что опыта с Uno и WinUI до последнего времени у меня не было.

Часть 6. Сборка и развертывание

Пару слов про то, насколько сложно подготовить проект к публикации и использовать его потом.

В целом, процесс должен быть не очень сложным везде. На практике, есть множество нюансов. В частности, неожиданно WinUI преподнес неприятные сюрпризы. Различных решений проблемы я нашел множество, но ни одно так и не помогло и, в конечном счете, запускал приложение для тестов из папки Release. Остальные приложения собрались и установились без проблем.

Дополнительно надо иметь в виду, что приложению требуется сертификат. То есть да, можно не подписывать приложение вовсе, но и распространять его будет сложнее - Windows на сторонних компьютерах будет ругаться при установке. Поэтому, хотя бы тестовым сертификатом подписать приложение стоит. А вот полноценный сертификат стоит денег, а в текущих условиях еще и надо найти, где его приобрести.

Конечно, это всё нюансы и наверно есть какие-то пути решения вопроса, да и вопрос сам не первоочередной важности. Но знать об этом стоит.

Часть 7. Итог

Что ж, стоит подвести итоги нашего небольшого исследования-сравнения. Для кого вообще оно делалось? Для тех, кто не занимался разработкой оконных приложений, но хотел бы понять, какие есть актуальные технологии. И вот эти технологии мы рассмотрели. Весьма поверхностно, конечно, но и задачи писать энциклопедию о том, как написать оконное приложение со всеми тонкостями, не стояло. А вот сделать вывод о том, с чего начать вкатываться в мир разработки приложений под Windows, а потом и других платформ, вполне можно.

Мое видение, основанное на имевшемся ранее и полученном сейчас такое:

- Начинать стоит все-таки с базы – с Windows Forms. Да, технология не нова, даже можно ее считать устаревшей. Но она живая и функциональная. Многие приемы на ней можно отработать, да и собрать действительно сложно приложение с графическим интерфейсом вполне реально. Да чего там – так делали, делали много и долго.

- Вторым шагом стоит изучить WPF. Эта технология позволит развить понимание паттерна MVVM, проектирование интерфейса в XAML и откроет путь к более современным стекам.

- Дальше путь открыт ко всему. Я был приятно удивлен возможностям Uno Platform, не ожидал. Кроме того, что можно написать приложение под любую актуальную ОС, в том числе и мобильную, так еще и весьма бережно эта технология относится, как оказалось, к ресурсам. Не то, чтобы это сильно критично, но, когда проект большой и нужно бороться за производительность, приложение, потребляющее меньше ресурсов будет выглядеть предпочтительнее на мой взгляд.

Еще из важного – возможность собрать дизайн приложения Uno в Figma и импортировать код интерфейса прямо в проект в виде XAML-кода! Такого нет ни у кого из других рассмотренных фреймворков.

К сожалению, не для всех технологий есть качественные и полноценные обучающие материалы, особенно на русском языке. Тем не менее, тут есть что порекомендовать:

Изучить Windows Forms с углубленным пониманием ООП можно по ссылке;
Изучить WPF можно по этой ссылке;

И, напоследок, пару слов о размере приложения на диске.

Здесь в папках располагаются установщики. WinForms - ожидаемо, самое “легкое” приложение. MAUI - без комментариев. Хотя нет, уточню, что в сборке MAUI отсутствуют билды под другие платформы, то есть это именно Windows-приложение.

На этом все. Делайте свои выводы, пробуйте разрабатывать оконные приложения и успехов!

P.S. исходный код всех проектов доступен по ссылке: https://github.com/algmironov/WinAppFrameworksComparison