На сегодняшний день .NET программист может применять свои навыки в различных сферах разработки программных продуктов: создание веб-приложений и веб-сервисов создание настольных приложений; создание облачных сервисов; создание игр; создание мобильных приложений. Когда говорят о .NET разработчиках, имеют в виду программистов, которые пишут на языке С#. Этот язык программирования, как и вся платформа .NET, был создан, развивается и поддерживается компанией Microsoft, которая стабильно уже несколько десятилетий входит в TOP-10 компаний - мировых лидеров рынка информационных технологий. Все продукты компании Microsoft созданы на платформе .NET. Какие же технологии необходимо изучить, чтобы стать .NET программистом? Поскольку львиная доля .NET-вакансий приходится именно на веб-сегмент, данная статья будет охватывать как фундамент, которым обязаны владеть все разработчики этой платформы, так и основные технологии серверной стороны веб-решений.     Язык программирования C# (“си шарп”) Любой .NET разработчик не может называться и быть таковым, если он не умеет хорошо программировать на языке C#. Это универсальный объектно-ориентированный язык, который является мощным инструментом создания программного обеспечения с широкой областью применения. При столь высокой функциональности он является достаточно несложным в изучении и отлично подойдет тем, кто собирается сделать первый шаг навстречу программированию. Благодаря широкому спектру применения, С# является очень востребованным языком. Различные ресурсы по поиску работы предлагают большое количество вакансий, причем, как на крупные проекты с четко определенным консервативным стеком технологий, так и в компании, которые создают новый программный продукт с применением самых современных инструментов. Компания Microsoft активно развивает свое детище - .NET направление, потому C# всегда актуален, идет расширение функционала, добавляются новые возможности. Тенденция последних лет - кроссплатформенность, реализуемая в .NET Core. Огромное количество учебных материалов, качественная официальная документация, видео курсы и образовательные вебинары - все это создает максимально комфортные условия для грамотного поэтапного изучения данного языка.     ООП Объектно-ориентированное программирование - это методология разработки программного обеспечения, в основе которой лежат четыре главных принципа: абстракция, инкапсуляция, наследование и полиморфизм. Поскольку C# является объектно-ориентированным языком, необходимость изучения и полного понимания ООП парадигм обязательно. Однако, есть и приятная новость: все принципы быстро и легко усваиваются во время изучения C#.      Алгоритмы и структуры данных Понимание алгоритмов и структур данных  - обязательные знания для любого программиста. Изучив структуры данных, вы сможете управлять сложностью своих программ, делая их более доступными для понимания, а также разрабатывать высокопроизводительные программы, которые будут эффективно работать с памятью. Знание алгоритмов позволит вам создавать сложные конструкции для эффективного решения широкого спектра задач.   Шаблоны проектирования Паттерны (они же шаблоны) представляют собой архитектурные конструкции, которые описывают типичные способы решения распространенных задач, возникающих в ходе проектирования программного обеспечения. Всего существует более двух десятков шаблонов, однако знать их все - это обязанность архитектора, а не .NET. разработчика.  Обычно в одном проекте используется небольшое количество паттернов, поэтому вам достаточно знать самые популярные из них.   SQL Structured Query Language - декларативный язык структурированных запросов, который создан для взаимодействия с базами данных. Особенность SQL состоит в том, что он лишь описывает необходимые компоненты и желаемые результаты, не указывая, как именно эти результаты должны быть получены. Каждый программный продукт подразумевает работу с данными, будь то обыкновенная процедура приема данных от сервера (например, скачивание файлов) или внесение в БД информации о новом зарегистрированном пользователе - умение работать с данными одинаково важно во всех сферах разработки, разве что за исключением FrontEnd.   ASP.NET Active Server Pages для .NET - платформа, использующая среду выполнения .NET Framework и предоставляющая необходимые службы для создания серверных веб-приложений и веб-сервисов. Является развитием более ранней технологии Microsoft ASP. ASP.NET базируется на среде выполнения Common Language Runtime (CLR), которая является основой всех приложений Microsoft .NET. Также данная платформа имеет преимущество в скорости по сравнению со скриптовыми технологиями. ASP.NET MVC является расширением ASP.NET и представляет собой платформу для создания веб-сервисов при помощи паттерна MVC. Данный шаблон предусматривает разделение приложения на три компонента: Модель, Представление, Контроллер, благодаря чему реализуется концепция разделения и закрепления ответственности за каждым компонентом, что упрощает разработку проектов.   ASP.NET Core Фреймворк от компании Microsoft, который использует среду выполнения .NET Core, предназначен для разработки качественных современных веб-приложений и является продолжением развития платформы ASP.NET. Однако, это не просто обновленная технология. Выход ASP.NET Core фактически обозначил качественное изменение всей платформы. Последняя версия 3.0 была выпущена не так давно - в сентябре 2019 года. Главные особенности ASP.NET Core: наличие открытого исходного кода на GitHub; кроссплатформенность; модульность; расширяемость; возможность применения облачных технологий. Более подробную информацию обо всех нововведениях можно найти на официальном сайте Microsoft. Таким образом, платформа .NET Core существенно расширила области применения технологии ASP.NET и предоставила разработчикам большое количество возможностей по созданию программного продукта.   Entity Framework 6 Entity Framework -  специальная объектно-ориентированная технология на базе фреймворка .NET, которая позволяет разработчикам получать доступ к данным, используя концептуальную объектную модель, а не непосредственно реляционную базу данных. Благодаря такому подходу уменьшается количество кода, необходимое для получения доступа к базе, растет производительность и уменьшается время на поддержку объектов в приложениях, которые работают с данными. В двух словах, эта технология позволяет программисту абстрагироваться от самой базы данных и работать с данными независимо от типа хранилища.   LINQ Language Integrated Query (язык интегрированных запросов) - это простая и удобная .NET технология доступа к данным. Особенность данного языка запросов: возможность применения ко всем источникам данных (XML-документы, XML-потоки, наборы данных ADO.NET, базы данных SQL, массивы и коллекции .NET и т. д.) одного и того же самого подхода выборки данных.   Git Наиболее популярная система контроля версий, которая позволяет вести историю разработки проекта с возможностью доступа к каждой сохраненной версии. Данные системы позволяют команде программистов работать над одним проектом одновременно, сохраняя внесенные изменения, а также отслеживать выполнение задач каждым членом группы. Не во всех вакансиях можно встретить среди требований владение системой контроля версий, однако, знание Git или ее аналогов даст вам дополнительное преимущество перед остальными кандидатами.   Английский язык Традиционное требование для каждого разработчика в IT. Знание языка на уровне чтения технической документации и комментирования кода вполне достаточно.   Подведем итоги В статье были перечислены основные технологии, которыми должен обладать каждый .NET-программист. Поскольку веб-разработка ныне является очень популярной и востребованной, мы также добавили в список .NET средства, которые используются во время создания соответствующих серверных веб-решений. Однако среди всех пунктов наиболее важным является знание языка С# - каждый “дотнетчик” обязан им владеть на высоком уровне.   В свою очередь, перечень можно дополнить такими технологиями, как: TDD (разработка через тестирование), WCF, Unit тестирование, рефакторинг приложений. Их знание не является обязательным, однако, дает дополнительное преимущество перед другими кандидатами в глазах работодателя.  Также вы можете ознакомиться со списком всех необходимых к изучению технологий на странице специальности .NET Developer. Комплексная программа обучения состоит из 49 видео курсов общей продолжительностью 346 часов. Перейдя на страницу, вы найдете много полезной информации  - как для новичка, так и для разработчика, желающего углубить и дополнить свои знания. Более подробно тему требований IT компаний к .NET разработчику рассматривал на вебинаре Виталий Емец - FullStack Developer, Microsoft Certified Specialist. Почему многие выбирают веб-направление и какими технологиями должен владеть кандидат? Ответы на эти и другие вопросы вы найдете в этом видео -  “Как стать C#/.NET разработчиком?”. ITVDN желает Вам достижения Ваших целей и готов быть надежным помощником в вопросах обучения программированию. Оставайтесь с ITVDN! 

