.NET backend study

2021-11-30 14:44:31 Конспект по теме "Очистка ресурсов" из категории "C#"

Есть несколько способов очистки ресурсов:

⦁ GC.Collect

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

⦁ Finalize

GC.Collect только помечает объекты на удаление, а не удаляет их сразу. Непосредственно при удалении - у объекта вызывается метод Finalize. Там, в основном, происходит очистка неуправляемых ресурсов (всякие низкоуровневые файловые дескрипторы).

Это м.б. не очень удобно, т.к. могут быть ситуации, когда ресурсы нужно освободить как можно раньше, а предугадать, когда GC пометит этот объект на удаление и удалит его - нельзя.

⦁ Деструктор

~MyClass { }

В итоге разворачивается в Finalize метод:

try-finally { base.Finalize() }

⦁ Dispose

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

using - это гарантия того, что для IDisposable класса будет выполнен метод dispose. Т.е. это разворачивается в конструкцию try-finally.


Вернуться в бэклог категории C# Открыть/Комментировать

2021-11-26 11:25:48 Конспект по теме "Индексы" из категории "SQL"
Часть II - советы по использованию

⦁ Нужно учитывать, что индексы занимают дополнительное дисковое пространство и большое их количество может ухудшить производительность;

⦁ Индексы больше подходят для столбцов, которые имеют простые атомарные значения - например, целые числа - это обеспечит бОльшую производительность;

⦁ Индексы предпочтительно использовать на столбцах с уникальными значениями, не допускающими NULL. Т.е. чем меньше дубликатов (или вообще их отсутствие) - тем быстрее будет работать поиск через индекс;

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

⦁ Индексы лучше не использовать на таблицах с маленьким количеством записей, т.к. в данном случае простое сканирование будет работать быстрее, чем поиск через индексы;

⦁ Для составных индексов (индекс из нескольких столбцов) важен порядок столбцов при определении этого индекса. Т.е. если у вас индекс по полям Name, Surname - то индекс лучше создавать следующим образом:

CREATE NONCLUSTERED INDEX Employee_Index
ON Employee (Surname, Name)

Поле Фамилия (Surname) имеет больше уникальных значений и позволит сразу сильно отфильтровать исходную таблицу. Поэтому мы ставим это поле первым при объявлении индекса.


Вернуться в бэклог категории SQL Открыть/Комментировать

2021-11-23 17:05:58 Конспект по теме "Индексы" из категории "SQL"
Часть I - Что это такое, виды индексов.

Индекс - это древовидная структура данных. В узлах этого дерева хранятся данные из таблицы.

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

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

При отсутствии индекса - будут просканированы все строки, которые есть в таблице и на основе фильтра будет выдан результат.

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

Виды индексов:

⦁ кластеризованный;
⦁ некластеризованный.

Кластеризованный индекс

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

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

Если кластеризованный индекс был повешен на поле с неуникальными значениями, то ко всем дубликатам в индексируемое поле будет добавлен уникальный идентификатор - и получится что-то вроде Иванов1234.

Некластеризованный индекс

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


Вернуться в бэклог категории SQL Открыть/Комментировать

2021-11-18 17:23:12 Конспект по теме "dynamic, object, var" из темы "C#"

В языках со статической типизацией выявление всех типов и их членов (свойств, методов) происходит на этапе компиляции. Т.е. если у объекта нет указанного метода, то программа не скомпилируется. В языках с динамической типизацией проверка происходит в процессе выполнения. dynamic это фича из языков с динамической типизацией.

object:

⦁ у компилятора мало информации об объекте, т.к. он хранится там в обобщённом виде;
⦁ может передаваться как параметр и быть возвращаемым значением метода;
⦁ позволяет запаковать любой объект в эту переменную. Но нельзя вызвать методы этих объектов. Доступны будут только методы класса object;
⦁ чтобы положить в object переменную любого типа - нужно произвести преобразование к object. Чтобы достать из object переменную определённого типа, нужно произвести преобразование к этому типу (распаковка);

