воскресенье, 20 марта 2016 г.

Radar: Создание проекта ASP.NET Core и публикация в MS Azure

Введение

Создадим новый проект ASP.NET Core и развернем его в облаке MS Azure

Нам понадобится VS 2015 Community и подписка MS Azure.
Если у вас нет подписки MS Azure, то ее легко получить - Free Azure.

Для регистрации понадобится банковская карточка. С нее спишется незначительная сумма в несколько центов, потом она, кажется, возбращается на счет.

После регистрации вы получаете $200 на счет на месяц. Вы можете потратить из на любые сервисы в облаке MS Azure (виртуальные машины, сервера баз данных, очереди, кеши, Push-нотификации для мобильных платформ и многое другое). Выбор сервисов уже очень широкий и он постоянно обновляется.

Создание ASP.NET Core проекта

Создаем новый ASP.NET Core проект:


На следующем шаге выбираем ASP.NET 5 Template - Web Application, cтавим галочку Host in the cloud:


На следующем шаге настраиваем Azure сервисы:


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


Продолжаем настройку и переходим на вкладку Services:


Здесь мы видим 2 таблички. В нижней указаны сервисы, которые вы уже выбрали и настроили. 

Мы уже настроили сервис для Web приложения. 
Если нужна ещеи база данных - нажимаем на плюсик напротив SQL Database из верхней таблички и настраиваем сервис:


Выбираем существующий SQL Server или создаем новый:


Мы закончили настройку сервисов Azure:


Нажимаем Create.

PS. По умолчанию создается база тарифного плана Standart S0 ($15 в месяц). Я сразу сменил в Azure portal на более дешевый Basic ($5 в месяц):

Публикация проекта в MS Azure

В контекстном меню проекта выбираем Publish:


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



Можно указать версию DNX:


На любой вкладке можно нажать кнопку Publish и проект будет опубликован (обновлен) в облаке MS Azure.

Заключение

Ура! Приложение опубликовано в облаке! 


4 года назад я немного завидовал рубистам с их прекрасным облачным хостингом Heroku, который позволял из гит репозитория в пару команд разворачивать приложение в облаке. Дотнетчикам в то время о таком можно было лишь мечтать. И знаете, ребята из Microsoft очень хорошо поработали в этом направлении и утерли нос всем. Несколько минут, минимум настроек и все готово. Публикация в 2 клика и это все не выходя из вашей любимой IDE! Кое-кто может только завидовать ;)

четверг, 24 сентября 2015 г.

Entity Framework: Stub Entities или как избежать лишних запросов к базе данных

Предыстория

Наверное, многие начинали свое знакомство с Entity Framework с туториалов на сайте entity framework tutorial или Getting Started with Entity Framework 6 Code First using MVC 5 или черпали знания из других источников.

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

Не так давно узнал про интересную возможность Entity Framework, которая позволит избежать лишних запросов к базе данных.

Распространенный подход удаления

Удаление сущностей часто производится по уже известному первичному ключу. Для этого используют следующий код:


При выполнении этого кода будет выполнено 2 SQL запроса к базе:


Но я не хочу доставать из базы сущность! Я хочу сразу удалить ее!

Используем Stub Entity

Модифицируем наш код удаления:


Смотрим лог:


Да! Entity Framework сразу отправляет запрос на удаление.
Если запись с узазанным Id существует, она будет удалена. Иначе будет выброшено исключение System.Data.Entity.Infrastructure.DbUpdateConcurrencyException:



Такой подход работает только для поиска по первичному ключу. Если мы попробуем что-то такое:


SQL лог в этом случае:


Как мы видим, Entity Framework генерирует запрос на удаление по первичному ключу, несмотря на то, какие поля заполнены в стабе.

Заключение

Я рассмотрел как можно оптимизировать удаление сущностей используя stub entities. Также можно оптимизировать обновление сущностей и создание сущностей, для которых нужно задать связи с другими сущностями.

Поиграться с кодом можно на GitHub.

Ссылки



воскресенье, 2 августа 2015 г.

ASP.NET Core: Dependency Injection

ASP.NET 5 имеет механизм внедрение зависимостей. Этот пост - краткий обзор внедрения зависимостей в ASP.NET 5 с некоторыми примерами.