Тип сайта и его тематика Функциональность сайта На сегодняшний день более половины всех сайтов в сети Интернет используют ту или иную систему управления контентом (Content Management System – CMS). Однако термин CMS не получил, к сожалению, четкого определения. Он может иметь несколько значений в зависимости от сценариев и целей человека или проекта. Некоммерческая международная организация AIIM (Association for Information and Image Management - Ассоциация по вопросам Управления Информацией и Изображениями) ввела в обиход понятия ECM (Enterprise Content Management) и WCM (система управления веб-контентом) как две составных части CMS.  В этом случае под ECM подразумевается программный комплекс, обеспечивающий документооборот, работу внутренней базы знаний и организующий в общем виде набор бизнес-процессов предприятия. Как одну из функций ECM может включать в себя и работу с веб контентом. Хорошим примером такого типа систем является платформа Microsoft SharePoint. В свою очередь WCM стало включать в себя набор инструментов в некотором комплексе, позволяющем управлять веб-сайтом и контентом на нем. Часто также CMS также называют «движком» сайта. В обиходе у разработчиков устоявшимся значением, подразумеваемым под CMS, является некоторая программная система, применяемая для создания, редактирования и управления контентом сайта и устанавливаемая на свой хостинг. В дальнейшем, в этой статье мы примем за основу именно это - последнее определение, более похожее на WCM. Стоит отметить и часто включаемые в число CMS так называемые SaaS решения (software as a service – услуга доступа к программному обеспечению). В случае такого типа услуг компании не предоставляют код, который вы можете скачать, установить и настроить под себя на своём хостинге. Провайдеры услуги SaaS предлагают для клиентов свои платформы, со своим хостингом, своими индивидуальными возможностями без предоставления CMS в обиходном понимании. При такой схеме вы фактически оплачиваете не владение вашим сайтом, а его аренду. В нашей статье мы не будем рассматривать такой тип услуг.   Рассмотрим подходы, которых следует придерживаться, решая вопрос как выбрать движок для сайта.   Критерии выбора CMS для вашего сайта Тип сайта и его тематика Большой выбор различных систем управления контентом на рынке объясняется различиями в типах сайтов, для которых лучше всего конкретная CMS подойдет. Будет это форум или интернет магазин, блог или корпоративный сайт, сайт-визитка или новостной портал – определенность с тематикой сайта это первое, от чего будет зависеть правильный выбор CMS. Функциональность сайта Не смотря на определенную специализацию каждой CMS под определенные задачи, на сегодняшний день для ТОП CMS существует огромное количество различных расширений (плагинов, модулей), существенно увеличивающих их функциональность и возможности «донастройки». К примеру существующими плагинами можно превратить «блоговый» движок в интернет-магазин, а на движке портала сделать форум. Однако нужно понимать, что большое количество дополнительных плагинов будут влиять и на быстродействие, и на безопасность, и на внутреннюю слаженность работы механизмов сайта, из-за возможных конфликтов этих расширений. Также определенный набор проблем может доставить и необходимость регулярных обновлений как самого движка, так и установленных плагинов. Без таких обновлений у вас будут открываться дыры в безопасности, а это вряд ли вам понравится. А обновление большого числа расширений может вызвать конфликты совместимости. Поэтому правильный выбор CMS это баланс между нужной готовой функциональностью движка «из коробки» и количеством (и качеством) установленных расширений. Исходя из задач и потребности в балансе, сложно однозначно ответить на вопрос «какая CMS лучше?». Требовательность к ресурсам Правильный выбор тематики сайта приводит к необходимости выбора условной «мощности» движка. «Мощнее», в нашем случае, вовсе не обязательно значит – «лучше». Если вы нуждаетесь, к примеру, в сайте-визитке, установка движка портала для вас будет избыточной. Значительная часть ресурсов мощной CMS останется не задействованной. При этом требования к хостингу такого сайта будут выше – вам понадобится больше оперативной памяти, больше ресурсов процессора, могут понадобиться некоторые специфические настройки сервера и предустановленное программное обеспечение. Также стоит понимать, что, к примеру, сайты администрации для поселка и для города миллионника хоть и имеют общую тематику, но будут иметь разный дизайн, функциональность, наполнение, разную посещаемость и, соответственно, разные требования. Поэтому, при выборе вам следует исходить и из масштабов вашего будущего сайта. Неправильный выбор выльется либо в необоснованное удорожание и хостинга, и администрирования вашего сайта, либо в нехватку ресурсов. Возможность кастомизации движка Многим владельцам сайтов не хватает возможностей «голой» CMS. Кроме того, из-за специфики каждого конкретно бизнеса и каждого конкретного сайта, возможности расширения с помощью дополнительных плагинов тоже может быть недостаточно. Может потребоваться индивидуальная доработка движка, тем оформления или доработка под заказчика тех плагинов, функциональности которых не вам хватает. В этом вопросе нам очень важно будет понимать следующие моменты: Количество разработчиков на рынке – специалистов по конкретной CMS; Количество и качество документации к CMS и плагинам; Развитость сообщества пользователей и разработчиков конкретной CMS. Можно с уверенностью сказать, что чем более распространён движок – тем больше доступных специалистов, тем проще внести нужные правки и тем дешевле эти правки обойдутся. Стоит уделить внимание и особенностям SEO-оптимизации конкретного движка. Если вы хотите, чтобы аудитория вашего сайта росла, вам придется соответствовать ряду правил, касающихся и скорости работы сайта на различных типах устройств, и внешнего дизайна сайта вообще и конкретных страниц в частности, и внутренней иерархии страниц, и правильной настройки индексации и т.п. Возможность проведения SEO оптимизации вашего сайта сложно переоценить.  Наличие уже встроенных в CMS SEO инструментов или доступных качественных плагинов, а также возможность доработки их под ваши нюансы проекта привлеченными разработчиками, будут очень важны на этапе продвижения вашего сайта. Стоимость CMS и доработки. На рынке сегодня присутствуют как качественные бесплатные, так и значительное количество различных платных CMS. Кроме того, выбирая бесплатные CMS, вам вероятно захочется добавить в них платные расширения.  Выбирая между платными и бесплатными вариантами вам стоит заранее определиться с несколькими моментами: Представить себе (хотя бы приблизительно) стратегию развития вашего сайта. От понимания дальнейших перспектив будет зависеть комбинация доступных расширений и необходимость их доработок. Может так сложиться, что выбор бесплатной CMS, с учетом плагинов и доработок для получения нужного функционала, окажется существенно дороже, чем купить платную CMS и платный плагин, получив при этом техническую поддержку разработчиков этой CMS. Также может оказаться, что нужный для вас плагин под конкретную CMS нужно будет разрабатывать с нуля, тогда как под другую CMS такой плагин есть уже готовый, давно выпущенный и протестированный в реальной работе.   Распространенность CMS и ее востребованность Если выбранный вами движок сайта окажется непопулярным и его разработчики решат перестать выпускать обновления, вы столкнетесь с рядом проблем. Это и падение уровня безопасности системы, и ухудшение внешней привлекательности на фоне новых сайтов-конкурентов, использующих новые технологические решения. Также существенно сложнее будет найти специалиста для внесения доработок в движок, использующий уже устаревшие и непопулярные технологии. В свою очередь выход новейшей версии движка может быть связан с кучей багов системы, наличия новых дыр безопасности, несовместимости со старыми плагинами и другими сложностями. Самописные движки Наличие такого числа сложностей при выборе системы управления для своего сайта может вызвать у вас желание заказать или написать свой сайт с нуля. Действительно, ряд проектов прямо потребует от вас такого подхода. Подключение к своим специфическим сервисам, интеграция с другими уникальными проектами, гибкость в дизайнерских и архитектурных решениях – в определенных обстоятельствах написание своего движка будет правильным решением. Однако стоит сразу учитывать набор проблем, с которыми вам предстоит столкнуться: Подсадка «на иглу» одного разработчика. Полноценно разбираться в куче кода, с слабо или вовсе недокументированными возможностями, сможет только сам автор кода. Новому разработчику может оказаться проще переписывать модули вашего сайта с нуля, чем тратить время на разбор чужого кода. Это с одной стороны существенно удорожит работу, а с другой жестко привяжет вас к конкретному разработчику. Даже сменив одного программиста на другого, вы оказываетесь в той же ситуации, только теперь с новым разработчиком. Сроки и цена разработки. Написание нужных модулей «с нуля» будет стоить значительно дороже и займет значительно больше времени, чем адаптация уже существующего движка и плагинов с хорошей документацией от авторов. Проблемы тестирования и ошибок. В движках, которые используют каждый день миллионы человек, есть значительный плюс – большинство багов выявляются мгновенно и быстро перекрываются обновлениями. Наличие багов в вашей самописной системе будет зависеть как от навыков вашего разработчика, так и от применяемых им технологий. Эта комбинация может нести большое количество скрытых проблем как работоспособности, так и безопасности, которые останутся не выловленными, пока не станет слишком поздно. В результате разработка своего движка оказывается выгодна, практически, только крупным компаниям со своими внутренними отделами разработки и тестирования, которые будут писать свой сайт и поддерживать его работоспособность независимо от сторонних разработчиков. Статистика использования CMS   По данным сайта w3techs.com более 55% всех Web-сайтов в Интернете управляются теми или иными CMS. Как видно из диаграммы более 33% всех сайтов в Интернете работают на движке WordPress. Фактически это более 60% от сайтов, управляемых теми или иными CMS. Следующие по популярности системы CMS: Joomla – 5.4%, Drupal – 3.5%, Magento – 1.8%, PrestaShop – 1.4%. Набравшие в этой диаграмме высокие места Shopify (2.7%), Squarespace (2.7%) и Wix (1.8%) предлагают услуги SaaS (которые мы здесь не рассматриваем). По данным портала WhatСms первое место по числу сайтов среди популярных CMS также принадлежит WordPress - 52.74%. Затем идут Joomla - 5.219%, Drupal - 3.953%, Magento - 2.840%, PrestaShop - 1.671%. Blogger, как и несколько компаний в предыдущей диаграмме, является SaaS платформой. По данным портала BuiltWith первые три места среди не SaaS CMS занимают: WordPress - 28.27%, Joomla – 26.93%, Drupal – 8.84%. По данным портала SimilarTech, предлагающего свой ТОП движков для сайтов, среди 9,5 млн сайтов на CMS также лидирует WordPress, заняв 68% рынка CMS. Слетом идет Drupal (версии 6 и ниже) – 4%, Joomla – 3%, Drupal 7 – 1%, Typo3 – 1%. В число других CMS вошли как SaaS решения, так и другие полноценные CMS, включая и Drupal 8. Проанализировав указанную статистику, мы выбрали следующий 6 ТОП CMS: WordPress, Joomla, Drupal, Magento, PrestaShop и Typo3. Проведем краткий обзор движков для сайтов, входящих в наш ТОП CMS.   1) WordPress Выпущенный впервые в 2003 году, CMS WordPress быстро завоевал популярность как у продвинутых разработчиков, так и простых пользователей. Благодаря простой настройке, не самой высокой требовательностью к ресурсам хостинга и огромному количеству расширений эта CMS уже многие годы занимает первое место. На сегодня именно WordPress называют лучшей CMS для блога. WordPress идеально подходит для довольно простых веб-сайтов, таких как ежедневные блоги и новостные сайты, и для тех, кто ищет для себя простую CMS. Дополнения позволяют легко расширять функциональность сайта. К примеру, благодаря плагину WooCommerce, из сайтов на движке WordPress получается удобный для управления интернет-магазин – один из самых распространенных вариантов интернет-магазинов в сети. Нужно отметить и большое количество SaaS решений, использующих на своей платформе этот движок. Часть успеха WordPress в представленных диаграммах без сомнения относится к SaaS решениям. Официальный сайт WordPress: https://wordpress.org/ Особенности WordPress: Последняя версия - 5.0.3 от 09.01.2019. Написан на PHP. Более старые версии чем 5.0 официально объявлены «небезопасными». Минимальные требования к хостингу, поддержку которых обещает разработчик: PHP 7.3 MySQL 5.6 или MariaDB 10.0; HTTPS; Apache или Nginx. Плюсы WordPress: Бесплатная CMS распространяется с открытым исходным кодом. Огромное количество как платных, так и бесплатных шаблонов, и плагинов. Удобная панель администратора. Простая CMS для пользователя. Отмечают простоту использования и легкость установки как движка, так и тем, и расширений. Большое сообщество. Достаточно высокая производительность. Доступные платные плагины с проверенным качеством. Минусы WordPress: Относительно не маленькая требовательность к ресурсам, особенно при установке значительного числа плагинов. Отсутствие технической поддержки в не SaaS вариантах. Многие плагины написаны некачественно, что создает проблемы в работе и дыры в безопасности. Сайты на WordPress взламывают чаще всего.   Для каких сайтов используют CMS WordPress: Популярность WordPress продолжает расти: При этом в Украине сейчас 34910 сайтов используют эту CMS, а в Российской Федерации - 297353.   2) Joomla CMS Joomla впервые увидела свет в 2005 году. Отражая философию этого движка, его назвали словом, звучащим на суахили как «всё вместе». Фактически разрабатываемая как CMS для порталов, Joomla позволяет создавать сайты с большей гибкостью контента и внутренней структуры, чем WordPress, но при этом с достаточно простым и интуитивно понятным интерфейсом. Эта CMS поддерживает электронную коммерцию, социальные сети и многое другое. Используя этот движок, разработчики создают сайты-визитки, интернет-магазины, фотогалереи, порталы (включая новостные), блоги и другие сайты. Рядом пользователей, Joomla признается лучшей CMS для сайта типа портал. Официальный сайт: https://www.joomla.org/ Особенности движка Joomla: Последняя версия – 3.9.3 от 12.02.2019. Написана на PHP и JavaScript. Минимальные системные требования: PHP 5.3.10; MySQL  5.1 или SQL Server 10.50.1600.1 или PostgreSQL 8.3.18; Apache 2.0 или Nginx 1.0 или Microsoft IIS 7. Плюсы Joomla: Бесплатное распространение с открытым исходным кодом по лицензии GNU GPL v2, включая обновления; Частое предоставление обновлений движка; Большое сообщество пользователей и разработчиков; Большое количество доступных платных и бесплатных тем и плагинов; Относительно не высокий уровень требований к разработчику и пользователю. Минусы Joomla: Отсутствие технической поддержки. Вторая CMS по числу взломов. Joomla применяется в следующих сферах: В Украине 907  сайтов используют эту CMS и 3800 сайтов - в Российской Федерации. Есть определенная тенденция по снижению популярности CMS Joomla: 3) Drupal Впервые вышедшая в 2000 году, CMS Drupal является мощным, удобным для разработчиков инструментом для создания сложных сайтов. Как и большинство мощных инструментов, Drupal требует определенных знаний и опыта для работы. На основе Drupal часто создают порталы, новостные сайты, форумы, интернет-магазины - одни из самых продвинутых сайтов. Тем не менее Drupal является самым сложным для пользователя движков из тройки лидеров. Хотя его использование с каждым выпуском и становится все проще, если вы не готовы погрузиться в изучение этого программного обеспечения или не можете нанять кого-то, кто его знает, возможно, это не лучшая система управления контентом для вас. Официальный сайт: https://www.drupal.org/   Особенности Drupal CMS: Последняя версия 8.6.10; Ядро предоставляет только минимальный функционал, нужный для работы CMS, остальной функционал добавляется за счет плагинов. Установка модулей происходит в связке. Если для реализации функционала какого-то модуля нужны другие модули – они установятся автоматически в связке с первым модулем. Минимальные требования к хостингу для CMS Drupal 8: PHP 5.x/7.x для x86 и PHP 5.x для x64; MySQL 5.5.3 или MariaDB 5.5.20, или Percona Server 5.5.8, или PostgreSQL 9.1.2, или SQLite 3.6.8; Microsoft SQL Server и MongoDB поддерживаются благодаря отдельным модулям; Apache 2.x (используется в качестве Web-сервера для Drupal чаще всего) или Nginx (0.7.x, 0.8.x, 1.0.x, 1.2.x), стабильная версия 1.8.x или 1.9.x. Плюсы Drupal: Бесплатная CMS с открытым исходным кодом GNU GPL 2+. Стабильная работа ядра движка. Большое количество бесплатных тем, и различных расширений. Достаточно развитое сообщество разработчиков. Для решения типовых задач есть готовые наборы плагинов. Drupal известен своей мощной таксономией и способностью отмечать, классифицировать и организовывать сложный контент. Минусы Drupal: Сложность использования для начинающих пользователей. Меньшее количество доступных бесплатных плагинов чем у предыдущих CMS. Отмечают большую требовательность к хостингу за счет более частых обращений движка к базе данных, чем у других движков. Сегодня эту CMS используют в 7110 сайтов в Украине и 45189 сайтов в Российской Федерации. Можно наблюдать определенное снижение интереса к этой CMS по сравнению с 2016 годом:   4) Magento CMS Magento — движок для интернет-магазинов и других вариантов электронной коммерции. В основном популярен в западных странах и слабо представлен в русскоязычной части Интернета из-за слабой интеграции с местными сервисами. В настоящий момент является собственностью Adobe Inc. В основном Magento используется для крупных проектов. Считается не рентабельным использовать его для магазинов с несколькими сотнями позиций в обороте из-за относительно высокой стоимости разработки. Официальный сайт: https://magento.com/. Особенности CMS Magento: Написан на PHP. Последняя версия 2.3.0 от 28.11.2018. Требования к хостингу: LAMP (Linux, Apache, MySQL, and PHP) или LNMP; Apache 2.x или Nginx 1.7.x; PHP 5.6 или 5.5 или 5.4; MySQL 5.6 (Oracle or Percona); HTTPS; Доступ к crontab и к записи в .htaccess. Плюсы Magento: Бесплатная система с открытым исходным кодом. Движок оптимизирован под требования поисковых систем «из коробки». Готовая функциональность движка в базовой версии. Являясь собственностью Adobe Inc., отлично поддерживает интеграцию с сервисами Adobe. Минусы Magento: Несмотря на открытый исходный код, многими разработчиками считается не удобным работать с этой CMS из-за особенности организации ее кода. В бесплатной версии нет технической поддержки, платная версия будет стоить несколько тысяч долларов в год. Отсутствует интеграция с платежными средствами и другими локальными сервисами на постсоветском пространстве. Низкая скорость загрузки страниц сайта «из коробки». Большая часть настроек сайта потребует специфических знаний и навыков.   В Украине на сегодня 1113 сайтов используют CMS Magento и 1774 используют ее в Российской Федерации. После 2016 года можно наблюдать некоторое снижение числа сайтов на этой CMS:    5) PrestaShop PrestaShop – это еще один пример простой CMS с открытым исходным кодом для создания интернет-магазина. Созданный в 2008 году, этот движок достаточно быстро обрел популярность и продолжает ее наращивать. Это достаточно простая бесплатная CMS создана для организации торговых площадок и интернет магазинов. Официальный сайт: https://www.prestashop.com Особенности PrestaShop: Текущая версия – 1.7.5.1 от 18.02.2019. Написан на PHP с применением фреймворка Symfony. Минимальные требования к хостингу: PHP 5.6; MySQL 5.0; Server RAM – чем больше, тем лучше; Unix, Linux или Windows; Apache 2.2 или Nginx 1.0 или Microsoft’s IIS Web server 6.0. Плюсы PrestaShop: Бесплатный движок с открытым исходным кодом. Большое количество доступных тем оформления и расширений. Достаточный для начала работы интернет-магазина стандартный набор базовой версии движка. Имеет отличную русскую локализацию. Богатый выбор модулей для развития интернет-магазина. Хорошая интеграция с различными сервисами на постсоветском пространстве. Простота установки и работы. Удобная интуитивно понятная панель администрирования. Базовая версия имеет хорошую SEO-оптимизацию. Активные сообщества разработчиков. Минусы PrestaShop: Качественные темы и расширения являются платными. Более требователен к ресурсам чем WordPress. Низкая безопасность у бесплатных тем и плагинов. Наблюдаются баги при проведении внутренней оптимизации. Можно видеть рост популярности CMS PrestaShop. Например, на сегодня уже 2461 сайт работает на этом движке в Украине, и 8423 сайтов - в Российской Федерации.    6) Typo3 Typo3 это CMS с открытым исходным кодом. Впервые этот относительно универсальный движок был представлен в 1998 году. Typo3 часто применяется для новостных порталов, интернет-магазинов, корпоративных сайтов и других вариантов сайтов.   Официальный сайт: https://typo3.org/.   Особенности Typo3: Написан на PHP. Последняя версия 9.5.4 от 22.01.2019. Особенностью Typo3 является то, что в проектах на этой CMS вся информация публикуется от администратора и сайты не работают с пользовательским контентом. Typo3 не приспособлена для создания блога, активно взаимодействующего с пользователем портала или социальной сети. Минимальные требования к хостингу: Linux, Windows или Mac; PHP> = 7.2; PostgreSQL / Microsoft SQL Server / MariaDB >= 10.2 / MySQL >= 5 <= 5.7 / SQLite; Apache httpd или Nginx или Microsoft IIS, Caddy Server. Плюсы Typo3: Простота администрирования сайта. Возможность управления несколькими проектами из одной панели администратора. Возможность создания отдельных разделов на сайте с раздельным доступом для разных типов пользователей. Минусы Typo3: Относительно высокая требовательность движка к ресурсам сервера. Сложность изучения документации. Основная часть материалов не переведена с английского. Также, как и у ряда предыдущих CMS, у Typo3 наблюдается снижение популярности с 2016 года. В свою очередь в Украине на этом движке зарегистрировано 399 сайтов, в Российской Федерации - 1327. Полезным будет рассмотреть и сравнение производительности среди ТОП CMS.   Популярные CMS. Сравнение производительности. Согласно опубликованным данным тестирования ряда CMS, можно сделать вывод о наиболее быстром движке (пусть и в искусственных  - «тепличных» условиях теста). Указанные данные в таблице – это количество обрабатываемых запросов в секунду. Наиболее быстрой в данном исследовании среди популярных CMS показала себя WordPress 5.0 с версией PHP 7.3.   Вывод В нашем кратком обзоре CMS мы рассмотрели ТОП 6 наиболее распространенных CMS в мире. Как мы видим, каждая из них имеет свою специфику и особенности. Из-за разных возможных сфер применения сложно выбрать лучшую систему управления сайтом. Как лучшая CMS для блогов многими пользователями отмечается WordPress, а PrestaShop многими определяется как лучшая CMS для сайта интернет-магазина. Стоит понимать, что большая часть представленных в нашем ТОП CMS движков являются относительно универсальными. Кроме PrestaShop и Magento, ориентированных на интернет-коммерцию, с помощью других движков можно делать разнотипные проекты. Однако многими разработчиками признается, что никакая универсальная CMS не будет работать в конкретной сфере также хорошо, как специально разработанная для этой цели CMS. Поэтому, полезно кроме данного обзора ТОП CMS, рассмотреть отдельно ТОП CMS для блогов, ТОП CMS для интернет-магазинов, ТОП CMS для форумов, и далее. Такие обзоры помогут лучше понять, как правильно выбрать движок для сайта с вашими уникальными потребностями. Как вы могли заметить, рассмотренные CMS из ТОП движков для сайтов написаны на PHP. Если вы определились с CMS для своего проекта и хотите его сами доработать, или просто хотите научиться работать с топовыми проектами сети Интернет - вам, вероятно, будет интересен наш набор курсов  и вебинаров на портале ITVDN: WordPress Starter и WordPress Essential WordPress: создаем блог за час Интеграция верстки лендинга на CMS WordPress PHP Starter How To PHP Starter PHP Essential 

