Краткое содержание

• Использование событийной (event-driven) архитектуры для уменьшения связанности — весьма популярная идея при проектировании микросервисов.
• Событийная бизнес-логика хорошо подходит для децентрализованных данных и решения проблем сквозной функциональности. Однако, не стоит выстраивать сложные цепочки по передаче событий из сервиса в сервис. Координация сервисов с помощью команд, а не событий — позволяет еще сильнее их развязать.
• ESB (Enterprise Service Bus, в контексте статьи — "умная шина" — прим.перев.) плохо сочетается с микросервисной архитектурой. Предпочтительнее использовать простые каналы передачи данных и умных клиентов (smart endpoints, dumb pipes). Но, не отказывайтесь от сервиса-координатора других сервисов только лишь из опасений получить один богоподобный сервис: бизнес-логике все равно нужен дом.
• Workflow engines прошлого были, в основном, вендоро-зависимы. Так называемые "zero-code" решения — на практике оборачивались сущим кошмаром для разработчиков. В настоящее время есть легковесные и простые средства управления workflow, многие из них — с открытым исходным кодом.
• Не тратьте время на написание своих собственных конечных автоматов. Напротив, используйте готовые решения во избежание сложностей.

Logo designed by Pablo Iglesias.

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

Содержание:

• Claims
• Подготовительные работы
• Атрибут Authorize и политики доступа
• Настройки политик доступа
• Resource-based авторизация
• Авторизация в Razor-разметке
• Permission-based авторизация. Свой фильтр авторизации

Около месяца назад я обнаружил себя разговаривающим по видеосвязи с Joel Spolsky (автор известного блога «Joel on Software», со-основатель Stack Overflow — прим. перев.). Даже сейчас кажется абсурдным писать подобное. Долгое время, на протяжении всей своей карьеры, я регулярно читал Joel Spolsky, и во многом сходился с ним во взглядах на разработку. И вдруг общаюсь лицом к лицу.

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

Многие программисты делают записи, описывают трудности, красивые и не очень решения, с которыми приходится сталкиваться по долгу службы. Это может быть собственный технический блог, рабочая вики, или даже обычный блокнот — суть одна. Постепенно, из маленьких Evernote-заметок может вырасти целая статья на Хабр. Но время идет, перемена места работы сулит изменения в стеке разработки, да и технологии не стоят на месте (кстати, EF Core уже пару месяцев как в версии 1.1). С другой стороны, Entity Framework 6 был и остается "рабочей лошадкой" для доступа к данным в корпоративных приложениях на стеке .net, не в последнюю очередь благодаря своей стабильности, низкому порогу входа и широкой известности. Поэтому, я надеюсь, статья всё еще окажется кому-то полезной.

Содержание:

1. Database First без EDMX
2. Работа с отсоединенными графами
3. Модификация SQL. Добавление табличных указаний
4. Кэширование данных за пределами времени жизни DbContext
5. Retry при ошибках от SQL Server
6. Подменяем DbContext, изолируемся от реальной БД
7. Быстрая вставка

Изображение с hangfire.io

Hangfire — многопоточный и масштабируемый планировщик задач, построенный по клиент-серверной архитектуре на стеке технологий .NET (в первую очередь Task Parallel Library и Reflection), с промежуточным хранением задач в БД. Полностью функционален в бесплатной (LGPL v3) версии с открытым исходным кодом. В статье рассказывается, как пользоваться Hangfire.

План статьи:

• Принципы работы
• Внутренности и возможности Hangfire-сервера
• Повторяемые и отложенные задачи
• Микрообзор Quartz.NET
• Про (не)нагрузочное тестирование
• Выводы. Опрос.

Цель: написать, протестировать и развернуть простейший плагин для R#, содержащий пользовательские Quick-Fix и Context Action.

План статьи:

1. Настройка среды разработки
2. Пример №1: простейшее расширение-заглушка
3. Установка плагина
4. Отладка, полезные советы
5. Пример №2: модификация кода с помощью R# API
6. Функциональное тестирование плагинов средствами R# API

В ролях:

Visual Studio 2015
ReSharper Ultimate 10

Заинтересовавшихся приглашаю под кат.

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

Вот мои главные цели:

• не нанимать плохих работников;
• нанимать хороших работников;
• оставить кандидата с положительным впечатлением о компании.

До сих пор, мое продвижение по карьерной лестнице было быстрым. В 2008 году, я начал работать на полную ставку программистом в должности Junior Developer. Там был славный босс и классные коллеги, и я получил навыки использования Java и .NET, вместе с первым полезным опытом. Поработав так пару лет, я чувствовал, что настало время двигаться дальше…

OrmLite — это дружелюбная micro-ORM с открытым исходным кодом и коммерческой лицензией (бесплатна для небольших проектов с ограничением в 10 таблиц). Входит в состав известного фреймворка ServiceStack (и обладает высокой производительностью — взгляните на benchmark от разработчиков Dapper). В данной статье мы рассмотрим основы работы с OrmLite в связке с SQL Server. Если сравнивать OrmLite и Entity Framework, то сразу бросается в глаза отсутствие контекста и отслеживания изменений (change tracking). И это далеко не единственные отличия.

План статьи:

• Подготовка к работе. Code-first и database-first подходы
• Запросы к БД
• JOIN и navigation properties
• Lazy и Async
• Транзакции
• Сравнение производительности OrmLite и Entity Framework
• Заключение

Заинтересовавшихся приглашаю под кат.

При добавлении/изменении большого количества записей (10³ и выше), производительность Entity Framework оставляет желать лучшего. Причиной этому являются как архитектурные особенности самого фреймворка, так и неоптимальный генерируемый SQL. Забегая вперед — сохранение данных в обход контекста сокращает время выполнения на порядки.

Содержание статьи:
1. Insert/Update стандартными средствами Entity Framework
2. Поиск решения проблемы
3. Интеграция Entity Framework и SqlBulkCopy
4. Продвинутая вставка с использованием MERGE
5. Сравнение производительности
6. Выводы