Регистрация сервисов

Сервисы регистрируются, когда приложение запускается. Это происходит в Startup классе. Этот класс содержит ConfigureServices() метод и в конце этого метода я обычно объявляю маппинг сервисов.


Доступные скоупы:
  • Singleton - всегда возвращать один и тот же экземпляр объекта (сервиса)
  • Transient - каждый раз возвращать новый экземпляр
  • Skoped - возвращать один и тот же экземляр в текущем скоупе (это как singleton в текущем скоупе). Скоупом может быть, например, http-запрос (в течение обработки запроса все потребители будут работать с одним и тем же экземпляром объекта, например, подключением к базе данных DbConnection)
  • Instance - кажый раз возвращается конкретный экземпляр (смотрите выше LocalizationService)
Сервисы, зарегистрированные во время запуска приложения доступны всех классах через внедрение зависимостей.

Также доступны системные переменные и классы. Например, можно внедрить и использовать IApplicationEnvironment.

Давайте посмотрим, как внедрение зависимостей работает с контроллерами и вьюхами. Да-да, с вьюхами тоже! :)

Ранее приходилось создавать фабрику контроллеров для испльзуемого DI контейнера  (Ninject, Castle Windsor, Autofac). Сейчас этого делать не нужно. Но вы по прежнему можете использовать свой любимый DI контейнер и заменить им стандартный. Но не все DI контейнеры могут работат с .NET Core! Например, Autofac может работать только с полной версией .NET.

Внедрение зависимостей в контроллер

Вот пример внедрения пользовательских сервисов и IApplicationEnvironment в контроллер.


Этот код использует внедрение конструктора (constructor injection) для IProductBuilder и IApplicationEnvironment. Это наиболее распространенная практика, она поддерживается всеми,  известными мне, DI контейнерами.

Для внедрения IClientBuilder используется внедрение свойства (property injection). Для этого используется атрибут FromServices. Такая же возможность есть в Ninject, но ее нет в Castle Windsor.

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

Внедрение зависимостей в вьюхи

Теперь можно внедрять сервисы в вьюхи. Для этого используется специальный синтаксис @inject.


@ingect указывает движку представлений (Razor), что мы хотим получить экземпляр LocalizationService.

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

Заключение

Внедрение зависимостей в ASP.NET 5 очень прозрачное и легко настраивается. Вначале регистрируем маппинг в Startup классе и потом испльзуем внедрение конструктора для получения экземпляров наших классов. В MVC мы можем использовать внедрение зависимостей для контроллеров, вьюх и вью-конпонент (view components, появились в MVC 6, но это уже тема отдельной статьи)

понедельник, 15 июня 2015 г.

Добавление дополнительного билд-агента в TeamCity

Сегодня добавлял дополнительные агенты на TeamCity, набил немного шишек и хочу поделиться опытом :)

TeamCity по умолчанию устанавливает сервер TeamCity и один билд-агент.  Агент может выполнять один билд одновременно. Количество агентов в основном ограничивает количество параллельных выполнений билдов. Агент может выполнять любой билд (с совместимой конфигурацией).

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

Заходим в AdministrationInstall Build Agents


И скачиваем по ссылке установщик агентов


Запускаем установщик, выбираем компоненты 


Выбираем директорию, куда установить агент


Дальше нужно быть очень внимательным! 
Изменяем настройки агента


 Сохраняем. Появится следующее сообщение


Не нажимаем OK! 
Открываем в текстовом редакторе конфиг запуска сервиса агента C:\TeamCityBuildAgent004\launcher\conf\wrapper.conf
В конце файла создержатся настройки сервиса, изменяем их.


Сохраняем конфиг. Возвращаемся к установщику. Закрываем сообщение


Запускаем сервис агента


Все, через пару минут в TeamCity появится дополнительный агент.

Для дополнительной информации можно прочитать статью из официальной документации Setting up and Running Additional Build Agents.

среда, 3 июня 2015 г.

ASP.NET Core: Введение