Когда вы начинаете свои эксперименты с Vue и открываете инструменты разработчика в браузере, вы обнаружите предложение загрузить инструменты разработчика Vue.js по указанной ссылке. Дружеское напоминание. Что это? Любой мало-мальски популярный фреймворк обладает своим расширением для разработчиков, которые, как правило, добавляют новые панели в браузере и являются гораздо более узкопрофильными, нежели поставляемые браузером по-умолчанию. В нашем случае мы получим возможность инспектировать Vue-приложение и взаимодействовать с ним на системном уровне. На самом деле это действительно очень полезный и мощный инструмент. Разработчик может инспектировать приложение только в режиме разработчика. Благодаря этому мы можем быть уверены, что никто не сможет посредством расширения изменять данные приложения, когда само приложение на продакшине (а также повысить производительность Vue, так как ему не нужно заботиться о запущенных в данный момент инструментах разработчика). Теперь перейдем к установке! Существует три способа установить инструменты разработчика: в Chrome в Firefox в отдельное приложение По-умолчанию Safari, Edge и прочие браузеры не имеют поддержки для панели инструментов, но с использованием отдельного приложения тестировать можно в любом браузере.   Установка в Chrome Переходим по этой ссылке: https://chrome.google.com/webstore/detail/vuejs-devtools/nhdogjmejiglipccpnnnanhbledajbpd и кликаем на клавишу Add to Chrome. Проходимся по всему процессу установки: Иконка установленного приложения появляется в панели инструментов. Если на странице на данный момент Vue-приложение не запущено, иконка приобретает серый оттенок. Если же нужное приложение запущено — поздравляем! Иконка Vue расцветает во всей своей красе. Сама по себе иконка ничего не делает, разве что показывает, что мы работаем с нужным типом приложения. Чтобы использовать установленное расширение, мы должны открыть панель разработчика «View → Developer → Developer Tools» - или Cmd – Alt – I.   Установка в Firefox Ссылка: https://addons.mozilla.org/en-US/firefox/addon/vue-js-devtools/ Нажмите «Add to Firefox» и расширение будет установлено. Подобно Chrome, в зависимости от открытого веб-приложения, иконка будет изменять окрас. И когда вы посещаете Vue-сайт, можно открыть панель разработчика и увидеть панель «Vue».   Установка в отдельное приложение Ну, это вообще проще простого: и запустите расширение при помощи благодаря чему откроется отдельное приложение на базе Electron. Теперь тег скрипта покажет вам следующее: внутри файла index.html. Теперь нужно подождать, пока приложение перезагрузится и автоматически свяжется с Vue-программой.   Как использовать инструменты разработчика Как и было сказано, инструменты разработчика Vue могут быть использованы в панели разработчика в браузере. Также можно просто кликнуть на любом элементе страницы и выбрать «Inspect Vue component». Как только панель открыта, мы можем переместиться к дереву компонентов. Когда мы выбираем компонент в левом списке, в правом  окне отображается информация о выбранном элементе. Вверху вы можете заметить 4 кнопки: Components – показывает все представленные на данной странице элементы. Vue может иметь несколько запущенных экземпляров в одно и то же время. К примеру, вы можете просматривать слайдшоу из небольших, легковесных виджетов. Vuex – здесь вы можете просматривать текущее состояние. Events – как и следует из названия, показывает все порожденные события. Refresh – перезагружает панель разработчика. Заметили небольшой текст = $vm0 рядом с компонентом? Это весьма полезный способ просмотреть компонент с использованием консоли. Нажмите esc и вы увидите консоль под панелью разработчика. Если вы введете приведенный код, вы сразу же перейдете к указанному компоненту. Очень удобно просматривать и взаимодействовать с компонентами приложения, не прибегая при этом к биндингу их значений и к неким глобальным переменным.   Фильтр компонентов Начните вводить имя компонента и дерево компонентов автоматически выведет все совпадения.   Выбор компонента на странице Кликните и вы сможете выделить любой компонент на странице мышкой, кликнуть на него и открыть в панели разработчика.   Форматирование имен компонентов Вы можете отображать имена в camelCase или через символы нижнего подчеркивания (_).   Фильтрация информации о компоненте В правой панели вы можете ввести любое слово и отсеять те свойства, которые не содержат его.   Отображение DOM Нажмите на клавишу «Inspect DOM».   Открытие в редакторе Любой пользовательский (не являющийся частью фреймворка) компонент обладает клавишей, при нажатии которой его можно открыть в вашем дефолтном редакторе. Очень удобно. Я собираюсь изучать Vue на постоянной основе и через 2 месяца создам ресурс, который также позволит вам изучить Vue максимально быстро — с проектами и туториалами, рабочими примерами и подборками скриншотов. До скорого!   Автор перевода: Евгений Лукашук Источник