dynamic:

⦁ позволяет не производить проверку наличия свойств, методов на этапе компиляции. И производить её на этапе выполнения;
⦁ переменные этого типа могут менять тип во время работы программы;
⦁ позволяет вызывать любые методы с любым количество параметров. Однако, если при выполнении будет подставлен тип, у которого нет данного метода - выпадет исключение RuntimeBinderException;
⦁ у компилятора нет никакой информации об объекте;
⦁ может передаваться как параметр и быть возвращаемым значением метода;
⦁ преобразование к типу не требуется, но нужно точно знать, что этот тип содержит нужный метод;
⦁ желательно избегать использования, т.к. затруднена отладка, высока вероятность ошибки;

var:

⦁ у компилятора есть вся информация об объекте, т.к. он хранится в нужном типе;
⦁ это просто синтаксический сахар, чтобы не объявлять тип переменной. По сути, это просто сокращение записи;
⦁ не может передаваться как параметр и быть возвращаемым значением метода;
⦁ не нужно осуществлять никаких преобразований, т.к. у компилятора есть вся необходимая информация об объекте;


Вернуться в бэклог категории C# Открыть/Комментировать

2021-11-17 13:33:41 Конспект по теме "SOLID" из темы "Архитектура"

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

Класс должен выполнять только одну задачу, каждый метод класса должен выполнять одну задачу. Также классы должны работать на одном уровне абстракции (т.е., например, взаимодействие с пользователем, обработка бизнес-требований, взаимодействие с БД).

Open/closed principle (принцип открытости/закрытости)

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

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

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

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

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

Dependency inversion principle (принцип инверсии зависимостей)

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


Вернуться в бэклог категории Архитектура Открыть/Комментировать

2021-11-15 19:04:37 Конспект по теме "Различия между Rest API и GraphQL" из темы "Web"

⦁ Количество endpoint-ов - в REST необходимо реализовывать множество простых endpoint-ов. Например - получение всех пользователей, по id, по имени, по городу проживания. GraphQL же может предоставить одну общую точку users - и в зависимости от переданных и запрашиваемых данных - даст ответ;

⦁ Избыточность - в REST данные отдаются либо с избытком, либо приходится делать большое количество endpoint-ов. Когда мы делаем один endpoint, где отдаём всю модель целиком - пользователю, зачастую, это не нужно, таким образом перегружается фронт, получая большое количество полей;

⦁ Сложная читаемость - засчёт версионирования в REST ухудшается визуальное восприятие endpoint-ов;

⦁ Дополнительная сложность - при использовании GraphQL вводится ещё один слой, что увеличивает вероятность ошибки;

⦁ Ухудшается производительность - также засчёт добавления нового слоя обработки запроса, в GraphQL запросы отрабатывают медленее;

⦁ Коды состояния - большим преимуществом REST является возможность использовать коды состояния, о которых написано выше. В GraphQL , если запрос дошёл до сервера и вернулся обратно - будет 200 ответ, вне зависимости от того, как отработал этот запрос. Стандартный ответ от GraphQL содержит поля data и errors. Если запрос отработал некорректно, то ошибка появится в поле errors, но будет возвращён 200 ответ от сервера.


Вернуться в бэклог категории Web Открыть/Комментировать

2021-11-15 19:00:29 Конспект по теме "GraphQL" из темы "Web"

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

Основные характеристики GraphQL:
⦁ позволяет клиенту точно указать какие данные ему нужны - запросить не всю модель, а только нужные ему поля;
⦁ использует систему типов для описания данных. Для этого генерируется схема используемых данных.

Основным достоинством GraphQL является то, что вместо большого количества простых endpoint-ов, мы получаем 1 умный endpoint. Т.е. бэк предоставляет возможность запросить определённую модель, а фронт уже запрашивает только то, что ему нужно. Это позволяет не плодить endpoint-ы, а также не перегружать фронт хранением лишних данных, пришедших с бэка.

