Протокол HTTP может использоваться не только для веб-страниц. Это еще и мощная платформа для создания API, предоставляющих сервисы и данные. Протокол HTTP прост, гибок и широко распространен. Практически любая существующая платформа имеет библиотеку HTTP, поэтому службы HTTP доступны в большом числе клиентов, включая браузеры, мобильные устройства и традиционные офисные приложения.
В новой статье из серии ASP.NET Core будет описано создание простого веб-API для работы со списком дел.
В этой статье мы поговорим о шаблонах проектирования «Единица работы» и «Репозиторий» в контексте тестового веб-приложения на ASP.NET Core (с использованием встроенного DI), которое мы с вами вместе и разработаем. В результате мы получим две реализации взаимодействия с хранилищем: настоящую, на основе базы данных SQLite, и фейковую, для быстрого тестирования, на основе перечисления в памяти. Переключение между этими двумя реализациями будет выполняться изменением одной строчки кода.
Несколько лет назад я реализовал ряд проектов, для управления которыми использовалась система управления основанная на ASP.NET Dynamic Data. В свое время эта система сэкономила достаточно много времени и ресурсов. Но как известно, в ИТ все развивается очень стремительно. Не так давно вышла в релиз платформа .NET Core, основным нововведением которой была поддержка кроссплатформенности. Это в свою очередь позволило мне мигрировать ряд небольших проектов, а также проектов, которые я поддерживаю на некоммерческой основе на бюджетные сервера от Digital Ocean, которые, как известно, поддерживают только ОС семейства Linux. Когда дело дошло до системы управления передо мной стоял выбор — с минимальным изменением кода портировать проект под Mono, или переписать с нуля использую новые возможности .NET Core. Взвесив все за и против, я выбрал второй вариант. Что из этого вышло и что я собираюсь получить вы можете узнать под катом.
Продолжаем делиться материалом по работе с ASP.NET Core. В прошлой статье мы рассказывали о развертывании приложения ASP.NET Core на Nano Server со службами IIS. Сегодня поговорим о создании внешнего интерфейса веб-службы для вашего приложения.
По умолчанию службы Azure Service Fabric не предоставляют общедоступный интерфейс для веб-служб. Для того чтобы сделать приложение функциональным для HTTP-клиентов, необходимо создать веб-проект, который будет работать в качестве точки входа и обмениваться данными с отдельными службами.
В июне 2016 вышел релиз ASP.Net Core 1.0 и теперь, если вас не пугает возраст нового фреймворка, можно аккуратно запустить микросервис в продакшн (все ведь используют микросервисную архитектуру, не так ли?). Для того, чтобы ограничить доступ к вашему микросервису для третьих лиц, необходимо сделать аутентификацию, используя довольно распространенный способ — токены. В статье под катом мы расскажем подробнее о том, как это сделать с помощью JSON Web Token (JWT), а также о плюсах и минусах этого подхода.
Представляем первую из пяти статей, посвященных работе с ASP.NET Core: руководство по развертыванию приложения ASP.NET Core на Nano Server со службами IIS.
Я решил написать на эту тему, т. к. постоянно использую модели видов (view models) в веб-приложениях на ASP.NET MVC, и часто приходится объяснять суть такого подхода коллегам, а подходящего материала, чтобы ссылаться на него, мы так и не нашли. Эта статья ориентирована прежде всего на новичков.
Представим, что нам необходимо отобразить календарь некоторых мероприятий на текущий месяц. Это достаточно сложная конструкция. Календарь должен содержать заголовок с названием текущего месяца и годом, строку с названиями дней и, собственно, сами дни (6 рядов по 7 дней), каждый из которых имеет дату и, опционально, некоторый набор мероприятий, названия которых необходимо отобразить, предварительно загрузив их из базы данных. Также предположим, что выходные и праздничные дни должны быть отмечены особым образом. Т. е. в итоге должно получиться нечто такое:
Раньше наш рабочий процесс прерывался из-за ряда неразрешенных вопросов:
Наш опыт решения данных вопросов с помощью системы рейтинга Elo будет рассмотрен в статье. А также ссылка на репозиторий и на сайт будут разбросаны по статье.
Читать полностью »
Каждый раз с выходом нового фреймворка, хочется попробовать его в деле и написать на нем какое-то приложение. В прошлый раз отлично зашел формат квеста. По этому предлагаю посмотреть что поменялось за почти полтора года и написать еще один квест— и фреймворки посмотрим, и поиграть можно.
Результат:
— сорсы на гитхабе для тех, кому интересно посмотреть на исходники
— линк на квест для тех, кому интересно что получилось или потратить свое время на еще один логический квест.
Под катом описан полный процесс от создания проекта до его развертывания.
Читать полностью »
Весной прошлого года, когда ASP.NET 5 был еще в стадии Beta 3, я начал получать от пользователей письма с просьбами сделать WebMarkupMin совместимым с DNX 4.5.1 и DNX Core 5.0. Основной проблемой было то, что новый .NET не поддерживал настройку с помощью конфигурационных файлов App.config и Web.config. Переписывание WebMarkupMin.Core, WebMarkupMin.MsAjax и WebMarkupMin.Yui не должно было представлять особой сложности, потому что нужно было просто удалить весь код, использующий библиотеку System.Configuration. Серьезные проблемы должны были возникнуть при переписывании ASP.NET-расширений, потому что для них нужно было разработать совершенно новую модель конфигурации, а это, в свою очередь, требовало очень серьезных изменений в архитектуре. Эти изменения затрагивали не только код, но и структуру решения и NuGet-пакеты, поэтому я решил начать с чистого листа и сделал репозиторий на GitHub. На тот момент, до релиза стабильной версии нового ASP.NET оставалось как минимум полгода, поэтому нужно было одновременно поддерживать 2 ветви WebMarkupMin: стабильную 1.X на CodePlex и предварительную 2.X на GitHub.
Как известно всем, выход стабильных версий .NET и ASP.NET Core 1.0 задержался еще на несколько месяцев и состоялся только в конце июня этого года. Вслед за релизом этих фреймворков, состоялся и релиз WebMarkupMin 2.0. В этой статье я расскажу вам о том, как обновить существующие приложения под WebMarkupMin 2.X, а также как добавить его в веб-приложения, написанные на ASP.NET Core.
Для того чтобы установить пакеты WebMarkupMin 2.X вам необходимо обновить NuGet Package Manager до версии 2.8.6 или выше.
Основным критическим изменением версии 2.X стал отказ от использования файлов Web.config и App.config для настройки WebMarkupMin. Теперь при настройке вместо декларативного подхода (использование конфигурационных файлов) используется императивный подход (использование программного кода).
Читать полностью »