Добрый день, дорогие читатели блога ITVDN. Сегодня я затрону очень важные темы о виртуальной машине среды .Net, которую в Microsoft назвали CLR (Common Language Runtime - Общеязыковая среда выполнения). Вы узнаете, что значит промежуточный код, познакомитесь с важными компонeнтами CLR: JIT (Just in Time compiler) компилятором и его ролью в выполнении кода, также со Сборщиком Мусора(Garbage Collector). Будет полезно получить ваши отзывы, положительные и отрицательные.   C# является языком общего назначения платформы .NET (эта платформа поддерживает разные языки, которые отличаются друг от друга, например, VB.NET, F#, весь список можно поискать в интернете), разработанный компанией Microsoft, учитывая плюсы и минусы ряда языков, таких как C++ и Java. Это ни в коем случае не значит, что Microsoft занимается копированием, в мире технологий это в порядке вещей, каждая новая технология основывается на старых, Java был разработан на основе других языков (включая C++), такие инструменты для Java, как Spock Framework или Gradle, были созданы, учитывая минусы предшественников, сам C++ был разработан на основе C и в начале назывался “Си с классами”. Вся эта информация доступна в интернете. Вернемся к C#, двумя его особенностями являются компиляция кода и автоматическая сборка мусора. Поговорим о каждой по отдельности.   Компиляция кода Сущность компиляции в том, что написанный нами код сначала компилятором (каждый язык .Net имеет свой компилятор) переводится в промежуточный язык IL(Intermediate Language, его также называют MSIL, CIL или просто байт-код). После байт-код переводится в машинный код (нули и единицы), понятный процессору. За это отвечает JIT-компилятор. Это свойство есть и у других языков .NЕТ платформы, если, например, есть программа, написанная на C# и VB.NET, они отдельно скомпилируются, но после эти части программы уже будут соединены в одно целое на уровне байт-кода. Если здесь задуматься, можно понять смысл названия “Общеязыковая среда выполнения”, это среда, где вместе выполняется байт-код от разных языков .NET платформы.   Способом компиляции работают также языки C++ и Java. Есть еще интерпретируемые языки, в их случае код выполняется строка за строкой. Наиболее известными языками этого семейства являются Javascript, PHP, Python.   А теперь давайте создадим консольное приложение и посмотрим, что из себя представляет байт-код. Откройте папку приложения, зайдите в bin, потом Debug и скопируйте путь к этой папке, она вам пригодится. Для этого просто нажмите на иконку папки, который показан стрелкой в картинке снизу. Папка будет пуста, но как только выполните программу, в ней появятся 3 файла, первый из них мы откроем с помощью утилиты ILDasm (IL Disassembler), который устанавливается вместе с Visual Studio. В картинке не видно, но у файла расширение “.exe”. Делать это очень просто, откройте Start Menu, в папке Visual Studio найдите Developer Command Prompt и запустите его. В появившемся окне напишите “ildasm.exe” и путь к файлу, который вы скопировали, после добавьте имя первого файла в списке вместе с расширением(у меня имя файла “HelloStudents”, потому что я так назвал свой проект). В открывшемся окне увидите Манифест сборки и имя вашего проекта.     Развернув его, перед вами откроется такая картинка.   Давайте откроем “Main : void(string[])”, здесь IL-код нашего метода Main, который во время выполнения программы JIT-компилятор генерирует в машинный код. О работе JIT добавлю, что есть 3 типа: Нормальный(по умолчанию) JIT Econo JIT Pre JIT Чтобы не было необходимости постоянно проделывать эти шаги, есть способ открыть ILDasm через Visual Studio. Для этого в Visual Studio откройте External Tools в разделе Tools. В поле “Title” дайте название “ILDasm”, а для поля “Arguments” выберите значение, которое видите на скриншоте, после нажмите на многоточия поля “Command” и найдите папку, где находится ildasm.exe в операционной системе(у меня путь к нему был таким C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools), выберите нужный файл. Сохраните изменения и после этого в разделе “Tools” появится ILDasm. Примечание Eсли присмотреться к картинке сверху, можно увидеть дату релиза фреймворка .NET версии 4.6.1   Автоматическая сборка мусора Цель автоматической сборки мусора состоит в том, чтобы освобождать память во время работы программы автономно, тем самым освобождая разработчиков от этой проблемы, которая требует довольно больших усилий. С этой стороны, C# - противоположность известного языка C++, который требует вручную освобождать память при написании программы. Проще говоря, в случае C++ при выполнении программы память освобождается в соответствии командам, которые дали сборщику мусора разработчики и соответственно это приводит к быстродействию программы, а в случае C# сам CLR решает, когда и как освобождать память, но это отрицательно влияет на скорость выполнения кода. Важным аспектом, который на мой взгляд должен знать каждый начинающий C# разработчик, является понятие поколений. Объекты, созданные в ходе выполнения программы, хранятся в управляемой куче, в которой разделяются 3 поколения (поколение 0,1,2), их размер устанавливает CLR. В первой хранятся только что созданные объекты, когда в нем не хватает места для новых объектов, сборщик мусора очищает ненужные, чтобы освободить память, а оставшиеся перемещает в поколение 1. Если в следующий раз при работе сборщика в поколении 0 будет достаточно свободного места для новых объектов, поколение 1 останется нетронутым, даже если там существуют объекты, являющиеся мусором. Но как только при очистке поколения 0 не освободится достаточно памяти для новых объектов, сборщик мусора вместе с поколением 0 очистит и его. Все объекты, которые переживут очистку в поколении 1, перейдут в поколение 2. Если дойдет до того, что начнется чистка в поколении 2, объекты, пережившие ее, останутся там же. Этим способом осуществляется очистка так называемых малых объектов, но существуют также большие объекты, размер которых достигает 85000 байт и выше. Они сразу помещаются в поколении 2. Такой способ освобождения памяти повышает производительность, так как делать очистку и сжатие (дефрагментация) памяти в отдельной части управляемой кучи получится быстрее, чем сразу во всей куче. Читая эту статью, можно было подумать, что сборщик мусора работает полностью без вмешательства разработчиков, но это не совсем так. Существует статический класс GC, в котором реализованы ряд статических методов и одно свойство, которые дают возможность поработать со сборщиком мусора. Это было все, что я хотел сказать, если тема вам интересна, прочитайте и выполните задания, приведенные ниже. Самостоятельная работа Прочитайте об этих понятиях Высокоуровневое/низкоуровневое программирование IDE/Text Editor, различия между ними Манифест сборки Ассемблер, различие от IL Управляемый/неуправляемый код, для чего реализован интерфейс IDisposable   Полезные ресурсы Очень рекомендую изучить материалы о сборке мусора в руководстве Microsoft по .NET и прочесть главу 21 книги Дж. Рихтера “CLR via C#”. Их довольно трудно усвоить, но если прочтете 2-3 раза, во многом разберетесь, я сам пользовался ими для этой статьи. С их помощью узнаете, в каких случаях, кроме переполнения памяти, производится очистка памяти, узнаете о режимах сборки мусора, получите больше информации о куче больших объектов, увидите примеры использования класса GC. Кстати, на сайте ITVDN можете найти обзор книги Рихтера от Александра Шевчука. Автор: Vahram Papazyan