Есть 3 типа операций:
⦁ запрос - клиент запрашивает данные с сервера;
⦁ мутация - клиент добавляет/изменяет данные на сервере;
⦁ подписка - клиент подписывается на некое действие сервера и слушает его обновления в лайв-режиме.

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

GraphQL - это одна из реализаций при паттерне BFF. Фронтенд кидает запросы на BFF с помощью GraphQL, BFF дальше кидает запросы уже на микросервисы с помощью REST.


Вернуться в бэклог категории Web Открыть/Комментировать

2021-11-15 18:53:41 Конспект по теме "Rest API" из темы "Web"

Это способ взаимодействия и обмена данными с сервером.

Есть 4 основных метода работы REST:
⦁ GET - получение;
⦁ POST - добавление;
⦁ PUT - обновление;
⦁ DELETE - удаление.

Стандартные коды ответов в REST:
⦁ 1** - информационный;
⦁ 2** - успешно;
⦁ 3** - редирект;
⦁ 4** - ошибка клиента;
⦁ 5** - ошибка сервера.

Основные составляющие:

1. Ресурсы - это данные, на которых мы хотим выполнить операцию. Т.е. данные которые возвращаются при GET-запросе и являются обёрнутыми в JSON - это ресурсы;
2. Методы запросов - GET, POST, PUT, DELETE. Это действия, которые будут совершаться над ресурсами;
3. Заголовки запроса - там м.б. передана дополнительная информация. Например, авторизационные данные (JWT);
4. Тело запроса - это данные, которые м.б. отправлены вместе с запросом;
5. Тело ответа - содержимое ответа от сервера клиенту;
6. Код ответа - код ответа от сервера.

Преимущества:
⦁ Универсальность - у сервисов, написанных на различных языках, есть возможность взаимодействовать друг с другом, оперируя общими понятиями;
⦁ Отсутствие состояния - при каждом запросе от клиента сервер будет заново отдавать ему свежие данные, не запоминая, что этот клиент к нему уже обращался. Т.е. это протокол без сохранения состояния.


Вернуться в бэклог категории Web Открыть/Комментировать

2021-11-15 18:11:06 Конспект по теме "Связанность и связность" из категории "Архитектура"

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

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

Связность модуля показывает насколько модуль является связным/целостным/единым с точки зрения его использования. В идеале, модуль должен выполнять одну задачу и иметь минимальное количество точек управления.

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

Основной способ достижения слабосвязанного кода - уменьшение связей между классами, использование абстракций.


Вернуться в бэклог категории Архитектура Открыть/Комментировать

2021-11-15 17:53:24 Конспект по теме "Ref, out" из категории "C#"

При передаче параметров значимого типа в метод с использованием ref или out - они передаются туда по ссылке.

Ref (входной параметр):
⦁ При передаче ref переменной внутрь метода, она должна обязательно быть проинициализированной снаружи метода;
⦁ При изменении ref переменной внутри метода, её значение также меняется снаружи метода, т.к. она передаётся по ссылке;
⦁ Ref переменная может и не менять своё значение внутри метода;
⦁ Методу может быть передано несколько ref переменных.

Out (выходной параметр):
⦁ При передаче out переменной внутрь метода, она не должна быть обязательно проинициализированной снаружи метода;
⦁ При изменении out переменной внутри метода, её значение также меняется снаружи метода, т.к. она передаётся по ссылке;
⦁ Out переменная обязательно должна получить значение внутри метода;
⦁ Методу может быть передано несколько out переменных.

Резюме:
⦁ Ref предпочитают использовать, когда переменная используется снаружи метода и может поменять своё значение внутри метода;
⦁ Out предпочитают использовать, когда метод должен вернуть несколько значений;
⦁ Ref - мы понимаем, что метод МОЖЕТ изменить значение переменной;
⦁ Out - мы знаем, что метод ОБЯЗАН изменить значение переменной.


Вернуться в бэклог категории C# Открыть/Комментировать