Не за горами релиз  Visual Studio 2015 и ASP.NET 5. Давайте разбираться, что же это такое и как с этим жить. Вводная статья будет скучноватая, с кучей теории, но дальше постараюсь писать повеселее :)

Создадим новый проект веб-приложения File - New - Project - ASP.NET Web Application. Выберем шаблон Empty.

Структура решения(solution)


global.json

global.json файл используется для настройки всего решения. Он содержит 2 секции:
  • projects - указывает, какие папки содержат исходный код (по умолчанию папки src и test);
  • sdk - указывает версию DNX (.Net Execution Environment), которую Visual Studion будет использовать для открытия решения. Она указывается здесь, а не в project.json, чтобы избежать ситуации, в которых различные проекты в рамках решения в используют различные версии SDK.

Фреймворки

ASP.NET 5 можно собирать для нескольких фреймворков, что дает возможность разворачивать приложение в различных окружениях. По умолчанию приложения будет собираться для полной версии .NET, но они также могут собираться для .NET Core. Большинство унаследованных приложений будет собираться для полной версии ASP.NET 5, по крайней мере первоначально, поскольку они, вероятно, имеют зависимости, которые включают библиотеки из набора .NET Framework Class Library, которые не доступны в .NET Core сегодня. .NET Core облегченная версия платформы .NET, которая оптимизирована для веб-приложений и поддерживает Linux и Mac. .NET Core могжет быть развернут с приложением, что позволяет различным приложениям на одном сервере работать на различных версиях .NET Core. Он модульный, что позволяет дополнительные функции добавлять только тогда, когда это требуется, как отдельные пакеты NuGet.
Вы можете увидеть, какой фреймворк в настоящее время является целевым в свойствах проекта, щелкнув правой кнопкой мыши на веб-проекте в окне Solution Explorer и выбрав Properties:


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

Структура проекта

Структура проекта ASP.NET 5 добавляет новые концепции и заменяет некоторые устаревшие элементы. 

Новая структура включает в себя специальную папку wwwroot, и раздел References, который присутствовал в предыдущих версиях ASP.NET (но был обновлен в этой версии).

В корне проекта есть несколько новых файлов, таких как project.json и Startup.cs. Вы можете заметить, что проект не содержит файлы global.asax, packages.config и web.config. В предыдущих версиях ASP.NET, большинство конфигураций приложения хранилось в этих файлах и в файле проекта.

project.json

Файл project.json является новым для ASP.NET 5. Он используется, чтобы определить server side зависимости проекта (описанные ниже), а также другую информацию для конкретного проекта. Разделы, включенные в project.json по умолчанию с шаблоном веб-проекта:



Раздел webroot указывает папку, которая будет корнем веб-сайта.

Раздел version указывает версию проекта. Вы можете добавить произвольные разделы, например titledescription, authors. 

ASP.NET 5 имеет хорошую поддержку командной строки и раздел commands позволяет настроить, что некоторые команды командной строки делать (например, запустить веб-сайт).



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



Раздел exclude используется для указания файлов и папок, которые должны быть исключены из сборки

Управление server-side зависимостями

Папка References описывает server-side зависимости для проекта. Она должна быть знакома разработчикам ASP.NET, но она была изменена, чтобы различать зависимости для различных фреймворков, таких как полный DNX 4.5.1 и DNX Core 5.0. Для каждого времворка вы найдете отдельные ссылки с пиктограммами, указывающими ли ссылка на сборку, пакет NuGet или проекта.


Я упоминал выше, что .NET Core ставится с приложением. Обратите внимание, что все зависимости для DNX Core являются Nuget пакетами (либо могут быть зависимости от).

Запуск приложения

Когда запускается приложение ASP.NET, среда выполнения ASP.NET вызывает метод ConfigureServices, а за ним - Configure в классе Startup.
Метод ConfigureServices используется, чтобы указать, какие сервисы доступны в приложении, т.е для настройки DI контейнера. Да, в ASP.NET теперь из коробки есть DI контейнер :)

Заключение

Я постарался осветить основные нововведения, которые вы увидите в новом проекте ASP.NET. Но это далеко не все. На очереди конфигурация, управление client-side зависимостями (npm, bower, grunt, gulp), MVC и Web API и многое другое. Продолжение следует.