.NET спецификация говорит о том, что приложение никогда не должно генерировать NullReferenceException. Впрочем, риск встречи подобного все равно остается во многих библиотеках и приложениях. Де-факто, NullReferenceException – это наиболее часто встречаемый тип исключений. И здесь на сцену выходит C# 8. В новой версии сего прекрасного языка ссылочные типы больше не могут принимать null по-умолчанию. Это и огромный плюс, и отличное нововведение. Но… Это все, конечно, хорошо, но как будут обстоять дела с поддержкой старых библиотек? Именно в этой статье мы как раз и разберем этот вопрос. Зачем нам вообще избегать NullReferenceException? Когда выбрасывается NullReferenceException, причину ошибки далеко не всегда так уж просто найти. Ошибки обычно возникают далеко от очага реальной проблемы. Именно поэтому возникновение подобных ошибок и является крайне нежелательным. Потому вместо проверки на null-исключения просто выбрасывайте ArgumentNullException. Если где-то мы передаем null в качестве аргумента, мы можем просто на уровне компиляции запретить это делать. Просто выбрасываем ArgumentNullException – и мы сразу увидим первопричину ошибки в системе. Давайте рассмотрим, как именно C# 8 решает подобные проблемы. Установка C# 8 На момент написания статьи официального релиза C# 8 еще не было. Впрочем, даже сейчас вы можете его опробовать. Сейчас, на момент написания статьи, для этого нужно иметь Visual Studio 2017 15.5-15.7. На заметку! Устанавливая эту версию компилятора, вы наверняка встретите множество предупреждений со стороны уже существующих C#-проектов. По-умолчанию используется последняя стабильная версия языка. Чтобы избавиться от предупреждений, просто явно задайте версию компилятора. Ссылочные типы больше не могут принимать null Ничего сложного для понимания здесь нет. Синтаксис, подобный  обычным значимым типам. Хотите, чтобы ссылочный тип принимал null? Ставим после оглашения типа знак вопроса. В то же время, хотя внешне синтаксис ссылочных и значимых типов выглядит похоже, сам принцип реализации кардинально другой. При работе со значимыми типами компилятор использует специальный тип Nullable. Это значимый тип, который помимо прочего также содержит в себе приватное булевское поле, определяющее, является ли значение переменной null. Со ссылочными типами компилятор просто добавляет атрибут Nullable. Версия 8 распознает этот атрибут и обрабатывает его соответствующим образом. Версия 7 его не понимает и просто игнорирует. При компиляции программы под C# 7 Book b и Book? b будут распознаны одинаково. Приведенный выше тип Book определяет не-nullable свойства Title и Publisher, а также nullable Isbn. Плюс, этот тип также содержит конструктор-кортеж. Используя тип Book и получая значение переменной Isbn, мы можем хранить полученные данные только в переменной типа string?. Присваивание Nullable к не-Nullable В случае, если нам нужно присвоить nullable-тип, C# 8 анализирует код. В коде ниже, так как isbn сравнивается с null, после условной конструкции isbn больше не сможет вернуть null. И так как сигнатура метода не предусматривает возвращение string?, при возвращении значения типа произойдет конверсия. Конечно, эту же конструкцию можно написать гораздо проще и элегантнее. Возвращение и передача значения Здесь мы можем видеть класс NewAndGlory, построенный с использованием возможностей последней версии С#. Сигнатура метода GetANullString предусматривает возвращение null, так что в нашем случае этот метод просто возвращает null. Метод GetAString не сможет в свою очередь вернуть null. Что же касательно последнего метода PassAString, тут тоже все очень просто. Мы передаем string и возвращаем также string. По этой причине смысла в проверке на null нет. С другой стороны, предположим, что у нас есть библиотека TheOldLib, использующая 7 компилятор (задается в файле *.csproj). Класс Legacy определяет метод GetANullString, что просто возвращает null. Метод PassAString принимает строку и проверяет ее на null. Также библиотека определяет интерфейс ILegacyInterface, задающий сигнатуру метода, что возвращает строку. С использованием шарпа 7 версии, мы не можем здесь указать, должна ли строка принимать null, или нет. Приложение на C# 8 могут использовать библиотеки, созданные и при помощи C# 7 Теперь давайте рассмотрим пример консольного приложения, что ссылается на старые и на новые библиотеки. Используя класс NewAndGlory, в качестве ожидаемого результата метода GetNullString мы можем получить только string?. Попытка же передать null в метод PassAString породит ошибку уровня компиляции (невозможно преобразовать null в не-nullable значение). Обращаясь к классу Legacy, где метод GetANullString, результат может быть записан в тип string. И, так как эта библиотека не создавалась под эгидой C# 8, наш компилятор будет покорно молчать. Претензии он будет предъявлять только в отношении «новых» сборок. Также здесь мы можем вызвать метод PassAString и спокойно передать в нее null. Если бы компилятор ругался на все подобные нюансы более ранних сборок, список возможных ошибок мог формироваться до бесконечности, поэтому здесь и применяется принцип «разностного отношения». Метод Foo интерфейса ILegacyInterface, определенный в библиотеке, собранной с использованием более ранней версии языка, – и здесь он возвращает string. Но как же нам тогда его использовать в C# 8? Как можно заметь ниже, здесь интерфейс может быть реализован с использованием как string, так и string?. Интерфейсы, реализуемые в рамках C# 8, требуют прямого указания поведения по отношению null. Приложения под C# 7 с использованием сборок C# 8 Что же касательно использования более новых версий сборок в ранних версиях языка, тут нет никаких проблем: все происходит, как и с любыми другими .NET-сборками. Приложение не будет видеть никаких string? – все nullable-ссылочные типы будут интерпретироваться как обычные ссылочные типы -  в нашем случае просто как string. И, конечно же, проблема NullReferenceException остается. Передача в метод PassAString null вызовет NullReferenceException. Для отлавливания подобного в рамках C# ранних версий мы можем проводить ручную проверку на null и выбрасывать ArgumentNullException. Возможно, эта ситуация по отношению к более старым версиям языка в миксе с новыми сборками с дальнейшим развитием C# 8 изменится, но это уже другой вопрос. В заключение Ссылочные типы, не принимающие null, – это одна из ключевых возможностей С# 8, позволяющая минимизировать риск возникновения ошибок типа NullReferenceException. Подобное стало возможным благодаря изменениям внутренней реализации ссылочных типов языка. Впрочем, несмотря на все нововведения, C# 8 по-прежнему может без каких- либо проблем использовать более ранние библиотеки, как и более ранние версии языка – новые библиотеки. Microsoft осталась верной своим канонам обратной совместимости и технически это стало возможно благодаря использованию специальных атрибутов для nullable-типов. Автор перевода: Евгений Лукашук Источник

Мой первый опыт переноса .NET приложения под .NET Core Совсем недавно я портировал .NET 4.5.2 – приложение под .NET Core 2.0. Хочу сразу отметить, что эта статья не является гайдом, и тем более это не перечень того, что может во время процесса пойти «не так». Однако она призвана дать общее понятие операции, мои впечатления от перехода на Core – стандарт и вообще, а стоит ли это делать. Приложение Приложение, которое я портировал, импортирует и обрабатывает информацию от ресурса SurveyMonkey. Проект DataPersistence – это уровень для взаимодействия с базой данных, в моем случае – через Entity Framework 6.2. Логика взаимодействия с SurveyMonkeys и преобразования данных так же, как и различные администрирующие функции, помещены в библиотеке ImporterCore. Importer – это небольшое консольное приложение, которое инкапсулирует определенную функциональность из ImporterCore, позволяя запустить ее в качестве запланированной Windows-задачи. Проект Explorer является веб-приложением ASP.NET MVC 5 для анализа информации. Проект Tests (на диаграмме не представлен) построен с использованием nUnit3 и обновляет все проекты к 5 версии. Кратко о процессе Сам порт занял у меня около двух дней. В конце концов картинка была следующая: Более 80 процентов усилий были затрачены на чтение блогов, логов ошибок и, конечно же, употребление кофе. Но только после всего этого я смог собой гордиться. Впрочем, если бы мне пришлось повторить порт снова, сейчас бы он занял у меня всего лишь одну четвертую от того времени, которое я потратил. Итак, касательно порта я могу сказать следующее: Просто погуглите готовые решения и применяйте их до тех пор, пока все это дело не заработает снова. Для всех компонентов, кроме, собственно говоря, самого веб-проекта, обновите csproj-файлы к более новому и упрощенному VS15-формату, который все еще поддерживает версию .NET 4.5.2. Я подумал, что лучше сделать это вручную, чем пересоздавать проекты с нуля. Выгрузите все проекты из решения отдельно от DataPersistance, которая была в основании пирамиды приложения. Соберите для .NET Core – стандарта. Обновите все пакеты библиотеки DataPersistence к последним версиям, поддерживаемым .NET Core. В некоторых исключительных случаях (наподобие работы с Entity Framework) полностью замените пакеты программ на .NET Core – аналоги (в нашем случае это будет Entity Framework Core). Просмотрите все провальные билды и исправляйте все изменения api до тех пор, пока проект не скомпилировался. Повторите шаги 2-4, добавляя дополнительные пакеты к приложению (по одному за раз). Чтобы заставить заработать веб-проект после порта, мне пришлось бы столько всего фиксить и исправлять, что я просто предпочел создать новый пустой проект и просто скопировал папку контроллеров, моделей и представлений + различные статические файлы в виде JavaScript и CSS. Перенос сайта на новый проект вместо исправления старого было определенно правильным решением. Запустите тесты. Запомните, что «построение того же самого, что и раньше» - это не то же, что «делать то же самое, что и раньше». Исправьте баги шага 7. Проведите мануальные тесты. Упущения К сожалению, далеко не все прошло так гладко, как хотелось бы. В основном замеченные ошибки были связаны с не совсем правильным выполнением шагов 7 и 8. Несовместимые библиотеки Дело в том, что ImporterCore зависела от библиотеки, которую я написал несколько лет назад и которая не поддерживает стандарт .NET Core. Она использует WebClient, который не существует в рамках .NET Core 1.0 / 1.1. К счастью, уже в версии 2.0 появилась поддержка WebClient, что значительно упростило обновление системы – нужно всего лишь внести некоторые изменения в csproj, AssemblyInfo и nuspec – файлы. Однако в случае, если вы все же сильно зависите от неподдерживаемых библиотек, порт приложения будет невозможен. Entity Framework Эта вещь заняла больше всего времени. Дело в том, что Entity Framework 6.2 в .NET Core не поддерживался, а его аналог – Entity Framework Core – значительно различается, что делает процесс порта достаточно трудоемким. А именно: Маппинг В конце концов EF Core мне понравился больше, чем EF 6.2. Здесь я привожу пример оригинального файла маппинга для оригинального объекта – Survey. Здесь Entity Framework получает информацию об именах колонок для всех свойств, названия таблицы, ключевом свойстве. В EF Core при преобразовании свойства производится маппинг к соответствующей колонке (разве что вы не укажете другую логику маппинга). Также считается, что если в вашем классе вашей сущности есть свойство Id или SurveyId, это будет считаться свойством-ключом (опять же, если вы не укажете обратное). Так что мне удалось избежать написания около 1000 строк лишнего кода, что достаточно круто.   Большинство из оставшихся нюансов маппинга могут быть настроены через аннотации, композитные ключи и так далее.   Изменения в API Здесь также есть целая серия замечательных изменений. К примеру, для конфигурирования «иностранных» ключей мы писали следующий код: Однако в EF Core метод HasRequired() заменился на HasOne(). Также раньше для тестов приходилось использовать context.Database.Create() и context.Database.Delete(), которые в EF Core были заменены на context.Database.EnsureCreated() и context.Database.EnsureDeleted().   Наложение Немного больше усилий пришлось приложить, чтобы настроить кастомную работу со значениями типа DateTime. Приложение всегда сохраняет значения типа DateTime в базе как Utc, но когда EF читает это, указанный тип не распознается, таким образом он маркируется как DateTimeKind.Unspecified, что в последствии может приводить к нежелательным последствиям. В рамках предыдущей версии EF я использовал возможности фичи – Intersection, которая, увы, больше не доступна в полной мере в раках EF Core. Впрочем, я смог решить проблему при помощи использования инструмента EntityMaterializerSource.   Лично меня сводит с ума то, что ни одна версия Entity Framework – технологии не поддерживает в нормальном виде работу с UTC – форматом. Lazy Loading Это было наибольшее разочарование: EF Core не поддерживает Lazy Loading. Да, в грядущей версии EF 2.1 эта опция должна появиться, но на данный момент решения не существует. В свое время я написал немного горькой правды о производительности Entity Framework, потому использование возможностей Lazy Loading было бы разумным решением. Отследить правильность работы с базой во время построения приложения невозможно. К счастью, при помощи некоторых тестов мне удалось вовремя заметить, что EF Core не использовал возможности Lazy Loading, но представьте себе, что было бы, если бы я этого не заметил и выпустил приложение в продакшн. Конечно, решение использовать Eager Loading вместо Lazy Loading не стало концом света, но оно вынудило писать большее количество тестов, усложнило код (в основном из-за использования вложенных Include() и ThenInclude() - конструкций) и слегка замедлило работу. Возможно, с релизом EF Core 2.1 я все же верну все так, как было. Конфигурация В то время, как .NET Framework хранит все записи о конфигурации в виде xml в app.config / web.config – файлах, .NET Core использует appsettings.json. Лично мне это понравилось, но вместе с этим мне пришлось внести некоторые изменения. Хостинг на IIS Оригинальный веб-сайт Explorer развернут под IIS. ASP.NET Core использует Kestrel, который запускается в качестве отдельного от IIS – процесса. Вам необходимо установить .NET Core Windows Server Hosting Bundle, что позволяет Kestrel непосредственно работать с кодом, а IIS – отвечать за безопасность и некоторые задачи администрирования. Также необходимо настроить пул приложения для запуска неуправляемого кода. К несчастью, деплой подобного в продакшн – сложный и трудоемкий процесс. Пришлось ждать помощи от дружественно настроенного сисадмина. Упс. Вердикт По сути, я не встретил ничего особо страшного. Только парочку незначительных багов, каждый из которых потребовал немного времени на устранение. Для отслеживания подобных багов я советую использовать Portability Analyzer, который значительно упростит вам работу. Я портировал небольшое приложение – всего лишь 5 проектов с несколькими десятками тысяч строчек кода. Если я буду делать что-то подобное вновь, весь процесс должен занять у меня намного меньше времени, чем пара дней. А в целом перед портированием больших приложений я все же советую пока попрактиковаться на маленьких. Вообще, если говорить о целесообразности перехода на стандарт .NET Core, я был вынужден это сделать только потому, что нам предстоит взаимодействовать с другими приложениями этого же стандарта. А так, безусловно, новая технология ASP.NET Core заслуживает своего внимания. Автор перевода: Евгений Лукашук Источник

