d2funlife | Блог о программировании

Видосики #1

d2funlife@gmail.com (Danil Pavlov) — Tue, 17 Sep 2019 10:55:42 GMT

Hidden gems in .NET Core 3 - David Fowler & Damian Edwards

Релиз .NET Core 3 готовит огромную пачку улучшений и изменений. Данный доклад в сжатом формате представляет основные нововведения, изменения. Изменений очень много. Таймкоды для быстрой навигации:

1:06 ограничения для GC (сборщика мусора)
1:45 пример графика с новыми ограничениями GC
2:20 AssemblyLoadContext API, новая возможность для плагинов, библиотеки можно зрагрузить и выгрузить в отдельном контексте.
7:19 Startup hooks - код, который будет выполняться перед методом Main
9:25 новые кроссплатформенные инструменты для диагностики приложений
18:58 3 новых опции для публикации приложений
27:56 улучшения взаимодействия с нативным кодом
29:46 IAsyncDisposable - неблокирующее выполнение dispose объекта
30:54 распределенная трассировка запросов пользователя (пример: https://zipkin.io/)
38:30 определение функций среды во время выполнения кода
39:17 улучшения threadpool
40:09 Process.Kill, BitOperations, Microsoft.VisualBasic, DbCommand async
41:13 UnixDomainSocket - отказ от библиотеки libuv в Kestrel
42:00 Интеграция статический данных (скриптов, картинок и т.д.) в представления Razor
43:10 переменные IIS сервера теперь доступны для ASP.NET Core приложений
43:16 System.IO.Pipelines
44:22 Новые сетевые абстракции. Kestrel теперь имеет изолированый транспортный API. API можно использовать для написания собственных клиетов и серверов.
48:25 LOL 😂
53:26 HostMatcherPolicy, HostAttribute. Теперь есть возможность действие контроллера привязать к домену или порту приложения!
56:38 TrailingHeaders - возможность отправить заголовок после отправки тела ответа. Используется для отправки служебной информации, метрик. Добавлено для полной поддержки gRPC
57:20 улучшена страница ошибки для разработчика. Теперь поддерживается отправка данных без HTML.
58:05 улучшения компрессии данных
58:49 интеграция systemd. Возможность запускать демоном свое приложение под linux ос.
58:55 IConfigurationRoot.GetDebugView - получение снимка все конфигурационных парамеров
59:03 SystemProviderOPtions.ValidateOnBuild - возможность проверить, что зависимости (DI) настроены корректно
59:21 валидация options - проверка что все объекты конфигураций корректы
59:43 LoggerFactory.Create - теперь более легко создать фабрику логирования для использования в приложениях без DI
59:50 добавили возможность получать конфигурации из потоковых источников. Существующие файловые методы конфигураций перевели на потоковые.

Отличный доклад от очень крутых программистов. Интересная подача, лайвкодинг.

Как добавить свою оптимизацию в JIT, Егор Богатов

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

IDE wars: мы, наши друзья, наши соперники и наши...партнёры (Кирилл Скрыган)

История становления JetBrains, на каком этапе развития IDE как таковой мы находимся. Почему Visual Studio Code не сможет обогнать IDE от JetBrains. И как же языки программирования и экосистемы для программистов влияют на огромный бизнес и большие корпорации. Так же рассказано как конкурирует Microsoft и JetBrains.

Be More Productive with JetBrains Rider

Если по воле обстоятельств или нелепой случайности вы не пробовали в деле JetBrains Rider, данное видео может быть коротким экскурсом в основные особенности этой IDE. Продемонстрированны особенности редактирования кода, а так же обвязка дополнительных инструментов, которые делают Rider отличным швейцарским ножом.

TeamCity, Docker и два бранча!

d2funlife@gmail.com (Danil Pavlov) — Tue, 16 Jul 2019 23:47:41 GMT

Для многих контейнеризация стала стандартом распространения сервисов. TeamCity же один из лучших инструментов для организации CI\CD. Что же, давайте сольем все в одну емкость и получим прекрасный коктейль, который будет помогать и радовать нас. По пути разберемся, как использовать параметры и шаблоны конфигураций. Для реализации данных сценариев я буду использовать проект движка блога (вы сейчас его читаете). Что мы имеем и что хотим в итоге получить: сборка asp.net core проекта в docker образ, публикация образа в репозиторий, запуск сценария обновления на удаленном сервере. Опционально можно так же добавить проставление тега на последний коммит обработанных изменений. На уровне "Root project" добавляем проект:

В репозитории имеется две ветки - master и develop, давайте сделаем публикацию develop на тестовый домашний сервер. Позже добавим публикацию master на production сервер. Настроим как первый источник ветку develop. В настройках проекта раздел "Version Control Settings":

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

Для более простого понимания устройства TeamCity: все проекты — это дерево с общим корнем в виде "Root project" и дочерние проекты, которые наследуют все параметры у родителей. Таким образом можно описывать в родительских проектах общие параметры конфигурации и расширять конфигурацию собственными параметрами в дочерних проектах. Каждый проект состоит из конфигураций, от одной и более. Конфигурация состоит из build step’ов, которые описывают действия и выстраиваются в определенный порядок – цепочка действий, которая приводит к результату конфигурации. Создадим первый build step для построения docker образа проекта:

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

Внимательный читатель обратит внимание, что указаны переменные конфигурации (%dockerLogin% и %dockerPassword%), а мы их еще не добавляли. Давайте же сделаем это. Так, как я уже описывал, TeamCity – дерево, и мы можем добавлять параметры конфигурации, которые будут доступны для всех дочерних уровней от корневого. Если у вас используется какой-то конкретный аккаунт для проекта, то можно указать его в параметрах проекта, если же параметры будут общими и для других проектов, то можем их указать на уровне "Root project" и они будут доступны везде.

Помечая параметры как hidden + password мы обеспечиваем защиту и скрытие отображения значений этих параметров в логах при билде проекта. После того как мы залогинились, мы можем публиковать наш образ, для этого добавим еще один build step:

И остается финальный build step, который будет запускать цикл обновления нашего сервиса на удаленном сервере. Путей решения этого вопроса просто уйма, я же буду запускать скрипт на сервере через SSH:

Готово! Теперь мы получили полностью готовый цикл, который будет обновлять сервис при изменениях в ветке develop. "Хорошо, для master ветки копируем и все работает, все понятно, мы читать дальше не будем" – так могли подумать вы... и это может быть нормальный вариант. Но я предложу чуточку шагнуть дальше и создать шаблон конфигурации. Шаблон конфигурации используется, если у вас есть разные конфигурации по параметрам, но одинаковые по сути. И редактирование множества конфигураций сводится к редактированию шаблона. К примеру, у вас поменялся сценарий публикации приложения, необходимо добавить еще один build step, но если конфигурации копировались отдельно, то отдельно придется и настраивать дополнительный шаг везде. Шаблон же позволяет сделать это в одном месте, конфигурация унаследует шаблон, наполняя его только своими параметрами.

Для того, чтоб добавить шаблон у нас сейчас есть два варианта: сгенерировать шаблон из конфигурации develop и потом только выделить параметры, либо создать все с нуля и привязать к конфигурациям. Я сгенерирую шаблон и вычленю наши ключевые конфигурации в переменные:

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

Вот так мы можем настроить TeamCity для тесного содружества с docker и обновлять сервера без проблем. И да, опциональное проставление тегов на последний коммит в изменениях. Для чего нужно - если у вас идет очень много изменений, то да бы иметь историю версий прямо в гите, рекомендуется проставлять теги. Мы можем сделать это автоматически, для этого нам необходимо зайти в конфигурацию и в настройках Build Features добавить VCS labeling:

Теперь точно все, если у вас есть вопросы, замечания, велкам в комменты!

Создаем скриншот и pdf документ из веб страницы

d2funlife@gmail.com (Danil Pavlov) — Fri, 21 Sep 2018 06:12:55 GMT

Все мы любим фоточки, а прикиньте фоточки нужной веб страницы в полный рост! А если это все в pdf по формату читалки?! Да это же крутяк! Можно накидать статей в читалку, очистить список непрочитанного в pocket. Делаем! Нужен фотик для всего этого, и тут вариантов для реализации много, да вот только не все они хорошие. PhantomJS - для сложных страниц не подходит, хоть и идея хороша, к тому же проект, судя по всему, уже все, того... Для нормального отображения веб страницы нужен "полноценный" браузер. И тут очень в тему будет SeleniumHQ - инструмент автоматизации браузера, как заявляют на главной. Отлично, фото в полный рост будет, а что насчёт pdf? Тут все как обычно - куча платных библиотек, есть и бесплатные, но со звездочкой, есть и без звездочек, но они существуют как отдельное приложение. Как вариант, я выбрал iTextSharp. Для opensource проектов они предоставляют бесплатное использование - нам подходит. А теперь собирем все вместе и да начнется фотосет!

Для получение скриншота страницы нам нужен SeleniumHQ + Chrome. Так как мы уже прошареные ребята, то знаем как можно получить желаемое максимально быстро. Да-да, Selenium Docker и всех делов. Для запуска нам нужно всего-то выполнить одну команду для запуска контейнера.

docker run -d -p 4444:4444 -v /dev/shm:/dev/shm selenium/standalone-chrome:3.14.0-curium

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

var driver = new RemoteWebDriver(new Uri("http://localhost:4444/"), new ChromeOptions());
driver.Navigate().GoToUrl("https://google.com");

//Устанавливаем размер окна
driver.Manage().Window.Size = new Size(1024, 768);

//Перемещаем скрол на нужную позицию
driver.Manage().Window.Position = new Point(0, 0);

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

private Image GetFullPageImage(IWebDriver driver, ShotOptions options)
{
    ResizeBrowser(driver,
                  options.Width + ScrollWidthOffset,
                  options.StepHeight + MenuHeightOffset);

    var jsExecutor = (IJavaScriptExecutor) driver;

    LoadAllPageHeight(jsExecutor);

    var pageSizes = GetWebPageSizes(jsExecutor);
    if (pageSizes.TotalWidth > pageSizes.ViewportWidth)
    {
        ResizeBrowser(driver,
                      options.Width + ScrollWidthOffset,
                      options.StepHeight + MenuHeightOffset + ScrollWidthOffset);
    }

    var rectangles = new List<Rectangle>();
    for (var yScroll = 0; yScroll < pageSizes.TotalHeight; yScroll += pageSizes.ViewportHeight)
    {
        var rectangleHeight = pageSizes.ViewportHeight;
        if (yScroll + pageSizes.ViewportHeight > pageSizes.TotalHeight)
        {
            rectangleHeight = pageSizes.TotalHeight - yScroll;
        }

        var currRect = new Rectangle(0, yScroll, options.Width, rectangleHeight);
        rectangles.Add(currRect);
    }

    var takerScreenshot = (ITakesScreenshot) driver;
    var fullPageImage = new Bitmap(options.Width, pageSizes.TotalHeight);
    var graphics = Graphics.FromImage(fullPageImage);

    var yPosition = 0;
    for (var rectangleIndex = 0; rectangleIndex < rectangles.Count; rectangleIndex++)
    {
        jsExecutor.ExecuteScript($"window.scroll(0, {yPosition.ToString()})");

        if (rectangleIndex > 0 ||
            options.HideOverlayElementsImmediate)
        {
            HideFloatingElements(jsExecutor);
        }

        var rectangle = rectangles[rectangleIndex];
        var screenshot = takerScreenshot.GetScreenshot();
        var screenshotImage = ScreenshotToImage(screenshot);

        var sourceRectangle = new Rectangle(0,
                                            pageSizes.ViewportHeight - rectangle.Height,
                                            rectangle.Width,
                                            rectangle.Height);

        graphics.DrawImage(screenshotImage, rectangle, sourceRectangle, GraphicsUnit.Pixel);

        yPosition = rectangle.Bottom;
    }

    return fullPageImage;
}

А когда у нас есть полная картинка мы можем делать уже все, что нам вздумается. А вздумается нам получить pdf документ для электронной читалки. Для полного удовлетворения потребностей нам нужно перевести изображения в черно-белый цвет и минимизировать. Каждая страница документа представляет из себя изображение на весь размер. Формирование pdf документа:

private PdfShot GetPdfDocument(Image fullPageImage, ShotOptions options, String title)
{
    var magicImage = new MagickImage(fullPageImage.ToMemoryStream());
    magicImage.Strip();

    if (options.IsGrayscale)
    {
        magicImage.Grayscale(PixelIntensityMethod.Lightness);
        magicImage.Contrast();
    }
    
    var partsCount = Math.Ceiling((Decimal) magicImage.Height / options.StepHeight);
    partsCount = Math.Ceiling((magicImage.Height + options.OverlaySize * partsCount) / options.StepHeight);
    
    var pageImageParts = new List<Byte[]>();
    for (var i = 0; i < partsCount; i++)
    {
        var y = i * options.StepHeight - i * options.OverlaySize;
        var images = magicImage.CropToTiles(new MagickGeometry(0,
                                                               y,
                                                               options.Width,
                                                               options.StepHeight))
                               .ToList();
        pageImageParts.Add(images.First().ToByteArray());
    }
    
    var pdfBytes = _pdfCreator.CreateDocument(options.Width, options.StepHeight, pageImageParts);
    return new PdfShot(pdfBytes, GetFileName(title));
}

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

Примечания

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

Из неприятного, но факт: при некорректном использовании веб драйвера, вы можете получать ошибки по типу "session does not exist". Еще имеется открытый issue на github, который указывает на проблему использования подключений. При интенсивной нагрузке подключения множатся, драйвер работает в этом плане неверно.

Исходный код: https://github.com/d2funlife/screenshooter

Примечания по запуску под Linux: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx

Appveyor + Docker = ❤

d2funlife@gmail.com (Danil Pavlov) — Tue, 10 Jul 2018 12:39:10 GMT

Не так давно Appveyor добавили поддержку Linux агентов сборки, а это значит, что пришло новое счастье для множества open source проектов. Ведь раньше для сборки проекта под Linux необходимо было использовать что-то другое, например Travis CI, и выглядело это все как-то так:

И все бы хорошо, но скорость Travis CI для открытых проектов оставляет желать лучшего. Сейчас же мы можем построить полный цикл неприрывной интеграции (CI) на Appveyor. Я хочу рассказать, как настроить сборку docker образа, публикацию образа в репозиторий, а так же запуск скрипта для обновления docker контейнеров. Все примеры подразумевают использование open source проектов и не требуют оформления подписки. Если интересно, как скрыть приватные файлы конфигураций в открытом проекте, а так же не иметь проблем с доступом к этим файлам уже в docker контейнере, пишите комментарии, опишу отдельно этот вопрос.

Appveyor поддерживает конфигурацию в 2х режимах - через визуальную админ часть или через конфигурационные файлы *.yml. Оба подхода имеют одну и ту же суть, разница в том, что админ часть создает конфигурационный файл на сервере и после использует его, а ручной вы можете создать в любом текстовом редакторе и использовать его, храня у себя в исходном коде. По умолчанию используется серверная конфигурация, но если добавить конфигурационный файл в репозиторий вашего проекта, то будет использоваться он. Я покажу всю настройку на примере собственного файла. В качестве подопытного выступает непосредственно этот блог. Для него сформирована следующая конфигурация:

# Версия, которая будет присваиваться каждой сборке. Переменная build - инкремент номера сбороки.
version: 1.0.0.{build}
# Образ виртуальной машины на которой будет происходить сборка.
image: ubuntu

# Глубина клонирования репозитория. По умолчанию клонируется вся история. Флаг 1 указывает клоинирование без истории.
clone_depth: 1

# Номер сборки не будет инкрементироваться при создании pull request'а.
pull_requests:
  do_not_increment_build_number: true

# Переменные окружения.
environment:
  DOCKER_PASS:
    secure: tyCs62GdU59M1vNsnAwKrw==
  DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
  DOTNET_CLI_TELEMETRY_OPTOUT: true

# Параметр указывает, что сборка будет производиться только при изменении master ветки. По умолчанию сборка производится на всех ветках.
branches:
  only:
    - master

skip_commits:
  files:
    - README.md

install:
- docker version

build_script:
- ps: .\build.ps1

# Этап выполнения тестов отключен
test: off

# Используется потому как не поддерживается скрипт и провайдер одновременно в deploy
before_deploy:
- ps: .\deploy.ps1

deploy:
- provider: Webhook
  url:
    secure: bwtxM3PwlQqNCxXgKZ7Aul9FWEx9OTMjV4suCKf0E6vOI
  authorization:
    secure: xFex7sajn/RKjS/cZrqSJnEjrhRO4535ALSzvC+OjzY7xVlq==
  on:
    branch: master

К каждому пункту конфигурации добавлены комментарии, так будет проще и быстрее понять общий сценарий. Отдельно отмечу официальную документацию https://www.appveyor.com/docs/ в ней расписаны детально все ньюансы, но только на английском языке. Давайте посмотрим непосредственно на скрипты build.ps1 и deploy.ps1. Они запускаются в соответствующие названию этапы обработки. К каждому этапу можно добавить сразу несколько скриптов.

build.ps1 - скрипт запускает сборку docker образа и присваивает ему сразу несколько тегов.

$Version=$env:APPVEYOR_BUILD_VERSION
Write-Host Starting build $Version

docker build -t d2funlife/blog:latest -t d2funlife/blog:$Version .

deploy.ps1 - скрипт логинится в docker hub репозиторий и выполняет push образа, который мы собрали на предыдущем этапе.

$Version=$env:APPVEYOR_BUILD_VERSION
Write-Host Starting deploy $Version

docker images

Write-Host Docker login

$env:DOCKER_PASS | docker login --username d2funlife --password-stdin

Write-Host Push to docker hub

docker push d2funlife/blog

И когда образ опубликован, остается только один вопрос - как же обновить его на нашем хосте. Список доступных вариантов деплоя представлен в документации https://www.appveyor.com/docs/deployment/. К сожалению, не поддерживается выполнение ssh команды на удаленном сервере. С использованием docker контейнеров мы можем запустить такой сценарий, но это что-то из разряда костылей и подпорок + необходимо быть внимательным к вопросу безопасности. Хорошей альтернативой является Webhook. Это веб-запрос на указаный вами url, с параметрами авторизации (для безопасности). Приняв запрос на сервере, вы можете выполнить необходимую команду для обновления docker контейнеров. Я сделал простой веб-сервис на .NET Core, который принимает запрос и запускает shell скрипт обновления. Таким образом мы получаем полностью настроенную непрерывную интегарцию с помощью Appveyor.

Docker в быту разработчика

d2funlife@gmail.com (Danil Pavlov) — Sun, 10 Jun 2018 18:34:54 GMT

В последнее время сталкиваюсь с такими двумя фразами, относительно docker, первая - "Зачем мне нужен docker, у меня монолитное приложение, менять ничего не нужно, все уже отлажено", и вторая - "Я видел пару статей про docker, интересно будет разобраться, но потом как-то выделю время на это". Постараюсь дать свои комментарии на обе фразы.

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

Docker закрывает множество проблем инфраструктурного характера. Вы можете решить проблемы с ограничением ресурсов для своего приложения, создать без особых проблем кластер и многое другое. Ко всему этому, вы получаете возможность "портативного" использования своих контейнеров вне зависимости от вашей операционной системы. Так, к примеру, у разработчика есть виртуальная машина, где уже все настроено как ему удобно и нужно, где провел немало часов. И вдруг нужно перенести виртуалку на другой компьютер, и хорошо, если операционные системы совпадают, можно решить проблему копированием огромных образов и установкой нужного софта, а если вы работали на windows под Hyper-V, а теперь вам нужно получить тоже самое для Mac OS или Linux, то обычным копированием влоб не удастся решить эту проблему. В свою очередь, docker позволил бы решить эту проблему обычным копированием скрипта запуска контейнера и переносом данных. Многие .NET разработчики использовали MS SQL Server на своих компьютерах и знают, что сам процесс установки его вручную - боль еще та, и к тому же, по итогу получаем кучу фоновых сервисов, которые работают всегда, а если это компьютер личного пользования, то сервисы работают даже тогда, когда в них нет нужды. Подобную проблему очень легко решить с помощью docker, ведь мы получаем полностью изолированную “песочницу”, в которой можем делать все, что захотим. Когда вам нужно, можно просто остановить контейнер с приложением и расхода ресурсов нет, ваша основная операционная система чиста. Для SQL Server Microsoft предоставили официальный docker образ, который можно использовать в своих нуждах. Что же такое контейнер и образ? Образ приложения - готовый пакет софта и данных, который вы можете запустить, а вот когда вы его запустите, то получите контейнер. По сути контейнер - рабочий экземпляр (instance) вашего софта. Для нетерпеливых новичков приведу примеры готовых скриптов для запуска популярных приложений.

Установка docker под разные платформы описана здесь: EN + Windows RU + Ubuntu

Запустим MS SQL Server в контейнере. Для этого нам нужно будет выполнить следующую команду:

docker run --name mssql -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=givemedata' -p 1433:1433 -d --restart unless-stopped -v mssql-data:/var/opt/mssql/data -v C://docker//backups:/var/backups microsoft/mssql-server-linux:latest

Отмечу, что "C://docker//backups" - путь директории, которая будет общей с вашим контейнером, куда вы можете забросить нужные вам резервные копии баз данных для восстановления или откуда вы можете забрать созданные копии баз.

Запустим RabbitMQ:

docker run --name rabbit -d --restart unless-stopped -p 8004:15672 -p 8001:5672 -v rabbitmq:/var/lib/rabbitmq -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=pass rabbitmq:3-management

"-p 8004:15672" - это указание связи порта, который будет в вашей операционной системе и на который будет направляться запрос внутрь контейнера. Порт можно изменить с 8004 на любой свободный\желаемый.

Для запуска "пар" контейнеров можно использовать команду "docker-compose up -d". Отличие в том, что нам необходимо описать docker compose файл с указанием необходимых сервисов и их параметров. Приведу docker compose файл для запуска postgresql + pgAdmin. Отмечу, что разработчики pgAdmin в последней версии (4 v3.0) добавили официальный образ docker. Для запуска рекомендую создать отдельную директорию и в нее поместить файл docker-compose.yml со следующим содержанием.

Docker compose для Postgres SQL + pgAdmin 4:

version: '3.1'

services:
    db:
        image: postgres
        volumes:
            - db-data:/var/lib/postgresql/data
            - C://docker//backups:/var/lib/postgresql/backups
        ports:
            - 8002:5432
        environment:
            - POSTGRES_PASSWORD=givemedata
        restart: unless-stopped
        networks:
            - net

    admin:
        image: dpage/pgadmin4
        volumes:
            - admin-data:/var/lib/pgadmin
            - C://docker//backups:/var/lib/pgadmin/storage/admin/backups
        ports:
            - 8003:80
        environment:
            - PGADMIN_DEFAULT_EMAIL=admin
            - PGADMIN_DEFAULT_PASSWORD=admin
        restart: unless-stopped
        networks:
            - net

volumes:
    db-data:
    admin-data:

networks: 
    net:

Все что остается, выполнить команду docker-compose up -d в доступном CLI инструменте (powershell/shell/bash).

Приведу репозиторий docker-infrastructure, где можно будет забрать остальные docker compose файлы, файл с общими командами для запуска инструментов.

Для более наглядного управления и понимания состояния всего, что связано с docker, рекомендую использовать Portainer. Он имеет очень большой функционал и позволяет уйти от командной строки + отобразить все, что происходит и хранится в вашем docker. Особенно полезно, если места на диске мало, а неиспользуемых образов скопилось много. C Portainer можно быстро выбрать и удалить не нужные образы, сохранить место на диске.

Запуск Portainer:

docker run --name portainer -d --restart unless-stopped -p 8000:9000 -v portainer:/data -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer

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

ASP.NET MVC жизненный цикл запроса

d2funlife@gmail.com (Danil Pavlov) — Wed, 20 Sep 2017 20:05:25 GMT

Как бы смешным не казалось, но эту статью можно начать философским вбросом про смысл жизни, куда мы движемся, и то, что движемся по спирали, и все события повторяются. Ведь посудите сами – у всего есть жизненный цикл, многие процессы имеют некую "циклическую" составляющую. И я хочу вам, мои друзья, рассказать про тот самый смысл жизни и типичную жизнь тривиального запроса в ASP.NET MVC приложении. Основой классического ASP.NET MVC приложения является IIS он и является той самой отправной точкой на длинном пути запроса "от появления на сервере до отправки ответа". Картина прихожей для запросов выглядит следующим образом:

Подробное описание устройства и взаимодействия всех частей цепочки описано в статье на хабрахабре. Отдельно хочу отметить список источников, приведенный в статье. Цель данной статьи рассказать, что именно происходит между 6м и 7м шагом на данной схеме, рассказать про устройство и всю цепочку работы ASP.NET MVC приложения. Путешествие с запросом происходит по следующей цепочке действий:

Здесь видно два "острова", которые соединены мостами. Один из них — это платформа HTTP приложения, если предметнее: открыв Global.asax, мы увидим, что ключевой класс, где происходит конфигурация нашего приложения, наследуется от HttpApllication (System.Web). HttpApplication и дает базу для нашего приложения, в том числе и события из списка выше, которые можно использовать из Global.asax.cs, либо подключаться к событиям, реализуя свой HTTP модуль (IHttpModule). Пример всех этих точек расширения HttpApplication можно посмотреть тут - исходный код. Используя данный пример, можно в режиме отладки пройти все шаги один за одним и проверить правильность порядка и существование точки расширения в принципе. Уровень HTTP приложения и интеграция его с MVC приложением будет рассмотрен в отдельной статье. В данной статье будет рассмотрен исключительно второй "остров" нашей карты, с его остановками в виде маршрутизации (routing), инициализации контроллера (controller initialization), выполнением действия контроллера (action excecution) и выполнением результата действия (result execution).

MVC цикл

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

Routing (Маршрутизация)

Первой остановкой запроса является подсистема маршрутизации, ведь необходимо определить, какой цели должен достигнуть наш запрос, какое действие и какого контроллера является для него желанным, а может быть запросу вовсе нужен статический файл, а не контроллер, в любом случае необходимо получить некую пару "ключ – значение" для маршрута и единицы, которая будет его обрабатывать дальше. Эта единица называется "обработчик запроса" (route handler) и ее задача вернуть объект HttpHandler, который будет выполнять всю дальнейшую цепочку обработки запроса. Неопытный программист задастся вопросом "какой route handler? Ведь мы при старте приложения просто указываем общий шаблон в текстовом варианте и все. Там нет указания каких-либо route handler, только имя контроллера и действия по умолчанию". И здесь тот момент, когда оптимизации и улучшения сыграли злую шутку с программистом и он не знает внутренних тонкостей из-за того, что их скрыли от него. Пример объявления маршрутизации по умолчанию:

// пример регистрации маршрута по умолчанию
routes.MapRoute(name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional });

Все красиво, все просто: передаем имя маршрута, шаблон url запроса, анонимный объект, который указывает названия контроллера и действия по умолчанию. Но MapRoute – это расширяющий метод, который скрывает за собой реальную логику добавления маршрута в таблицу маршрутизации.

//метод расширения для добавления маршрута в таблицу
public static Route MapRoute(this RouteCollection routes, string name, string url, object defaults, object constraints, string[] namespaces)
{
    if (routes == null)
    {
        throw new ArgumentNullException("routes");
    }
    if (url == null)
    {
        throw new ArgumentNullException("url");
    }

    Route route = new Route(url, new MvcRouteHandler())
    {
        Defaults = CreateRouteValueDictionaryUncached(defaults),
        Constraints = CreateRouteValueDictionaryUncached(constraints),
        DataTokens = new RouteValueDictionary()
    };

    ConstraintValidation.Validate(route);

    if ((namespaces != null) && (namespaces.Length > 0))
    {
        route.DataTokens[RouteDataTokenKeys.Namespaces] = namespaces;
    }

    routes.Add(name, route);

    return route;
}

Пример добавления маршрута в таблицу маршрутизации без использования расширяющих методов:

//Добавление маршрута в таблицу маршрутизации без расширяющих методов
var myRoute = new Route("{controller}/{action}/{id}",
              new RouteValueDictionary { { "controller", "Home" }, { "action", "Index" }, { "id", "1" } },
              new MvcRouteHandler());