Я работал с .NET-платформой на протяжении 5 лет – как в плане профессиональной необходимости в качестве бек-енд разработчика и архитектора, так и в плане определенных личных задач - таких как открытые и закрытые сторонние проекты. После нескольких лет работы с экосистемой PHP и имея солидный стаж в плане Java, я пришел к выводу, что язык C# для меня представляет, пожалуй, наибольший интерес – благодаря своему удобству и эффективности. Этот язык комплексный, тщательно продуманный и лично для меня в работе с C# лучшую среду программирования, нежели Visual Studio, человечество еще не изобрело. Более того, ASP.NET уже содержит в себе все, что необходимо веб-разработчику, не требуя установки дополнительных фрейморков и библиотек. Единственное, что меня не очень устраивало в плане .NET-системы, это ее «закрытость» и использование преимущественно Microsoft-платформы (хотя и существуют специальные Mono, которые позволяют в качестве альтернативы запускать шарп-проекты и под Linux, но достигается это ценой утраты целого ряда полезных фичей). По этой причине я обратил свое внимание на Node.JS, хотя мои коллеги называли JavaScript бесполезным языком, а Node.JS – хламом. Я был очарован однопоточной каллбэк-системой, я наслаждался, создавая REST API, используя ExpressJS. Но затем Microsoft выпустила кроссплатформенную технологию ASP.NET Core, и я призадумался, что же и когда стоит использовать. После чего я решил собрать как можно больше информации касательно возможностей и реализации тех или иных фичей двух технологий, после чего выбрал для себя, по моему мнению, наиболее удобную технологию, в рамках которой и развернул свой новый проект. Надеюсь, эта публикация вам тоже поможет прийти к определенному решению. Модель обработки запроса Node.JS Node.JS успел зарекомендовать себя как однопоточный обработчик запросов. Что это значит? Это значит, что вместо обработки каждого поступившего http-запроса внутри отдельного потока или процесса (наподобие Apache), обработка производится внутри одного потока. Подобный подход делает обработку запросов однопоточной, тогда как в Apachi\PHP обработка является многопоточной. Однако, что касательно Node.JS, здесь преимущество заключается в асинхронной работе системного ввода-вывода, которое, соответственно, не блокирует требуемый поток. Операция ввода\вывода производится в рамках отдельного потока, в то время как основной продолжает свою работу. Как только вторичный поток завершает свою работу, вызывается callback, который, соответственно, передает в контекст основного потока результат. С одной стороны, использование подобного подхода прекрасно подходит для приложений, интенсивно работающих с вводом\выводом. С другой стороны, появляется вероятность так называемого «ада обратных вызовов», который провялятся в цикличной сложности кода. Будем надеяться, что новая версия введёт в обиход полноценные async\await. Однопоточная модель обработки запросов Node.JS может быть сгруппирована при помощи использования нативной кластеризации, Nginx или PM2. ASP.NET (синхронный) Исторически так сложилось, что обработка запросов ASP.NET MVC (или Web Api) производится подобно Apache / PHP: каждый запрос обрабатывается внутри своего собственного потока пула потоков. И каждая команда ввода-вывода производится синхронно внутри каждого из потоков. В контексте жесткой работы с вводом-выводом подобный подход, конечно, менее удобный, если сравнивать со схемой Node.JS. Хвала Небесам, .NET Framework 4.5 вводит в C# async\await, что также исправляет сложившуюся ситуацию. ASP.NET Core (асинхронный) Паттерн async\await позволяет в полной мере ощутить все прелести асинхронного программирования. Действительно, теперь появилась возможность указать каждый обработчик запросов как асинхронный, благодаря чему работа с системой ввода-вывода будет производиться в контексте своего потока. Это позволит не блокировать основной поток. Подобная модель на базе Task`ов позволяет использовать обратные вызовы, ощутить все прелести асинхронности и прочее. .NET Core часто применяет паттерн async\await при интенсивной работе с системой ввода-вывода.   Async\await Node.JS VS Async\await ASP.NET Core Пример кода Node.JS для асинхронного запроса в базу данных: Пример того же кода на ASP.NET Core (фрагмент класса Startup):   Разница между двумя моделями в том, что ASP.NET Core способен обрабатывать большее количество запросов благодаря своей дефолтной параллельности. В то же время переключение между асинхронными потоками может занимать время в случае использования большого количества общих для многих потоков переменных. В такой ситуации все же Node.JS будет быстрее.   Много современных языков программирования, вроде того же C#, реализуют асинхронный ввод-вывод, который часто недооценен сообществом Node.JS-разработчиков, но который может приводить к приятным неожиданностям. В этом случае Node.JS в значительно меньшей мере технологичный, если сравнивать его с ASP.NET Core. Язык программирования Особенности и безопасность Вращаться в среде C#-разработчиков – значит выслушать множество критики в адрес динамической типизации и удивительных булевых преобразований JavaScript. Впрочем, эта критика является обоснованной, если учитывать, что JavaScript был разработан всего за 10 дней для динамического контента HTML.   С другой стороны, с того времени язык очень даже «вырос», и новая спецификация привносит такие фичи, как: Классы Новые идентификаторы (const, let), повышающие надежность кода Указательные функции Интерполяцию строк Генераторы Элементы рефлексии Впрочем, C# все равно остается намного более мощным языком программирования, ибо все вышеперечисленное – всего лишь небольшая часть того, чем может похвастаться строго-типизированный объектно-ориентированный язык программирования. Мне кажется, что для C# лучшей среды работы, нежели Visual Studio, просто не найти. Однако, если учитывать рост спроса на рынок микросервисов, большинство из особенностей подобных гигантов здесь не найдут свое применение. Изучение Если вы раньше работали с классической MVC-архитектурой, переход на Node.JS \ Express затребует некоторое время, чтобы привыкнуть. Некоторые же вещи могут вообще оказаться в новинку. Также нужно будет время для того, чтобы «переварить» событийно-ориентированную парадигму Node.JS. Что действительно может показаться запутанным впервые при работе со средними или большими приложениями, так это паттерны рефакторинга кода и, собственно говоря, архитектура кода. Так как функциональность Express.js очень гибкая, выбор «правильной» архитектуры и файловой структуры может быть затруднительным. С другой стороны, для создания качественного приложения без этого – никак. Что же касается ASP.NET (Core) MVC / WebApi, то тут уже предоставляется готовая файловая структура. Да, разработчик может применить немного «креативности» при создании бизнес-логики и слоя для работы с базой, но предопределенность архитектуры упрощает разработку. Однако, в случае с маленькими приложениями, JS-платформа более предпочтительна, так как позволяет написать сайт-визитку с использованием одного лишь js-файла и одного лишь package.json. Продуктивность Я обнаружил, что написание простого кода является более быстрым при использовании Node.JS. Причина в том, что простые приложения тут проявляют большую «гибкость». Также возникают вопросы касательно типизации языка, так как в некоторых случаях оказывается, что динамическая типизация является скорее плюсом, чем минусом. С другой стороны, я заметил, что при написании объемного кода, более читабельным он оказывается при работе с C#, чем с JavaScript. Думаю, причина этому – строгие ооп-парадигмы. Что касается отладки и юнит-тестирования, тут C# / Visual Studio также показывают лучшую продуктивность, хотя и сказать, что JavaScript совместно с Visual Studio Code пасет задних, нельзя. Время построения маленьких js-приложений также меньше. Екосистема В этом плане две технологии отличаются больше всего. Node.JS обязана своим развитием в основном сообществу, которое и разработало для неё большее количество существующих популярных библиотек. С одной стороны, вы чувствуете себя очень свободно в выборе модулей для разработки. С другой же, внезапное обновление одного из пакетов, отсутствие надлежащей проверки на ошибки и стабильность, в некоторых случаях могут легко привести к обвалу всего приложения. ASP.NET Core технология разработана проверенной командой профессионалов из Microsoft. И она предоставляет абсолютно все, что необходимо разработчику веб-приложений любых направлений. Кроме того, сторонние библиотеки также качественно выполнены и разработаны другими крупными проверенными компаниями. Один из многочисленных примеров – ORM-инструменты. Entity Framework, официальный инструментарий для работы с базой данных, предоставляет абсолютно все, что необходимо разработчику. Публикация и запуск А вот это та область, где Node.JS, без сомнения, лидирует. Технология является открытой, кросс-платформенной, поддерживает докеризацию. Это значит, что вы запросто сможете запустить свое приложение под такими платформами: На собственном Linux, Windows или Mac-сервере. Все, что для этого нужно – это движок Node.JS и реверсивный прокси-сервер (наиболее популярный – Nginx). Докер-контейнер. Большинство PaaS-провайдеров (AWS, Google App Engine, Azure, Heroku, …) Сервис Now, который позволяет провести запуск Node.JS-приложения в одну строчку без предварительной конфигурации. Также есть много подходящих CI & CD – платформ. Что же в случае ASP.NET-стека, тут все обстоит несколько печальнее. Хотя и ASP.NET Core также кросс-платформенная, количество сервисов для публикации несоизмеримо меньшее. Вот какие хостинги я знаю на данный момент: Собственный Windows-сервер с классическим IIS. Собственный Linux-сервер с реверсивным прокси. Докер-контейнер под Windows. Работает отлично, но занимает много места. Некоторые облачные сервисы PaaS. В основном, Azure, но есть также некоторые неофициальные билды Heroku. Заключение Node.JS обладает асинхронной событийно-ориентированной моделью обработки запросов, которая не очень то и уступает многопоточной async\await модели ASP.NET. Производительность Node.JS – приложений не всегда лучше, чем ASP.NET Core. Можно сказать, она даже хуже. Язык JavaScript не так уж и плох (и становится лучше!). А использование его вместе с Node.JS может дать приятный результат. ASP.NET (Core) лучше всего подходит для объемных приложений и предоставляет все необходимые разработчику инструменты высшего качества. Для микро- или среднеразмерных сервисов Node.JS предоставляет широкие возможности в плане публикации. И, как всегда, не существует одного лучшего инструмента «на все случаи жизни». Попробуйте доступные и подберите для себя тот, который лучше всего отвечает вашим требованиям. Автор перевода: Евгений Лукашук Источник

Прошло много времени с момента релиза ASP.NET Core 1.0. Затем появились версии 1.1, 2.0… В общем и целом серверные компоненты и технология оказались достаточно качественными, в них было замечено всего лишь несколько багов. Кроме того, начиная с вышеупомянутой версии 1.1, было добавлено бессчётное множество различных полезных примочек к Entity Framework Core и самой ASP.NET Core. Помимо прочего, стоит также отметить радикальные отличия в структуре проектов, которые могут показаться слегка непривычными, но являются жизненно необходимыми для взаимодействия проектов .Net Core с другими типами проектов. Но ожиданиям качественного инструмента пришел конец. Произошел релиз Visual Studio 2017, и она успела зарекомендовать себя как достаточно стабильная версия. К тому же я без проблем сумел перенести мои проекты на базе project.json в новый формат файлов MSBuild без всяких проблем. Помимо прочего, стоит также отметить целую серию приятных улучшений стандартной среды языка .NET. Мы долго ждали и дождались – наконец-то стандарт .NET Core (вместе с технологией ASP.NET Core) успешно захватывает IT-рынок и обладает целым рядом полезных инструментов для разработки. Если вы из компании, которая от стольких лет ожидания успела натереть себе мозоль – определенно, вам есть чему радоваться. Итак, ASP.NET Core сейчас уже на полках. Так в каких случаях нам стоит забыть про старый добрый ASP.NET и опробовать его кроссплатформенную версию? Позволю себе поделиться мнением. Новые проекты Если вы начинаете разработку нового проекта с использованием MVC-подхода и/или Web API, вам определенно нужно обратить свое внимание на ASP.NET Core. Технология содержит в себе целую серию значительных улучшений, которые заметно отличают ее от предшественницы. Помимо прочего, она также может похвастаться первоклассной системой внедрения зависимостей. ASP.NET Core также обладает специальными tag-helper`ами. Используя сервис TestServer, вы запросто сумеете производить локальные тесты прямо на свое ПК (забудьте про падения через неверную конфигурация фаервола). Web API теперь внедрены в ASP.NET Core MVC, потому теперь нет никакой необходимости использовать сторонние библиотеки с кучей дублирующих компонентов. Также скорость работы значительно выше, плюс, помимо прочего, арсенал может похвастаться значительно большим количеством опций, нежели MVC5/WebAPI2, который в значительной мере привязан к IIS. Но что, если проект имеет среди зависимостей сторонние библиотеки (собственные или чьи-то еще), которые требуют полноценной среды .NET Framework, не включенной в .NET Core? Нет никаких проблем. При желании в ASP.NET Core можно включить полноценный .NET Framework. Желаете использовать ваш Entity Framework 6 или NHibernate для работы с данными? Да ради Бога. Все прекрасно будет работать и в ASP.NET Core. Единственное, что вы от этого утратите – это кроссплатформенность, ибо эти сервисы могут быть запущены только в рамках Windows-сервера. У меня нет времени переучивать команду на ASP.NET Core! На счастье, переход на новую платформу не займет много времени, если ваша команда уже знакома с ASP.NET MVC и/или Web API. Концепция Core – использовать все, что было раньше, но значительно лучше. Контроллеры и представления никуда не делись. Представления все еще используют Razor. Маршрутизация по сути своей осталась прежней – она даже стала немного проще. Фильтры также особо не изменились, а Web API добавили своего удобства в использовании (так как они были интегрированы в MVC). Конечно, отличия все же есть, но это не критично. Несколько новых вещей, вроде того, как запускается приложение или как работает middleware, выучить придется, но в целом опыт работы на предыдущей ASP.NET Core MVC тут будет решать очень многое. Я хочу поместить приложение в контейнер на Linux! Тогда вы можете желать только ASP.NET Core. Вы не сможете использовать библиотеки из среды .NET Framework, но что касательно стандартных компонентов .NET Core – полный вперед. И да, вы также можете помещать свои приложения под Azure на Linux. Судьба приложений на ASP.NET MVC 5 и/или Web API 2 Предугадать тут что-либо конкретное будет несколько затруднительно. Если эти приложения работают и запускаются без проблем, не думаю, что необходимость переходить под ASP.NET Core такая уж  срочная. Однако, несколько причин, по которым  стоит интегрировать подобные программы под ASP.NET Core, все же есть: Сама поддержка. Если вы бы хотели деплоить приложение и его сервер вместе, без привязки к IIS – Core, – это однозначно ваш выбор. Поддержка различных платформ. Порой использование Windows-ориентированных серверов может быть дороже прочих других. Возможно, вы могли слышать об поддержке контейнеров, Докера и так далее. Core все это поддерживает – причем на очень даже приличном уровне. Множественные приложения. Приходилось ли вам запускать несколько экземпляров приложения на одной и той же машине? ASP.NET Core позволит это делать значительно удобнее и эффективнее, нежели традиционный ASP.NET. Тестирование и Domain-Driven Design (DDD). Если ваша команда следует этому подходу, пишет тестируемое программное обеспечение, то ASP.NET Core (и Entity Framework Core) привнесёт целый ряд полезных фич, которые значительно могут упростить жизнь. Программы Web Forms         Если ваше приложение базируется на веб-формах, возможно, вам лучше всего будет оставаться на ASP.NET. Microsoft активно инвестирует в эту технологию. Существует множество способов улучшить качество кода, используя внедрение зависимостей и прочее. Но смена платформы на ASP.NET Core MVC будет такой же «болезненной», как и переход на ASP.NET MVC 5,4,3,2,1. Что хуже, используя MVC 5, вы можете запускать страницы отдельно друг от друга, но проделать подобное с ASP.NET Core не представляется возможным. Лично я могу посоветовать оставаться на веб-формах до тех пор, пока приложение не потребует полноценной замены. В плане нагрузки на данные, потребовалось бы применить стиль SPA-приложений со значительно большим количеством клиентского кода и фрейморков типа Angular 2, или React. Другие размышления Хотя Visual Studio – прекрасный инструмент для разработки приложений, эта среда не бесплатная (за исключением комьнити-версии). Помимо прочего, она Windows-ориентированная (да, есть VS для MacOS, но это совершенно другое приложение). Если же студия для вас по причине цены или размеров неприемлема, .NET Core будет воистину полезным приобретением. Вы можете на MacOS, Linux (и, разумеется, под Windows) работать в Visual Studio Code! Подобным образом, если ваши приложения больше ориентированы на клиентскую часть, ASP.NET Core порадует более облегченными размерами. В то время, как фронтендеры превозносят NodeJS как быструю технологию (и ее возможность исполнять js-код на сервере), ASP.NET Core может также исполнять Node.JS на сервере (и вы также можете работать под JS на сервере, если вам захочется). Используя TechEmpower, ASP.NET Core, развернутый с использованием Kestrel, может обрабатывать до 1 миллиона запросов за секунду на том же ПК и в рамках того же приложения, в то время, как NodeJS обрабатывает всего около 175 тысяч в секунду. Подведем итоги Безусловно, ваш опыт и ваше мнение может сильно отличаться от моего, потому вопрос о том, стоит ли переходить на ASP.NET Core для некоторых может остаться открытым. И, конечно, ASP.NET Core далеко не единственная технология, используя которую вы будете создавать свое следующее веб-приложение. Однако, тема этой статьи как раз-таки ASP.NET Core, с которым мне приходилось долго проработать. К тому же, написано очень много официальной документации на официальном сайте Microsoft. Я не советую переходить на ASP.NET Core лишь потому, что он такой новый и весь из себя красивый. Решение перейти должно быть тщательно взвешенным и подкрепленным весомыми аргументами, которые я постарался привести в своей статье. Что дальше? Разработка ASP.NET Core продолжается. Уверен, версия 2.0 – далеко не последняя! Было бы неплохо взглянуть на обновленный SignalR и новую функциональность разор-страниц. Автор перевода: Евгений Лукашук Оригинал статьи

Я работал с .NET Core около года и сейчас могу сказать, что был очень впечатлен. Поскольку наша компания создает приложения для разработчиков, которые базируются на .NET Core, я ощущаю нас причастными к тому, что сейчас происходит. Каждый день мы общаемся с клиентами, которые уже используют .NET Core в своих разработках. .NET Core быстро завоевывает популярность, и я уже предсказываю огромную потребность в разработчиках на C# и .NET Core в 2018 году. Согласно индексу программирования TIOBE, C# уже входит в пятерку наиболее популярных языков программирования. 6 вещей, которые стоит знать о C# и .NET Core Узнайте, почему .NET Core возводит C# в топ списка наиболее популярных языков программирования. 1) Простота в изучении Если вы уже работали с С, Java или даже JavaScript, синтаксис C# покажется Вам довольно знакомым. Сам синтаксис достаточно прост в понимании и чтении. Исходя из индекса TIOBE, приведенного выше, уже сейчас большинство разработчиков могут легко перейти с Java или C. В сети существует много онлайн-ресурсов для изучения C#. Большинство из них – бесплатные, другие же можно использовать за умеренную плату. Pluralsight – Отличный обучающий контент за доступную цену Microsoft Virtual Academy – Бесплатные видео и оценивание Microsoft Getting Started with C# - Бесплатные интерактивные туториалы 2) Современные возможности языка .NET существует на протяжении длительного времени и за последние 15 лет достаточно сильно преобразился и улучшился. На протяжении лет я отмечал такие прекрасные нововведения как MVC, обобщения, LINQ, async/await операторы и многое другое. Как человеку, который лично посвятил себя изучению языка, я рад наблюдать, как он модернизируется. Многое претерпело изменения с появлением .NET Core. Взять тому примером стек технологий ASP.NET. Все эти 15 лет язык C# был с нами, и он продолжает совершенствоваться. Вот некоторые наиболее примечательные особенности: Строгая типизация Качественные библиотеки классов Асинхронное программирование – шаблон async/await Сборка мусора, автоматическое управление памятью LINQ – интегрированный язык запросов Обобщения – примером List<T>, Dictionary<T, T> Управление пакетами Общие бинарные файлы для разных платформ и фреймворков Простота в использовании фреймворков для создания MVC веб-приложений и REST API. 3) Универсальность: веб, мобильные, серверные, настольные приложения Одним из наиболее значимых плюсов C# в частности и .NET в целом, я считаю, является его многогранность. Я могу писать программы для ПК, вести веб-разработку, создавать фоновые сервисы или даже мобильные приложения (спасибо Xamarin!). Кроме того, все, что мне нужно знать, дабы скомпоновать все UI-коды вместе (чего я все же стараюсь избегать), это, кроме C#, всего лишь немного JavaScript’а (+ TypeScript). Шаблоны ASP.NET Core в свою очередь при создании клиентских библиотек даже используют макеты Бутстрапа и npm. Универсальность языка - довольно весомый плюс, так как ваш вклад в его изучение может найти применение в широком спектре возможностей. Ваши навыки очень мультиплатформенные. Если пожелаете, Вы можете легко «перескочить» с разработки веб-приложений на мобильные. Пожалуй, это уникальное отличие от других языков, заточенных только под серверную часть. Не стоит забывать о первоклассной поддержке Microsoft Azure. Нужно задеплоить проект на облако? Нет ничего проще: сия операция осуществляется всего лишь в пару кликов. Поддержка Docker-контейнеров также присутствует, что значительно упрощает деплой приложений на AWS или другие хостинги на Ваше усмотрение. 4) Качественные инструменты разработчика Visual Studio всегда считалась одной из лучших сред разработки. Это прекрасный редактор кода, поддерживающий такие фичи, как компиляцию, отладку, профилирование, git-репозиторий, юнит-тестирование и многое другое. Плюс, за вами всегда остается возможность писать коды для .NET Core в любом текстовом редакторе в виде обычных текстовых файлов. Вы также можете использовать Visual Studio Code на любой ОС в качестве отличного редактора кода. Даже те из нас, кто никогда не желает расставаться с этим Vim или Emacs, могут вести разработку на C#. Можно также установить плагины для Visual Studio и добавлять свои «горячие клавиши». Вся экосистема .NET изобилует прекрасными инструментами. К примеру, вряд ли я смогу представить жизнь без Resharper`а или JetBrains. Существуют десятки классных инструментов, включая смеси открытого кода и коммерческих продуктов. 5) Обобщение навыков .NET обладает очень хорошим набором базовых библиотек. В отличие от Node.js, такие простые строковые функции, как LeftPad(), уже встроены. Подобное разнообразие стандартных библиотек значительно уменьшает потребность в сторонних пакетах. Также благодаря вмешательству Microsoft, мы можем использовать такие технологии, как JSON.NET и прочее. Microsoft обеспечивает качественный набор шаблонов и их реализаций на .NET. К примеру, сервис для работы с данными (Entity Framework) и MVC уже встроены. Большинство разработчиков именно ими и пользуется. Подобный подход значительно упрощает взаимодействие между командами и ускоряет понимание, как проект работает. Благодаря этому, Ваши знания и навыки становятся более универсальными. 6) Код .NET Core в свободном доступе Одним из наиболее значимых событий, которое когда-либо происходило на .NET, является публикация исходного кода. Теперь каждый на GitHub’е может просматривать, вносить правки и дополнять его. Пожалуй, большинство людей даже никогда не думали о том, что подобное может когда-либо произойти. Как разработчику, время от времени Вам необходимо «заглядывать за ширму», дабы понимать, как на самом деле работает код. К примеру, раньше я мог только гадать, закрывает ли вызов метода Dispose() на базе данных соединение или нет. Если же Вы можете заглянуть в исходный код, большинство схожих вопросов отпадает. Даже если Вы не дополняете исходники, так или иначе Вы получаете пользу от тех, кто это делает. Проблемы и возможные улучшения быстро обсуждаются, реализуются и публикуются в свободный доступ. Прошли теперь те дни, когда на ожидание сколь-либо значительных улучшений или незначительных правок уходили годы. Заключение На протяжении лет я читал о программистах-полиглотах и о новых классных языках. В разное время люди писали на Ruby, Python, Scala, Go, Node.js, Swift и прочем. Приятно видеть, что Microsoft, сообщество сделали с .NET Core и как он вознесся в ранг первоклассной платформы. Я даже портировал .NET приложения на Maрc! Проблемой многих существующих языков программирования является то, что они узкоспециализированы. Ruby и PHP прекрасно подходят для веб-приложений. Swift или Objective C лучшего всего использовать для IOS или MacOS. Если нужно написать серверное приложение, можно использовать Python, Java и так далее. Пожалуй, кроме C#, только JavaScript и Java могут считаться языками широкого профиля. Мне бы было трудно применить навыки для решения различных задач, если бы я был вынужден работать со многими языками программирования. Это ограничивает возможности. Мне нравится универсальность C#, нравится то, что его можно использовать для разных типов приложений. Теперь, поскольку .NET Core так же подходит и для MacOS и Linux, больше нет никаких лимитов на его применение. Автор перевода: Евгений Лукашук Источник