routes.Add(myRoute);

Вот тут уже более наглядно будет видно, что за route handler и как они вообще попадают в маршрутизацию. Сам класс обработчика маршрута реализует интерфейс IRouteHandler у которого есть единственный метод GetHttpHandler, возвращающий HttpHandler. HttpHandler – это тот объект который берет на себя ответственность за генерацию ответа на HTTP запрос, класс этого объекта реализует интерфейс IHttpHandler. Этот интерфейс содержит свойство IsReusable и метод ProcessRequest. IsReusable - флаг, указывающий может ли другой запрос использовать этот же обработчик, иными словами нужно ли ему создавать каждый раз новый экземпляр или можно создать один раз и использовать его для всех последующих запросов. ProcessRequest – метод, который выполняет обработку запроса. По умолчанию используется MvcRouteHandler и MvcHandler. Исходный код открывает все тонкости и оптимизации, которые заложили архитекторы. В реальной жизни очень мала вероятность , что придется создавать собственный HttpHandler, так как стандартные средства ASP.NET MVC покрывают большинство задач. Приведу пример маленького HttpHandler`а, который поздоровается с вами:

//Пример обработчика
public class HelloHandler : IHttpHandler
{
    public bool IsReusable
    {
        get { return false; }
    }
    public void ProcessRequest(HttpContext context)
    {
        context.Response.Write("<p>Hello world</p>");
    }
}

Получить данный обработчик мы можем только из RouteHandler, поэтому сделаем его и зарегистрируем по адресу "home/hello".

//Обработчик маршрута
public class HelloRouteHandler : IRouteHandler
{
    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        return new HelloHandler();
    }
}

//Регистрация обработчика маршрута на определенный урл
routes.Add(new Route("home/hello", new HelloRouteHandler()));

Таким образом мы получим приветствие, которого ждали, но это лирическое отступление с демонстрацией точки расширения в ASP.NET MVC, где вы можете управлять процессом обработки запроса. В стандартном приложении мы получаем MvcRouteHandler, который отдает MvcHandler, а тот в свою очередь запускает нужный контроллер, нужное действие и отдает им нужные данные.

Controller initialization (Инициализация контроллера)

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

//Запуск процеса обработки запроса
private void ProcessRequestInit(HttpContextBase httpContext, out IController controller, out IControllerFactory factory)
{
    HttpContext currentContext = HttpContext.Current;
    if (currentContext != null)
    {
        bool? isRequestValidationEnabled = ValidationUtility.IsValidationEnabled(currentContext);
        if (isRequestValidationEnabled == true)
        {
            ValidationUtility.EnableDynamicValidation(currentContext);
        }
    }

    AddVersionHeader(httpContext);
    RemoveOptionalRoutingParameters();

	//Получение имени контроллера
    string controllerName = RequestContext.RouteData.GetRequiredString("controller");

	//Получение фабрики контроллера
    factory = ControllerBuilder.GetControllerFactory();
	
	//Создание объекта контроллера
    controller = factory.CreateController(RequestContext, controllerName);
    if (controller == null)
    {
        throw new InvalidOperationException(
            String.Format(
                CultureInfo.CurrentCulture,
                MvcResources.ControllerBuilder_FactoryReturnedNull,
                factory.GetType(),
                controllerName));
    }
}

В MVCHandler мы получаем объект фабрики контроллеров (controller factory), который ответственен за получение контроллера и реализует интерфейс IControllerFactory. По умолчанию ControllerBuilder отдает объект класса DefaultControllerFactory. Увидеть это мы можем, посмотрев исходный код:

//Получение фабрики контроллеров в ControllerBuilder
public IControllerFactory GetControllerFactory()
{
    return _serviceResolver.Current;
}

//Конструктор ControllerBuilder
internal ControllerBuilder(IResolver<IControllerFactory> serviceResolver)
{
    _serviceResolver = serviceResolver ?? new SingleServiceResolver<IControllerFactory>(
                                              () => _factoryThunk(),
                                              new DefaultControllerFactory { ControllerBuilder = this },
                                              "ControllerBuilder.GetControllerFactory");
}

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

//Создания контроллера
public virtual IController CreateController(RequestContext requestContext, string controllerName)
{
    if (requestContext == null)
    {
        throw new ArgumentNullException("requestContext");
    }

    if (String.IsNullOrEmpty(controllerName) && !requestContext.RouteData.HasDirectRouteMatch())
    {
        throw new ArgumentException(MvcResources.Common_NullOrEmpty, "controllerName");
    }

	//Получение типа контроллера
    Type controllerType = GetControllerType(requestContext, controllerName);
	
	//Получение объекта контроллера
    IController controller = GetControllerInstance(requestContext, controllerType);
    return controller;
}

//Получение контроллера используя активатор контроллеров
protected internal virtual IController GetControllerInstance(RequestContext requestContext, Type controllerType)
{
    if (controllerType == null)
    {
        throw new HttpException(404,
                                String.Format(
                                    CultureInfo.CurrentCulture,
                                    MvcResources.DefaultControllerFactory_NoControllerFound,
                                    requestContext.HttpContext.Request.Path));
    }
    if (!typeof(IController).IsAssignableFrom(controllerType))
    {
        throw new ArgumentException(
            String.Format(
                CultureInfo.CurrentCulture,
                MvcResources.DefaultControllerFactory_TypeDoesNotSubclassControllerBase,
                controllerType),
            "controllerType");
    }
    return ControllerActivator.Create(requestContext, controllerType);
}

Активатор контроллера по умолчанию реализован в классе DefaultControllerActivator и реализация получения объекта с использованием разрешения зависимостей (dependency resolver) выглядит следующим образом:

private class DefaultControllerActivator : IControllerActivator
{
    private Func<IDependencyResolver> _resolverThunk;

    public DefaultControllerActivator()
        : this(null)
    {
    }

    public DefaultControllerActivator(IDependencyResolver resolver)
    {
        if (resolver == null)
        {
            _resolverThunk = () => DependencyResolver.Current;
        }
        else
        {
            _resolverThunk = () => resolver;
        }
    }

    public IController Create(RequestContext requestContext, Type controllerType)
    {
        try
        {
            return (IController)(_resolverThunk().GetService(controllerType) ?? Activator.CreateInstance(controllerType));
        }
        catch (Exception ex)
        {
            throw new InvalidOperationException(
                String.Format(
                    CultureInfo.CurrentCulture,
                    MvcResources.DefaultControllerFactory_ErrorCreatingController,
                    controllerType),
                ex);
        }
    }
}

_resolveThunk по умолчанию получает объект класса DefaultDependencyResolver, который является оберткой для System.Activator, но если вы подключите собственный dependency resolver, то использоваться будет именно он. Используя различные контейнеры инверсии зависимостей (IoC containers) + внедрение зависимостей (DI), мы расширяем наши контроллеры и можем дополнительно управлять жизненным циклом объектов. Интеграция контейнера присходит посредством класса DependencyResolver, он статичен и имеет метод SetResolver, где и будет установлен наш IoC контейнер, который, в свою очередь, будет получен в активаторе контроллера в конструкторе (тот самый _resolveThunk). И вот, когда контроллер получен, MvcHandler может вызывать метод Execute у контроллера, передав объект RequestContext (контекст запроса) в качестве аргумента. Схематически, в сжатом виде, инициализация контроллера выглядит следующим образом:

Action execution (Выполнение действия)

При выполнении действий контроллера, так же выполняются фильтры. Фильтры — это точки расширения, которые позволяют обогатить код дополнительной логикой. Существуют следующие типы фильтров authentication filters (фильтры аутентификации), authorization filters (фильтры авторизации), action filters (фильтры действий), result filters (фильтры результата действия), exception filters (фильтры исключений). Фильтры действий реализуют интерфейс IActionFilter, в котором определены два метода OnActionExecuting и OnActionExecuted, соответственно они выполняются перед выполнением действия и после выполнения действия. При выполнении цикла запроса фильтры исполняются в следующем порядке:

Фильтры аутентификации
Фильтры авторизации
Фильтры действий
Фильтры результата действия

Фильтры исключений выполняются на любом этапе, ведь ошибки нужно отлавливать и обрабатывать по всему приложению.
В исходном коде класса Controller мы видим, что Controller наследует ControllerBase, в ControllerBase реализован метод Execute и в нем уже вызывается ExecuteCore. ExecuteCore в свою очередь реализован в классе Controller, получив имя действия для выполнения, запускает его на выполнение с исполнением дополнительного уровня в виде ActionInvoker. ActionInvocker в себе инкапсулирует выполнение дополнительных действий (привязку данных, выполнение всех фильтров, запуск на исполнение результата действия) и выполнение самого действия. Все происходит в следующем порядке внутри метода InvokeAction:

Фильтры аутентификации (метод InvokeAuthenticationFilters)
Фильтры авторизации (метод InvokeAuthorizationFilters)
Получение значений параметров, если формальнее "привязка модели" (метод GetParameterValues)
Выполнение действия и фильтров действия (метод InvokeActionMethodWithFilters)
Выполнение результата действия (метод InvokeActionResultWithFilters)

//Выполнение действия контроллера
public virtual bool InvokeAction(ControllerContext controllerContext, string actionName)
{
    if (controllerContext == null)
    {
        throw new ArgumentNullException("controllerContext");
    }

    Contract.Assert(controllerContext.RouteData != null);
    if (String.IsNullOrEmpty(actionName) && !controllerContext.RouteData.HasDirectRouteMatch())
    {
        throw new ArgumentException(MvcResources.Common_NullOrEmpty, "actionName");
    }

    ControllerDescriptor controllerDescriptor = GetControllerDescriptor(controllerContext);
    ActionDescriptor actionDescriptor = FindAction(controllerContext, controllerDescriptor, actionName);

    if (actionDescriptor != null)
    {
        FilterInfo filterInfo = GetFilters(controllerContext, actionDescriptor);

        try
        {
            AuthenticationContext authenticationContext = InvokeAuthenticationFilters(controllerContext, filterInfo.AuthenticationFilters, actionDescriptor);

            if (authenticationContext.Result != null)
            {
                AuthenticationChallengeContext challengeContext = InvokeAuthenticationFiltersChallenge(
                    controllerContext, filterInfo.AuthenticationFilters, actionDescriptor,
                    authenticationContext.Result);
					
                InvokeActionResult(controllerContext, challengeContext.Result ?? authenticationContext.Result);
            }
            else
            {
                AuthorizationContext authorizationContext = InvokeAuthorizationFilters(controllerContext, filterInfo.AuthorizationFilters, actionDescriptor);
                if (authorizationContext.Result != null)
                {
                    AuthenticationChallengeContext challengeContext = InvokeAuthenticationFiltersChallenge(
                        controllerContext, filterInfo.AuthenticationFilters, actionDescriptor,
                        authorizationContext.Result);
						
                    InvokeActionResult(controllerContext, challengeContext.Result ?? authorizationContext.Result);
                }
                else
                {
                    if (controllerContext.Controller.ValidateRequest)
                    {
                        ValidateRequest(controllerContext);
                    }

                    IDictionary<string, object> parameters = GetParameterValues(controllerContext, actionDescriptor);
                    ActionExecutedContext postActionContext = InvokeActionMethodWithFilters(controllerContext, filterInfo.ActionFilters, actionDescriptor, parameters);

                    AuthenticationChallengeContext challengeContext = InvokeAuthenticationFiltersChallenge(
                        controllerContext, filterInfo.AuthenticationFilters, actionDescriptor,
                        postActionContext.Result);
						
                    InvokeActionResultWithFilters(controllerContext, filterInfo.ResultFilters,
                        challengeContext.Result ?? postActionContext.Result);
                }
            }
        }
        catch (ThreadAbortException)            
        {
            throw;
        }
        catch (Exception ex)
        {
            ExceptionContext exceptionContext = InvokeExceptionFilters(controllerContext, filterInfo.ExceptionFilters, ex);
            if (!exceptionContext.ExceptionHandled)
            {
                throw;
            }
            InvokeActionResult(controllerContext, exceptionContext.Result);
        }
		
        return true;
    }

    return false;
}

ActionInoker определяет, какое действие необходимо запустить, для этого берутся за ключевые фильтры: имя действия, параметры действия, атрибуты ActionMethodSelectorAtribute (если добавлены). Такими атрибутами являются HttpGet, HttpPost, к примеру, вы можете добавить свой, для этого просто необходимо создать класс, который наследует ActionMethodSelectorAtribute и переопределяет метод IsValidForRequest. Пример атрибута, который уточнит выбор действия, определив является ли клиент мобильным браузером или нет:

//Дополнительный параметр выборки действия
public class IsMobile : ActionMethodSelectorAttribute
{
    public override bool IsValidForRequest(ControllerContext controllerContext, MethodInfo methodInfo)
    {
        return controllerContext.HttpContext.Request.Browser.IsMobileDevice;
    }
}

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

Result execution (Выполнение результата действия)

В результате выполнения всей цепочки мы получаем объект ActionResult, который вместе с фильтрами результата выполняется в методе InvokeActionResultWithFilters. Данный метод вызывает InvokeActionResultFilterRecursive в котором рекурсивно выполняются фильтры результата и выполняется сам результат. Что значит выполняется сам результат? Объект ActionResult записывает свои данные в ответ запросу. Если действие возвращает JsonResult, то в ответ будет записан сериализованный в json объект, который отдан в результат действия. Если же результатом нашего действия является представление или частичное представление, то будет выполнена следующая цепочка действий:

public override void ExecuteResult(ControllerContext context)
{
    if (context == null)
    {
        throw new ArgumentNullException("context");
    }
    if (String.IsNullOrEmpty(ViewName))
    {
        ViewName = context.RouteData.GetRequiredString("action");
    }

    ViewEngineResult result = null;

    if (View == null)
    {
        result = FindView(context);
        View = result.View;
    }

    TextWriter writer = context.HttpContext.Response.Output;
    ViewContext viewContext = new ViewContext(context, View, ViewData, TempData, writer);
    View.Render(viewContext, writer);

    if (result != null)
    {
        result.ViewEngine.ReleaseView(context, View);
    }
}

Как видно, тут происходит следующее:

В базовом классе ViewResultBase вызывается метод ExecuteResult
Происходит поиск представления для рендера (реализован в классе ViewResult) по всем движкам представлений (ViewEngines)
Найденное представление отправляется на рендер
Результат рендера записывается в ответ на запрос

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

//код движка представления
public class ThemeViewEngine : RazorViewEngine
{
    public ThemeViewEngine()
    {
        ViewLocationFormats = new string[] { "~/Themes/{1}/{0}.cshtml" };
        PartialViewLocationFormats = new string[] { "~/Themes/{1}/{0}.cshtml" };
    }
}

//регистрация движка представления
protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    ViewEngines.Engines.Insert(0, new ThemeViewEngine());
}

Данный пример объясняет цепочку вызовов, когда результатом является представление, если у нас более простой ответ, к примеру, ContentResult, то вся цепочка выглядит куда проще:

public class ContentResult : ActionResult
{
    public string Content { get; set; }

    public Encoding ContentEncoding { get; set; }

    public string ContentType { get; set; }

    public override void ExecuteResult(ControllerContext context)
    {
        if (context == null)
        {
            throw new ArgumentNullException("context");
        }

        HttpResponseBase response = context.HttpContext.Response;

        if (!String.IsNullOrEmpty(ContentType))
        {
            response.ContentType = ContentType;
        }
        if (ContentEncoding != null)
        {
            response.ContentEncoding = ContentEncoding;
        }
        if (Content != null)
        {
            response.Write(Content);
        }
    }
}

Вот так мы и подошли к концу цикла запроса в MVC, в следующей статье завершим детальный обзор цикла HTTP приложения, получив полную картину, как работает само приложение, как обрабатываются запросы от пользователей. Если вы захотите сами побродить по просторам MVC приложения, то это можно сделать, скачав код тут : https://aspnetwebstack.codeplex.com или тут : https://github.com/ASP-NET-MVC/aspnetwebstack. Сodeplex уходит в прощальную гастроль, но официальный репозиторий пока только там, на github не завезли еще, только не официальное зеркало. Так же посмотрите подробные диаграмы жизненного цикла от Microsoft Lifecycle of an ASP.NET MVC 5 Application

ASP.NET Core обработка ошибок

d2funlife@gmail.com (Danil Pavlov) — Sun, 27 Aug 2017 17:00:57 GMT

Единственная настоящая ошибка — не исправлять своих прошлых ошибок. Конфуций.

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

Для обработки ошибки выделим три ключевых шага, которые необходимо выполнить:

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

Ключевой особенностью ASP.NET Core MVC приложений, по сравнению с ASP.NET MVC, является то, что в основу архитекторы заложили принцип объединения в цепочку отдельных функциональных частей (middleware).

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

Try catch в своем коде.
Фильтры исключений MVC.
“Try catch” на уровне middleware.

Обработка на уровне своего кода предельно ясна и ее рассматривать мы не будем. Для MVC мы можем использовать фильтр исключения. Для этого нам нужно создать фильтр исключения и зарегистрировать его для всех действий контроллеров. Код фильтра:

//Класс фильтра ошибок
public class GlobalExceptionFilter : IExceptionFilter
{
    private readonly ILogger<GlobalExceptionFilter> _logger;

    public GlobalExceptionFilter(ILogger<GlobalExceptionFilter> logger)
    {
        _logger = logger;
    }
    public void OnException(ExceptionContext context)
    {
        _logger.LogError(0, context.Exception, context.Exception.Message);

        context.ExceptionHandled = true;
        context.Result = new ViewResult {ViewName = "Error-500"};
    }
}

В фильтре мы логируем нашу ошибку и возвращаем страницу ошибки сервера "Error-500". Что бы добавить фильтр, мы должны зарегистрировать его в глобальные фильтры MVC, то есть фильтры, которые выполняются для всех действий всех контроллеров.

//Добавляем глобальный фильтр, который будет получать информацию об ошибке
services.AddMvc(options =>
{
    options.Filters.Add(typeof(GlobalExceptionFilter));
});

В данном случае мы обработаем все наши Exception и наследуемые от него, но как же отобразить пользователю красивое окно 404, к примеру, когда он пытался посмотреть ресурс, которого нет. Для этого мы добавим обработку HTTP кодов. В компоненте StatusCodePagesMiddleware есть так же методы UseStatusCodePages, UseStatusCodePagesWithRedirects и UseStatusCodePagesWithReExecute. Объясню разницу между 3мя методами.

UseStatusCodePages – использует текстовое представление HTTP кода ошибки, и все что вы можете изменить, это формат и текст сообщения, который увидете в браузере.

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

UseStatusCodePagesWithReExecute – самый оптимальный вариант, так как может вернуть и HTTP код и страницу ошибки в одном флаконе. Для использования мы зарегистрируем компонент:

//Добавляем разденеие обработки ошибок
if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseBrowserLink();
}
else
{
    app.UseStatusCodePagesWithReExecute("/StatusCode/{0}");
}

В строчном параметре {0} будет передано числовое отображение HTTP кода ошибки, с которым мы можем оперировать. Код контроллера с перенаправлением на страницы ошибок:

//Контроллер и действие обработки ошибки
public class StatusCodeController : Controller
{
    private Int32[] _availableCodes = new Int32[] { 404, 500 };

    [Route("/StatusCode/{statusCode}")]
    public IActionResult Index(Int32 statusCode)
    {
        if (!_availableCodes.Contains(statusCode))
            statusCode = 500;
        return View($"Error-{statusCode}");
    }
}

И последняя точка для обработки исключений – обработчик Middleware. Для чего это может быть нужно? Если у нас не используется MVC, а мы написали свой middleware для обработки запроса, то функциональность фильтров из MVC нам не будет доступна, поэтому и используем отдельный middleware для обработки ошибок:

//Middleware для обработки ошибок
public sealed class ExceptionHandlerMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ExceptionHandlerMiddleware> _logger;
    public ExceptionHandlerMiddleware(RequestDelegate next, ILogger<ExceptionHandlerMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }
    public async Task Invoke(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception exception)
        {
            try
            {
                //Обработка ошибки, к примеру, просто можем логировать сообщение ошибки
            }
            catch (Exception innerException)
            {
                _logger.LogError(0, innerException, "Ошибка обработки исключения");
            }
            // Если в коде обработки ошибки мы снова получили ошибку, то пробрасываем ее выше по цепочке Middleware
            throw;
        }
    }
}

Регистрируем наш middleware:

app.UseMiddleware<ExceptionHandlerMiddleware>();

Ключевой момент – обработчик должен быть зарегистрирован раньше всех остальных элементов цепочки, потому как, если произойдет исключение в цепочке до обработчика, то он не будет выполнятся и информацию об ошибке не получит. В ASP.NET Core важен порядок регистрации элементов middleware. Ну и самый простой вариант, это, не создавая свой middleware, обернуть все регистрации в try catch и обработать ошибку. Принцип работы тот же, только менее красиво.

Windows 10 Mobile жив или того? Точка зрения разработчика

d2funlife@gmail.com (Danil Pavlov) — Sun, 08 May 2016 22:19:51 GMT

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

Кто ты такой и почему я должен вообще это дальше читать?

Я разработчик на платформе .NET и имею определенный опыт в разработке Windows Phone приложений. Игру, которую сделали мы с моей женой можно посмотреть по ссылке : Магазин

Общение с мобильными операционными системами из разряда “смартфон” у меня началось с далекого Symbian дальше у меня был Windows Phone 8.0... иии вот я был приверженцем Windows как мобильной, так и пк версии. В целом, полностью мое рабочее пространство составляет инфраструктура от Microsoft и сейчас.

Так что там с Win дой?

Мобильная OS была отличной базой и задумкой от Microsoft, но все пошло не так. Операционная система позиционировала себя как наиболее стабильная и производительная не зависимо от железа телефона. Можно купить бюджетный телефон или флагман и получить различия исключительно в железных возможностях, качестве материалов, камеры система же себя вела идентично круто и быстро. И это меня безумно радовало и давало надежду на успешное развитие платформы. Посудите сами: платформа не имеет взлома, а приложения если и будут идти в телефоны пользователей, то через официальный магазин с попутным отчислением денег разработчикам. Производительность отличная на разных девайсах - к сравнению я видел, как люди проверяли тупит или нет Android листая главный экран с иконками. Отличный дизайн системы, да и вообще задания тенденции всем остальным платформам по дизайну. Да-да именно Windows 8 задала направление к metro (тогда это называлось так) дизайну и оформлению приложений с использованием "плоского" дизайна, красивых шрифтов и логичного расположения элементов. Порог вхождения в разработку крайне мал и простое приложение можно сделать чуть ли не за 2 часа с минимальными знаниями C# и XAML. Возможности для разработки приложений API Windows дает достаточные для большинства приложений. НО... шло время, а развитие было, но как-то все сдержано и по чуть-чуть. Прям английский лорд, который сдерживается в эмоциях и выражениях. И я, как маленький ребенок перед новым годом, сидел и ждал каждую весну конференцию Build от Microsoft, чтоб увидеть, что же будет нового, чем же будет жить следующий год все сообщество .NET разработчиков. Но в этом и прошлом году произошли самое лучшее событие с Windows платформой и самое худшее, как по мне. Лучшее - объединение Windows Mobile\Phone и полноценной Windows (многие и сейчас не знают, как же на самом деле Phone\Mobile). Что это дает? Можно написать приложение, которое работает одинаково на телефоне и на компьютере. И это очень круто, потому как открываются возможности очень тесной интеграции своего пк с телефоном, к примеру: писал текст\сидел в браузере\слушал музыку и перешел на телефон, а у тебя уже есть все то же самое, как будто просто поменялся размер экрана и все. Я очень рад был этому и у меня уже начали чесаться руки написать что-то реально нужное мне и таким же, как я. Что-то, что будет иметь единый интерфейс и способ взаимодействия как на компьютере, так и на телефоне. Родилось множество идей, но больше всего загорелся идеей сделать читалку для книг, которая будет синхронизировать состояние прогресса чтения на телефоне и компьютере. Придя домой, вы можете продолжить читать с того же места, где закончили, пока читали с телефона в пути. И все как в фильме "Начало" - идея грызла и прожигала изнутри и хотелось, но... не моглось. И не потому, что я не знал, как все это написать и организовать, а потому, что платформа все так же является сдержанным лордом и не дает тебе поврываться и устроить реальный дебош. Если детальнее: Windows 10 имеет API для вывода pdf документов, но это вывод с использованием jpg изображения, а не рендера самой разметки документа. Мобильная реализация функционала оставляет желать лучшего, изображения, которые получаешь на выходе имеюту эффект замыливания и "нечеткости" вне зависимости от того, какие параметры размера изображения для рендера указываешь. К сожалению, в программировании на C++ я не силен и реализовать собственными силами хороший движок для отрисовки pdf документа я не имею возможности. Есть платные компоненты сторонних производителей, но и у них качество в основном оставляет желать лучшего, да и цена высока для меня (500 вечно зеленых и более). И выходит, что идея есть, польза была б многим, но реализовать у меня не входит. Что же плохого произошло? В этом году Build прошел без мобильной платформы Windows вообще. Доклады были конечно, но нового ничего нет. И официальные лица заявляют, что платформа будет продолжать развиваться, но в ней сейчас не так заинтересованы, поэтому ждите. И демки на пленарных докладах проводились на IPhone и Android. И как-то меня, как разработчика, такое положение дел опечалило... Вот почему:

Еще год ничего нового в Windows 10 Mobile не будет и это так, потому как Microsoft теперь задавило свое же производство мобильных телефонов и приказало "ждать новый Surface Phone", а он будет весной 2017-го.
Анонс 10ки для телефонов был еще летом 2015, в феврале 2016-го все должны были получить ее на свои устройства, и обещали, что "кидалова не будет, все получат". Но февраль пролетел без выпуска, все находились какие-то ошибки, которые нужно было исправить. Обновление все время переносилось.
Несмотря на обещания, некоторые флагманы не получили Windows 10. Меня возмутил тот момент что Lumia 930 и 1520 не получат обновление. Хотя это самые лучшие телефоны из всей серии. Я очень хотел получить 930-ю в свое время, видно не зря я тогда не решился на нее перейти.
Когда в марте выкатили обновление, то я с радостью обновился (без превью версий и недоработанных бета). По итогу получил девайс, который дико садился при использовании Wifi, экран произвольно моргал, когда происходили глюки с датчиком освещения, переодически телефон просто брал вырубался и запускался заново без причин для этого (просто находясь в режиме ожидания). Так же плеер сходил с ума, если использовать кнопки гарнитуры для управления проигрыванием.
Приложения все сырые и не реализованы с надлежащим качеством, как это было раньше. Элементарный ввод текста на стандартной клавиатуре заставлял задуматься мою Lumia 830 для выдачи слов из словаря и подстановки их в текст. Да что там говорить, вы и сейчас можете увидеть иконки от Windows XP\7 на последней Windows 10, и я не пойму, неужели это так сложно - собрать пак новых иконок и забыть про отголоски прошлого. Напрашивается простой вывод - "те, кто надо из Microsoft" сами не пользуются Windows.
Новые телефоны на Windows 10 имеют плохое качество самого телефона и операционной системы. Новых выходить не будет, потому как теперь только Surface Phone. Для подтверждения моих слов о посредственности телефонов можно посмотреть на кучу акций у российского n-store, где за покупку флагмана тебе давали в подарок lumia 650 годовую подписку на office 365, бонусы для игры в WoT да и сама цена была снижена на 10 000 рублей, при стартовой в 50-60... Куча отзывов о том, что телефон не удался.
Microsoft теперь дружит со всеми и это хорошо, но как следствие все приложения office пакета и skype реализованы и работают на много лучше на Android и iPhone, чем на Windows 10 Mobile. Обновление другие платформы так же получают первыми. К примеру: недавно было выпущена клавиатура для iPhone с интересным методом ввода: Источник . Windows 10 же не позволяет реализовать собственную клавиатуру ...
Обновления переносятся на более поздний срок и сейчас. И новые сообщения, о грядущей тесной интеграции становятся смешными, потому как еще куча ошибок и работы в том, что уже есть, куда же еще дальше плодить функционал?!
Официальные лица указывают, что развитие будет и далее. Да будет, но это развитие настольной версии и как следствие мобильной именно в этом порядке. Система объединилась и вскоре вообще приставки Mobile\Phone не будет. Но основной уклон все так же на персональных компьютерах.

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

Пробел, который образовался в декабре связан с тем, что приложение просто изьяли из магазина при этом не предьявив не притензий, не уведомив о нарушении прав или еще чем-то в этом роде. Просто в поиске не увидить приложение и все, даже если ты введешь полное имя. Хочу сказать большое спасибо Михаилу Черномордикову, только с его помощью я смог решить эту проблему. Официальная поддержка порекомендовала мне делиться ссылкой на приложение в своих соц сетях... и все. Это бред чистой воды, как по мне.

Если посмотреть статистику за год, и вспомнить еще раз, что это распространение приложения только через поиск пользователями, то можно увидеть, как аудитория растет, как и настроения Windows Phone разработчиков, а после 30-го марта скачкообразным образом аудитория падает, как и продажи телефонов, как и настроения разработчиков. Все чаще сейчас можно увидеть заголовки "Windows Mobile мертв, не стоит ждать ничего хорошего". И, к сожалению, я частично согласен с ними. У меня осталась надежда на то, что Surface Phone и Windows 10 покажут отличный тандем в 2017-м, но это будет через год. Сейчас же у меня один совет для Microsoft - используйте свои продукты сами, которые выпускаете. Относитесь к ним так, как будто бы вы и есть тот самый злостный троль и критик в одном лице, который будет писать вам злостные отзывы и рассказывать, как у вас все плохо. Вот именно тогда реализуется весь потенциал платформы, который был заложен изначально. Сейчас же я ушел на Android и пока почти доволен. "Почти" потому, что все тоже не идеально. Очень хотелось бы вернуться на платформу Windows в будущем и обрадоваться хорошему развитию и росту. Пока же буду жить хорошим сегодня, а не "прекрасным завтра".

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

ASP.NET MVC лучшие практики

d2funlife@gmail.com (Danil Pavlov) — Thu, 01 Oct 2015 08:55:55 GMT

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

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

Общие проблемы архитектуры

Данный вопрос включает в себя понимание многослойной архитектуры приложений и умение грамотно сформировать solution на уровне проектов и файлов. Пример хорошей организации:

Данный пример показывает организацию solution'а в рамках проектов. Проект ядра содержит все доменные модели, интерфейсы, ключевые сущности. Данный проект составляет основу приложения. Проект бизнес логики содержит всю необходимую бизнес логику, которая инкапсулирована в менеджерах и которая не должна иметь платформенных зависимостей. Проект доступа к данным - рекомендую использовать паттерн репозиторий, который помогает инкапсулировать (скрывать) доступ к хранилищу данных. К примеру, вы можете реализовать работу с данными, используя различные ORM, либо использовать хранимые процедуры. Проект контейнера инверсии управления содержит непосредственно сам контейнер, а так же настройки зависимостей абстракций и реализаций (интерфейсов и реализаций интерфейсов). Проект веб проекта содержит все наши контроллеры, css, js код, вообщем основную ASP.NET MVC инфраструктуру приложения. Саб веб проект содержит модели представлений, дополнительные хелперы, сущности, которые расширяют функционал веб проекта. Для чего же это нужно? – для обеспечения легкости основного веб проекта, ведь согласитесь, намного проще воспринимать десяток строк и пару папок, чем огромные неповоротливые файлы с ужасной структурой файлов. Но данная архитектура и организация solution'а подходит для небольших проектов. Для больших систем больше подходит следующая схема:

Большие системы имеют ядро - "точку входа" в ASP.NET MVC приложение, а остальная функциональность представлена в виде модулей, которые наращивают функционал. Очень важно анализировать требования проекта и подбирать хорошую архитектуру проекта, так как это очень большая часть хорошего проекта.

Толстые и/или кривые контроллеры

Толстые контроллеры – это бич многих проектов, так как за частую сжатые сроки или неопытность разработчика подталкивают его к написанию всей бизнес логики в контроллер и как итог выходят большие файлы, которые сложно читать и понимать. Контроллер должен выполнять роль посредника, который получил запрос, провалидировал, отдал на обработку и вернул финальное значение. Ни больше ни меньше. В этом и есть его принцип S.O.L.I.D. - единство ответственности. Идеальная ситуация, когда у нас есть менеджеры, которые отвечают за бизнес логику и мы валидируем данные, отдаем менеджерам на обработку, после чего возвращаем результат. Использование своего базового типа для контроллеров полезно когда нам необходимо инкапслуровать общее поведение для нескольких контроллеров, иными словами мы создаем базовый класс контроллера, который после наследуем и пропадает необходимость дублировать какой то общий код в наследуемых контроллерах.

Паттерн Post/Redirect/Get

Как гласит Wikipedia:

Post/Redirect/Get (PRG) — модель поведения веб-приложений, используемая разработчиками для защиты от повторной отправки данных веб-форм (от т. н. double submit problem). Модель PRG обеспечивает интуитивно понятное поведение веб-приложений при обновлении страниц в браузере и при использовании закладок в браузере.

Иными словами используйте отдельные типы запросов для отображения данных и для модификации их. Существуют такие ситуации, когда отправка данных формы POST запросом на сервер прошла успешно, вернулась та же страница редактирования и если пользователь просто обновит страницу ему выпадет предупреждение "Подтвердите повторную отправку формы". Данная проблема решается тем, что после модификации данных в качестве результата действия пользователь не должен получить представление, а должен быть перенаправлен на получение данных, как если бы он только заходил в редактирование сущности. Таким образом можно избежать ситуации, когда пользователь может дублировать отправку формы, даже если просто захочет обновить страницу. Данный подход хорош для классической схемы приложения ASP.NET MVC, при асинхронном взаимодействии с сервером схема не применяется.

Cache

Кэширование это сложный вопрос по своей сути. И полностью его раскрыть можно с помощью отдельных статей, но если вкратце, то использование кеширования оправдано на страницах где нет динамических данных или где нет необходимости поддерживать постоянную актуальность данных. К примеру, много проектов имеют статическую главную страницу, которая не меняется так часто. Используя кеширование, можно увеличить нагрузку, которую сможет держать сервер. Кеширование имеет много граней, к примеру - где хранятся данные: сервер/клиент и т.д. , где кешировать данные, ведь можно использовать возможности ASP.NET, IIS, HTTP. Простой пример использования кеширования в ASP.NET MVC - это создать Cache профиль и использовать его на необходимых действиях контроллера.

<caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="AllEvents" duration="15" varyByParam="*" location="Client"/>
        </outputCacheProfiles>
       </outputCacheSettings>
</caching>

[HttpGet, OutputCache(CacheProfile = "AllEvents")]
public ActionResult All()
{
    var promoterId = this.User.Identity.GetUserId<long>();
    var events = this.eventManager.GetAll(promoterId);
    return this.View(events);
}

Использование action filter

Ну хорошо, рассказал, что контроллеры могут быть жирными, что необходимо выносить логику в менеджеры , что можно не дублировать код контроллеров, используя супер типы и кешировать нужные ответы сервера, что же еще скрывается за "толстые" и/или кривые контроллеры? А есть еще такая вещь, как action filters, мощь и пользу которых мало кто из новичков ценит и понимает вообще. Очень распространенная практика, когда программист долго пишет, используя какой-то набор готовых action filtter : авторизации и тд., но своих фильтров не пишет и не задумывается об этом. Приведу пример, как можно, используя фильтры, реализовать задачу более круто, чем с подходом "в лоб". Такой задачей является создание транзакций данных. Для этого нам нужен менеджер транзакций который инкапсулирует работу с транзакциями, а так же создать наш action filter:

[System.AttributeUsage(System.AttributeTargets.All, AllowMultiple = false, Inherited = true)]
public class TransactionAttribute : ActionFilterAttribute
{
    private static ITransactionManager TransactionManager
    {
        get
        {
            return ServiceLocator.Current.GetInstance<ITransactionManager>();
        }
    }
    
    
	public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        TransactionManager.Begin();
    }
	
    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        try
        {
            if (TransactionManager.IsActive)
            {
                if (((filterContext.Exception != null) && !filterContext.ExceptionHandled))
                {
                    TransactionManager.Rollback();
                }
                else
                {
                    TransactionManager.Commit();
                }
            }
        }
        finally
        {
            TransactionManager.Dispose();
        }
    }
}

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

[Transaction]
public ActionResult DeleteAccount(string email)
{
    //Удаление элеммента
}

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

DTO (Data Transfer Objects)

Мир доменных моделей представляет собой набор всех сущностей, что представляют предметную область проекта, в свою же очередь view model – это мир представлений. Модели представлений должны полностью удовлетворять потребности представлений. В множествах источников рекомендуют использовать на каждое отдельное представление отдельную модель. С помощью view model мы можем передать представлению что-то сверх доменной модели. И все бы хорошо, но когда начинаешь использовать такой подход, то сталкиваешься с такими вещами как DTO (Data Transfer Objects) – конвертация из доменной модели в view model и обратно. Для многих это становится микро адом. Проблема всем известна и решение в виде mapper’ов все знают, я же хочу показать несколько интересных подходов для решения этого вопроса. В первом варианте решения используется ручной код, тут предельно просто, у нас всю ответственность за DTO берет на себя view model:

public class IssueDetailsViewModel
{
	public int IssueID { get; set; }
       public DateTime CreatedAt { get; set; }
       public string CreatorUserName { get; set; }
       public string Subject { get; set; }
       public IssueType IssueType { get; set; }
       public string AssignedToUserName { get; set; }
       public string Body { get; set; }

       public IssueDetailsViewModel(Domain.Issue model)
    {
        this.IssueID = model.IssueID;
        this.CreatedAt = model.CreatedAt;
        this.CreatorUserName = model.Creator.UserName;
        this.AssignedToUserName = model.AssignedTo.UserName;
        this.IssueType = model.IssueType;
        this.Subject = model.Subject;
        this.Body = model.Body;
    }

    public Domain.Issue GetDomain()
    {
        return new Domain.Issue
        {
               IssueID = this.IssueID,
               CreatedAt = this.CreatedAt,
               Subject = this.Subject,
               Body = this.Body,
               IssueType = this.IssueType
        };
    }
}

Второй вариант можно использовать с mapper’ами. Суть его в том, что мы используем реализацию двух интерфейсов для указания, от какой доменной модели «пошла» view model, и как реализовать сложный mapping сущности. Сами интерфейсы:

public interface IHaveCustomMappings
{
   void CreateMappings(IConfiguration configuration);
}

Реализации интерфейсов имеют следующий вид:

public class IssueDetailsViewModel : IMapFrom<Domain.Issue>
{
	public int IssueID { get; set; }
	public DateTime CreatedAt { get; set; }
	public string CreatorUserName { get; set; }
	public string Subject { get; set; }
	public IssueType IssueType { get; set; }
	public string AssignedToUserName { get; set; }
	public string Body { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; } 
}

public class AssignmentStatsViewModel : IHaveCustomMappings
{
	public string UserName { get; set; }
	public int Enhancements { get; set; }
	public int Bugs { get; set; }
	public int Support { get; set; }
	public int Other { get; set; }

	public void CreateMappings(IConfiguration configuration)
	{
		configuration.CreateMap<ApplicationUser, AssignmentStatsViewModel>()
			.ForMember(m => m.Enhancements, opt => 
				opt.MapFrom(u => u.Assignments.Count(i => i.IssueType == IssueType.Enhancement)))
			.ForMember(m => m.Bugs, opt =>
				opt.MapFrom(u => u.Assignments.Count(i => i.IssueType == IssueType.Bug)))
			.ForMember(m => m.Support, opt =>
				opt.MapFrom(u => u.Assignments.Count(i => i.IssueType == IssueType.Support)))
			.ForMember(m => m.Other, opt =>
				opt.MapFrom(u => u.Assignments.Count(i => i.IssueType == IssueType.Other)));
	}
}

Регистрацию мапингов сущностей можно произвести вручную, по-старинке, либо используя LINQ и рефлексию. Как реализовать автоматическую регистрацию:

public class AutoMapperConfig
{
	public void Register()
	{
		var types = Assembly.GetExecutingAssembly().GetExportedTypes();
           LoadStandardMappings(types);
           LoadCustomMappings(types);
	}

	private static void LoadCustomMappings(IEnumerable<Type> types)
	{
		var maps = (from t in types
					from i in t.GetInterfaces()
					where typeof(IHaveCustomMappings).IsAssignableFrom(t) &&
						  !t.IsAbstract &&
						  !t.IsInterface
					select (IHaveCustomMappings)Activator.CreateInstance(t)).ToArray();

		foreach (var map in maps)
		{
			map.CreateMappings(Mapper.Configuration);
		}
	}

	private static void LoadStandardMappings(IEnumerable<Type> types)
	{
		var maps = (from t in types
					from i in t.GetInterfaces()
					where i.IsGenericType && i.GetGenericTypeDefinition() == typeof(IMapFrom<>) &&
						  !t.IsAbstract &&
						  !t.IsInterface
					select new
					{
						Source = i.GetGenericArguments()[0], 
						Destination=t
					}).ToArray();

		foreach (var map in maps)
		{
			Mapper.CreateMap(map.Source, map.Destination);
		}
	}
}

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

Использование строковых значений

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

public ActionResult CompetencyFrameworkReport()
{
    return View("ReportContainer",
    new ReportViewModel
    {
        Params = "User.CompetencyFrameworkReport.Params",
        Result = "User.CompetencyFrameworkReport.Result"
    });
}

public ActionResult ViewProfileRole()
{
    return RedirectToAction("ReviewGroupNeeded", "Assessment");
}

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

public static class UrlHelper
{
    public static string Login(this System.Web.Mvc.UrlHelper helper)
    {
        return helper.Action("Login", "Account");
    }
}

HTML helper, который будет инкапсулировать наши маршруты. И Использовать его будем так:

//Было
<a href="@Url.Action("Login", "Account")">Login</a>

//Стало
<a href="@Url.Login()">Login</a>

Получение доступа к view model из скрипта

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

app.controller('ConsultantInformationController', function($scope, $filter, $http) {
    $scope.user = {
        id: 1,
        firstName: @Model.UserBaseViewModel.FirstName,
        lastName: @Model.UserBaseViewModel.LastName
    };

    //other code is here
});

Примеры приведены для angular, но они так же будут актуальными для других js framewrk'ов, как к примеру knockout, backbone. Как же решить данные проблемы? А все предельно просто - мы создадим HTML helper, который преобразует наш объект в json и отдаст на обработку скрипту:

public static class JavaScriptHelper
{
	public static IHtmlString Json(this HtmlHelper helper, object obj)
	{
		var settings = new JsonSerializerSettings
		{
			ContractResolver = new CamelCasePropertyNamesContractResolver(),
			Converters = new JsonConverter[]
			{
				new StringEnumConverter(), 
			},
			StringEscapeHandling = StringEscapeHandling.EscapeHtml
		};

		return MvcHtmlString.Create(JsonConvert.SerializeObject(obj, settings));
	}
}

И использовать можно вот так:

<div ng-controller='editIssueController' ng-init='init(@Html.Json(Model))'></div>

И если уйти от js framework'ов, то реализация подобного подхода предельно проста - у нас должна быть функция, которая принимает json версию модели и обрабатывает ее далее. Данная практика идет тесно с рекомендацией использовать bundling и minification. Ведь скрипты, которые находятся в представлениях никоим образом не сжимаются и страница становится не оптимальной. Bundling позволяет решить порос минимизации объема кода css и js а так же количества подключений для скачивания файлов.

Взаимодействие с пользователем

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

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

public class Alert
{
	public string AlertClass { get; set; }
	public string Message { get; set; }

	public Alert(string alertClass, string message)
	{
		AlertClass = alertClass;
		Message = message;
	}
}

Для хранения наших предупреждений мы будем использовать TempData. Для доступа к коллекции предупреждений реализуем следующее расширение:

public static class AlertExtensions
{
	const string Alerts = "_Alerts";

	public static List<Alert> GetAlerts(this TempDataDictionary tempData)
	{
		if (!tempData.ContainsKey(Alerts))
		{
			tempData[Alerts] = new List<Alert>();
		}

		return (List<Alert>) tempData[Alerts];
	}
}

Для создания расширения к результату действия мы создадим декоратор для ActionResult, который будет содержать результат действий, css класс для отображения и сообщение для пользователя.

public class AlertDecoratorResult : ActionResult
{
	public ActionResult InnerResult { get; set; }
	public string AlertClass { get; set; }
	public string Message { get; set; }

	public AlertDecoratorResult(ActionResult innerResult, string alertClass, string message)
	{
		InnerResult = innerResult;
		AlertClass = alertClass;
		Message = message;
	}

	public override void ExecuteResult(ControllerContext context)
	{
		var alerts = context.Controller.TempData.GetAlerts();
		alerts.Add(new Alert(AlertClass, Message));
		InnerResult.ExecuteResult(context);
	}
}

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

public static class AlertExtensions
{
	const string Alerts = "_Alerts";

	public static List<Alert> GetAlerts(this TempDataDictionary tempData)
	{
		if (!tempData.ContainsKey(Alerts))
		{
			tempData[Alerts] = new List<Alert>();
		}

		return (List<Alert>) tempData[Alerts];
	}

	public static ActionResult WithSuccess(this ActionResult result, string message)
	{
		return new AlertDecoratorResult(result, "alert-success", message);
	}

	public static ActionResult WithInfo(this ActionResult result, string message)
	{
		return new AlertDecoratorResult(result, "alert-info", message);
	}

	public static ActionResult WithWarning(this ActionResult result, string message)
	{
		return new AlertDecoratorResult(result, "alert-warning", message);
	}

	public static ActionResult WithError(this ActionResult result, string message)
	{
		return new AlertDecoratorResult(result, "alert-danger", message);
	}
}

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

return RedirectToAction<HomeController>(c => c.Index())
				       .WithSuccess("Issue created!");

return RedirectToAction<HomeController>(c => c.Index())
				       .WithError("Unable to find the issue.  Maybe it was deleted?");

return RedirectToAction<HomeController>(c => c.Index())
				       .WithInfo("Issue deleted!");

Результат отображен был на изображении выше.

Итог и финальный best practice

Приведенные примеры лишь малая часть из общей массы советов и практик решения различных проблем и задач. Главный best practice - это использовать мощь платформы на полную и знать все тонкости ее. Ведь тогда вы будете видеть все, как на ладони и дополнения, расширения каких то моментов вас не затруднит ни коем образом. Используйте голову и не бойтесь экспериментировать и пробовать новое. Если у вас есть предложения по каким то своим практикам или замечания к приведенным мной, с радостью обсужу с вами эти вопросы в комментариях статьи.

Чистый код, или "Встаньте! Мне нужно убраться".

d2funlife@gmail.com (Danil Pavlov) — Sun, 05 Jul 2015 18:50:18 GMT

Больница № 389, после длительных и безуспешных попыток найти уборщицу, преобразована в грязелечебницу.

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

Для начала хотелось бы ввести два понятия: «писать» и «педалить». Писать у нас будет означать так как надо делать, а педалить, в свою очередь, как не надо. И так, включаем пылесос, начнем-с. Начнем от печки, а точнее от дома. Классный дом — это когда все сделано как надо, а главное фундамент заложен отлично, что гарантирует долговечность. Проведя аналогию с программированием, мы строим каждый день свои дома, и вот как в идеале выглядит чертеж.

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

string script = @"<script type="text/javascript">
//
//как правило
//много
//очень много
//строк javascript
//
</script>";
this.Headers.Controls.Add(new Literalcontrol("\r\n"+script));

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

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

Документирование… вопрос вообще неоднозначный, все к нему относятся равнодушно, ведь писать комментарии, когда имя метода итак все объясняет, нелепо. Но если в методе реализована сложная логика, которая не является известным стандартным алгоритмом, то стоит описать ее, мало кто будет потом разбираться в вашем коде, помогите ему сразу, а то и вообще время пройдет и сами забудете, что писали, к примеру, заставили править и будет трата времени.

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

Булевые выражения – все мы что то проверяем сравниваем, но прежде всего, ни вкоем случае не педалим такое:

if(isLoggedIn==true)
{ 
   //какой-то код 
}

loggedIn и так содержит только true или false значения, и сравнивать их никчемую Не стоит также и педалить подобного рода чепуху:

bool goingToBar;

if(cashInWallet > 10)
{
   goingToBar = true;
}
else{
   goingToBar = false;
}

Не отрицайте отрицание, да почти схоже с тавтологией, но нагляднее :

if(!isNotLoggedIn)
{
   //какой-то код
}

Цель чистого кода - это сделать как можно компактнее код приложения, и так написать, чтоб человек смог его читать как роман, попивая чек иль чего покрепче (в нерабочее время есессно!) поэтому педалинг такого выражения не будет придавать элегантности моменту чтения или распития и чтения .

int pointsCount;
if(isSpeaker)
{
   pointsCount = 0;
}
else
{
   pointsCount = 50;
}

А правильный вариант выглядит вот так:

int pointsCount = isSpeaker ? 0:50;

Не надо сравнивать со string какие-либо значения.

if(employeeType == “manager”)
{
   //какой-то код
}

А правильный вариант:

if(employee.Type == EmployeeType.Manager)
{
   //какой-то код
}

Магические числа, вообще прекрасный момент, сравниваем переменную с 25, а что такое 25 ? ответ : 25. И это довольно частая ошибка, ее продолжают и продолжают педалить.

if(age >= 21)
{
   //какой-то код
}

А правильный вариант:

const int legalDrinkingAge = 21;
if(age >= legalDrinkingAge)
{
   //какой-то код
}

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

if(employee.Age > 55 && employee.YearsEmployed > 10 && employee.IsRetired == true)
{
   //какой-то код
}

А правильный вариант:

bool eligibleForPension = employee.Age > MinRetirementAge && employee.YearsEmployed > MinPensionEmploymentYears && employee.IsRetired;
/*переменная имеет осмысленное название, которое дает понять сразу, 
что проверяется право выхода на пенсию работника*/
if(eligibleForPension)
{
   //какой-то код
}

Будьте логичны, изучайте свои инструменты, которыми работаете. Степан не стал бы пахать поле лошадью, если у него есть комбайн, так не стоит и нам. Как пример, использование LINQ для фильтрации данных:

var matchingUsers = new List<User>();

foreach(var user in users)
{
    if(user.AccountBalance < minimumAccountBalance &&
       user.Status == Status.Active)
       {
           matchingUsers.Add(user);
       }
}

return matchingUsers;

А лаконичнее будет:

return users.Where(u => u.AccountBalance < minimumAccountBalance)
            .Where(u => u.Status == Status.Active);

Количество проверок не должно превышать вложенность в три уровня

if(some){
    if(anotherSome){
        if(anotherSecondSome){
            //какой то код
        }
    }
}

Методы

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

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

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

private bool ValidateUsername(string username)
{
    var isValid = false;
    const int MinUsernameLength = 6;
    if(username.Length >= MinUsernameLength)
    {
        const int MaxUsernameLength = 25;
        if(username.Length <= MaxUsernameLength)
        {
            var isAlphaNumeric = username.All(Char.IsLetterOrDigit);
            if(isAlphaNumeric)
            {
                if(!ContainsCurseWords(username))
                {
                    isValid = IsUniqueUsername(username);
                }
            }
        }
    }
    return isValid;
}

А вот как сделать более лаконично:

private bool ValidateUsername(string username)
{
    const int MinUsernameLength = 6;
    if (username.Length < MinUsernameLength) 
        return false;
    const int MaxUsernameLength = 25;
    if (username.Length > MaxUsernameLength) 
        return false;
    var isAlphaNumeric = username.All(Char.IsLetterOrDigit);
    if (isAlphaNumeric) 
        return false;
    if (!ContainsCurseWords(username)) 
        return false;
    return IsUniqueUsername(username);
}

Если может выпасть исколючение или ошибка, то пускай это произойдет как можно раньше:

public void RegisterUser(string username, string password)
{
    if (!string.IsNullOrWhiteSpace(username))
    {
        if (!string.IsNullOrWhiteSpace(password))
        {
            //регистрация пользователя
        }
        else
        {
            throw new ArgumentException("Username is required.");
        }
    }
    else
    {
        throw new ArgumentException("Password is required");
    }
}

И по традиции:

public void RegisterUser(string username, string password)
{
    if (!string.IsNullOrWhiteSpace(username)) throw new ArgumentException("Username is required.");
    if (!string.IsNullOrWhiteSpace(password)) throw new ArgumentException("Password is required");

    //регистрация пользователя
}

И на последок... Зная все и используя все эти знания, можно получить отличный код, но как же быть, если только в начале пути а дать подзатыльник некому? Ответ есть: Visual Studio любезно предоставила такое средство как Code Metrics. Начать его использовать очень просто : всего лишь правой кнопокй мыши по "проекты" и "выбрать" Calculate Code Metrics. Более детально с результатами и значениями всего этого можно ознакомится вот здесь: Code Metrics

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