Что такое Dependency Injection (внедрение зависимостей) на языке C#? Как это работает, типы внедрения зависимостей в C# и многое другое. В недавнем сообщении в блоге мы говорили о том, что язык C# в частности и виртуальная машина .NET в целом являются технологиями высокого уровня. Если вы планируете писать код на C#, внедрение зависимостей - это лишь одна из многих вещей, о которых вы должны знать. Продолжайте читать пример внедрения зависимостей C#, чтобы вы могли использовать его в своих интересах в своем следующем проекте. Определение Dependency Injection в C# Если вы более подробно рассмотрите Dependency Injection (DI), то увидите, что это паттерн проектирования программного обеспечения, который позволяет разрабатывать слабосвязанный код. Через DI вы можете уменьшить «жесткость» связи между программными компонентами. Внедрение зависимостей также известно как Inversion-of-Control (инверсия управления), которая упрощает модульное тестирование. Крайне важно сделать шаг назад к основам проектирования объектно-ориентированного приложения, где основным аспектом проектирования является «слабая связь». Это означает, что объекты имеют только столько зависимостей, сколько необходимо для выполнения своих заданий, а число зависимостей должно быть ограничено. Кроме того, зависимости объекта должны быть от интерфейсов, а не от конкретных объектов. Что такое конкретный объект? Это любой объект, созданный с помощью ключевого слова «new». Благодаря «слабому связыванию» вы упрощаете поддержку программного продукта и даёте большую возможность повторного использования. Кроме того, вы можете использовать так называемые Mock-объекты, предназначенные для замены дорогостоящих сервисов, таких как socket-communicator. Существует три типа DI: 1) Constructor Injection 2) Setter Injection 3) Method Injection Поскольку DI используется для упрощения сопровождения кода, он использует паттерн с объектом-конструктором для инициализации объектов и предоставления необходимых зависимостей объекту. Как вы можете видеть, теперь вы можете «внедрить» зависимость снаружи класса. Как работает Dependency Injection в C# Чтобы проиллюстрировать, что вашему классу Client необходимо использовать компонент класса Service, лучшего всего, чтобы ваш клиентский класс «знал» об интерфейсе IService вместо класса Service. Благодаря этому вы можете изменить реализацию класса Service столько раз, сколько хотите, не нарушая хост-кода. Полезно понимать Принцип Инверсии Зависимостей (Dependency Inversion Principle), который помогает нам при написании слабо связанных классов. Определение: Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Как вы внедряете зависимость между двумя модулями? Через инверсию управления. Это фактический механизм, который вы можете использовать для создания модулей более высокого уровня, зависящих от абстракций. Вы должны инвертировать элемент управления, чтобы следовать принципу инверсии зависимостей. В результате ваши высокоуровневые модули больше не зависят от конкретных низкоуровневых реализаций. Давайте немного погрузимся в три типа Dependency Injection: Constructor Injection Основная предпосылка здесь заключается в том, что объект не имеет значений по умолчанию или одного конструктора. Для создания объекта необходимо задать определенные значения во время создания. Вкратце, Constructor Injection использует параметры для внедрения зависимостей. Это самый распространенный вид DI, который выполняется путем предоставления зависимости через конструктор класса при создании экземпляра этого класса. Кроме того, внедряемый компонент можно использовать в любом месте внутри класса. Хотя он должен использоваться, когда сия зависимость действительно необходима для работы класса. К тому же Constructor Injection используется в наиболее распространенном сценарии, когда классу требуется одна или несколько зависимостей. Вот несколько преимуществ Constructor Injection: • Инициирует контракт сильной зависимости. • Он поддерживает тестирование. • Можно сделать неизменным. Setter Injection Его также называют Property Injection (внедрение свойств). Setter Injection позволяет нам создавать затратные ресурсы и сервисы только по мере необходимости и как можно позже. Кроме того, он не требует предварительной проводки всего графика зависимостей. Единственная проблема - трудно определить, какие зависимости требуются. Хотя это не требует добавления или изменения конструкторов. К тому же перед использованием вам нужно будет проверить значение null. Method Injection Это наименее распространённый патерн, он используется только в крайних случаях. Как указано в названии, Method Injection вводит зависимость в метод, который будет ее использовать. В результате это удобно, когда для всего класса нужен только один метод, а не зависимость. Преимущества Dependency Injection C# С помощью DI вы можете вводить дополнительный код между зависимостями. Чтобы проиллюстрировать это, вы можете использовать Constructor Injection, чтобы предоставить объекту его зависимости. Если у вас есть класс с 10 методами, которые не имеют зависимостей, но вы хотите добавить новый метод с зависимостью, вы можете изменить конструктор для использования Constructor Injection. С другой стороны, вы можете просто добавить новый конструктор, который будет принимает зависимость. Тем не менее если зависимость нежелательна, вы можете использовать Setter Injection, поскольку она позволяет создавать дорогостоящие ресурсы только тогда, когда это необходимо. Как вы можете видеть, DI делает код надежным, поддерживаемым, многоразовым и читаемым. Источник