Введение Когда в 2008 году компания Microsoft придумала ASP.NET MVC, у многих возник вопрос: «Зачем нужна ещё одна технология ASP.NET?». Многие считают, что ASP.NET MVC не обязательно использовать, заменив на Web Forms ASP.NET. Однако, это неправда. Оба имеют свои плюсы и минусы. В статье мы рассмотрим преимущества этих двух технологий – и каждый сможет определиться, какая из них ему ближе. Мы также объясним понятия ASP.NET, ASP.NET Web Forms, MVC, ASP.NET MVC. Опытным разработчикам в ASP.NET MVC данная статья поможет переосмыслить свои концепции. Web-технологии Когда речь идёт о web-технологиях, на ум приходит классический ASP, PHP, JSP, ROR, ASP.NET Web Forms, ASP.NET MVC и другое. Классический ASP - web-технология, созданная корпорацией Microsoft. У классического ASP было два недостатка: слишком большой, неудобный исходный код и ненадёжность. К примеру, у Вас есть текстовые поля и кнопка. Нажав на кнопку, можно проверить данные, хранящиеся на сервере. Успешная проверка означает, что данные хранятся в базе, а в обратном случае выведется определённое сообщение об ошибке. В чём проблема такого сценария? Вам нужно совершить много действий. Приложение ASP.NET ASP.NET – приложение Microsoft, его структура построена на всеязыковой среде выполнения для построения динамических веб-сайтов – для создания можно использовать такие языки: C#, VB.NET и другие. ASP.NET поддерживает две модели: Web Forms и ASP.NET MVC. ASP.NET Web Forms Корпорация Microsoft первой вывела ASP.NET Web Forms из ASP, таким образом они решили множество проблем путём создания высокого уровня абстрагирования. Web Forms включает в себя postback (постит данные на заданную страницу) и ViewState. И самое интересное в том, что для ASP.NET Web Forms не требуется написания вручную ни единой строчки кода. ASP.NET 4.0 В ASP.NET 4.0 придумали, как преодолеть некоторые трудности: появилась возможность отключать и контролировать размер ViewState; с URL routing можно предоставить собственный URL вместо физического пути; в ASP.NET 4.0 мы имеем лучший контроль над ID элементов и, таким образом, интеграция с платформой JavaScript стала проще. Шаблон MVC MVC – архитектурный шаблон. Многие используют его с Java-технологией. MVC – не новое понятие, созданное Microsoft. Однако, в MVC ASP.NET нужно разобраться. До этого стоит уточнить для себя некоторые определения – в том числе, что такое MVC. Архитектурный шаблон – то, что решает наш вопрос на суб-системном уровне или на коротком уровне модуля. Речь идет о проблеме, связанной с архитектурой проекта. Это говорит о том, как можно разделить системы, а в частности - почему. Создаются библиотеки классов, компоненты, веб-сервисы, чтобы решить данный вопрос. MVC – архитектурный шаблон, позволяющий уловить тонкую связь между input-логикой, бизнес-логикой и UI-логикой. Платформа ASP.NET MVC ASP.NET MVC – еще одна платформа web-приложений от Microsoft. В ней устранены недостатки, имеющие место в предыдущих, подобного типа платформах. Эта платформа построена на всеязыковой среде выполнения (CLR) и полностью основана на MVC-архитектуре. Источник: http://www.codeproject.com/Articles/528117/WebForms-vs-MVC#Visual_in_Web

Автор статьи: Влад Кобылянский, архитектор программного обеспечения, разработчик и консультант по технологиям малого бизнеса (Майами, Флорида).   Вопрос: Что сегодня происходит с PHP фреймворками? В феврале 2017 года я так ответил на этот вопрос: «В основном все крутится вокруг двух PHP фреймворков -  Laravel и Symfony. Особой нужны в использовании CakePHP, Zend, CodeIgniter, Yii и т. д. нет, если вы начинаете новый проект. Только если вы уже знаете эти фрэймворки или у вас в команде есть разработчики которые привыкли работать с ними, тогда причины их использования обоснованы. Когда начинается реальная разработка, вы должны иметь возможность находить инструменты, плагины, ответы на общие проблемы. С сообществами Laravel и Symfony, с постоянным развитием новых «модулей» или функций, не будет ощущения, что вы остались «в стороне». Одни Laracast (даже если вы не работаете в Laravel) чего стоят! Они просто фантастичны. Когда заходит речь об интеграции с iron.io или другими SaaS сервисами, поддержке широкого спектра источников данных или о среде разработки – Laravel и Symfony и их расширения намного более продвинуты. Еще одним достоинством  Lumen, является быстрая разработка и прототипирование API для Laravel. При этом это никак не ограниченно для построения больших приложений.Вообще говоря, сегодня мы определенно видим переход к контейнерной архитектуре, где MVC играет гораздо меньшую роль. Все это касается микросервисов, оркестровки и создания приложений как «функций» (AWS Lambda и подобных сервисов). Возможно, пришло время освежить наши навыки Node/JS и GoLang?»   Хотя я в целом доволен этим ответом, сейчас я думаю, что некоторые моменты пришло время пересмотреть. Прежде чем перейти к таким странным темам, как GoLang, давайте взглянем на тенденции PHP MVC фреймворков. Я бы сказал, что тенденции, которые мы наблюдали в прошлом, остаются. Laravel продвигается вперед, в то время как большинство остальных фреймворков отстает. В популярности Symfony наблюдается небольшой всплеск, вероятно, из-за долгожданного выпуска Symfony 3. Я попробовал более конкретные поиски для сравнения, такие как «CakePHP 3» или «ZF2», однако они не привели к статистически значимым тенденциям. На этот раз я добавил CodeIgniter, потому что он оказалася очень популярным. Я получил ряд вопросов о CodeIgniter. Если коротко, CI сейчас не в конкуренции, потому что это не 100% фреймворк MVC. Иначе, чем организованной коллекцией POPO, я это не назову. Для наглядности представляю вам цитату из руководства CodeIgniter: «CodeIgniter имеет довольно свободный подход к MVC, поскольку не требуются Models. Если вам не нужно дополнительное разделение или вы обнаружите, что поддерживающие Models требуют большей сложности, чем вы хотите, вы можете их проигнорировать и создать свое приложение с помощью Controllers и Views.» Когда дело доходит до построения структуры, я просто не согласен с таким подходом. Возможно, это достойный шаблон (отсюда и популярность CodeIgniter), однако должна быть какая-то дисциплина, навязанная фреймворком, иначе конечный продукт в итоге превращается в беспорядочный спагетти-код, завернутый в какой-то «шаблон». Далее, Symfony 3 привнес некоторые достойные улучшения в разработку и целый ряд новых «фич». Как и многие аналоги PHP, теперь он предлагает микро-фреймворк. ZF3, к примеру, добавил ряд улучшений, таких как поддержка PHP7 (наконец!) и даже стал микро-фреймворком... но, в их руководстве так и говорится: «Для пользователей Zend Framework 2 MVC, различия с ZF3 незначительны...» Я действительно надеялся, что они скажут, что различия есть, что было замечательное архитектурное усовершенствование, замечательные новые модули, которые помогают вам разрабатывать все по-современному. Но, увы, по большей части ZF3 по-прежнему похож на ZF2. Long Story Short Вот как я вижу мир PHP фреймворков сегодня: Symfony или Laravel (выбор зависит от того, какую задачу вам нужно решить) Все остальное Laravel на первом месте. Объем доступной информации, Laracasts, таланты разработчиков во всем мире, простые реализации шаблонов, интегрированные наборы инструментов тестирования, активная реализация записей в форме Eloquent, облегченная версия в Lumen, развитие Homestead (Vagrant) – все перечисленное способствует фреймворку действительно выделяться и для новых, и для опытных разработчиков. Однако модели Eloquent могут стать непослушными и довольно большими по размеру, а сервисов Laravel (не путать с микросервисами) можно создать очень много, и вот тут люди начинают думать о реализации Repository, которому здесь не место. Так родился Monolith. Если вам не нравится активный шаблон записи и вам нужна дополнительная гибкость в репозиториях, или, возможно, вы видите слишком много независимых анонимных функций, тогда используйте Symfony + Doctrine. Рассматриваю ли я Symfony как шлюз для монолитных приложений? В какой-то степени, да. В целом, я бы не назвал это резким изменением с прошлого года. Тем не менее, нам нужно взглянуть на общую картину: правильно разработанное приложение выходит за рамки чистого MVC; речь идет об инфраструктуре, конвейере развертывания, разъединённой архитектуре. Все это может быть достигнуто в стеке MVC, но нужно быть внимательным, чтобы избежать Monolith. Приход микросервисов Раньше я упоминал о распространенности микросервисов и необходимости улучшать навыки GoLang или Node. А в статье о PHP MVC было бы глупо не упомянуть о явно растущем движении к микросервис-ориентированной архитектуре (MOA); и это движение набирает обороты, поверите вы или нет. Хотя эти два понятия не являются взаимоисключающими, не нужно находить параллели между ними, ведь они действительно представляют собой разные философии. В качестве примера, размещение вашего приложения MVC в одном контейнере и MySQL в другом, а затем объединение их вместе, не обязательно представляет собой надлежащую MOA. Это, безусловно, лучший подход, чем пытаться установить MAMP, XAMPP или что-либо еще, чтобы заставить ваш компьютер работать с приложением. Кроме того, это может решить некоторые проблемы, такие как простота запуска локальной среды на разных платформах и, возможно, в некоторых случаях стратегии развертывания, но вы застрянете с монолитным MVC в вашем приложении/контейнере. Уничтожение Monolith Микросервисы – это как раз о «разрушении». В то время как MVC обращается к вашей структуре кода и организации, обеспечивая надежный подход к разделению проблем, эта концепция еще больше расширяется контейнерами/сервисами/MOA. Вместо того, чтобы просто отделять виды (Views) от моделей (Models), вы теперь разделяете каждый «кусок» или логическую единицу вашего приложения на индивидуальную службу, предназначенную для правильной работы с собственными обязанностями. Если у вашего MVC-приложения есть контроллер «Поиск», действия и соответствующие методы модели, то у нас уже есть пример монолитного приложения. Напротив, используя подход MOA, у нас будет сервис для каждого из этих процессов. В качестве примера: Router сервис Request сервис Query сервис DataSource сервис Response сервис Но не все эти «сервисы» являются частью стека MVC? Конечно нет. Они являются строительными блоками нашего Monolith. С MOA каждый сервис работает в рамках собственной среды, а мы, как архитекторы, можем разработать лучший подход к решению конкретного запроса. В качестве примера, если я должен был бы написать службу обработки изображений в среде Laravel, я использовал бы что-то вроде расширения PHP-GD2, что может быть не самым эффективным способом обработки изображений. Служба C++, которая обрабатывает мои запросы в обработке изображений, может быть намного быстрее и определенно более надежной при масштабировании. И мы могли бы сделать вывод службы обработки изображений и отправить ее в службу DataStore, службу CloudStorage и службу Queue Email. Решение этой же задачи с кучей скрытых заданий и, возможно, нескольких отдельных приложений MVC и пользовательских сценариев – это то, как разработчики делали это раньше (2 года назад). Время двигаться вперед. Масштабируемость Здесь возникают проблемы (или заканчиваются, в зависимости от того, куда вы держите курс). С одной стороны, очень сложно масштабировать Monolith: если вы создадите все больше и больше логики в одном и том же наборе MVC, вы застрянете с хорошо структурированным приложением ужасной сложности. С другой стороны, если вы построите тысячу микросервисов на разных языках, как вы будете управлять этим беспорядком? Существуют различные инструменты компоновки контейнеров (например, Kubernetes, Swarm, Mesos), услуги по развертыванию контейнеров (GKE и AWS ECS), однако лишь немногие предприятия используют архитектуру Docker. Есть удачные истории в построении инфраструктуры с использованием Docker или других контейнерных технологий (т. е. GKE). Большинство из этих историй исходят от компаний, которые могут позволить себе тратить ресурсы на архитекторов, дефолтов, администраторов баз данных и инженеров. Тем не менее, сейчас идут бесчисленные дискуссии о том, как развернуть хорошо организованный и элегантный MOA. В любом случае, вы не решите эту проблему самостоятельно, и пока вы не достигнете относительно большого масштаба, эта проблема действительно нуждается в решении. Может быть, сейчас не самое время усердствовать. Золотая середина на сегодняшний день (даже для тех, кто занимается приложениями меньшей сложности или не такими требованиями к трафику) заключается в том, чтобы разгрузить многие типичные сервисы сторонним провайдерам. Почти все доступно сейчас как сервис. Фоновые задания, обработка изображений, аутентификация, аналитика данных, ведение журнала, отправка электронной почты, системы очереди не обязательно должны строиться в одном стеке MVC, а архитектор должен подумать о том, что может быть выгружено в систему SaaS за небольшую ежемесячную стоимость (т.е. поиск Algolia) или, возможно, специально созданную докерную службу, работающую в облачном пространстве, которая выполняет эту обработку изображений. Я думаю, важно, чтобы вы не начали перепроектировать весь проект с начала, не сбрасывать все, что у вас уже есть, а выпускать докеры, где это можно сделать. Существуют способы постепенного развертывания вашего проекта/продукта путем разъединения, изучения узких мест в системе (и т.д.) и последующим применением разделения проблем в этих проблемных областях. Вывод 2017 год принес нам много дискуссий и производственных развертываний, основанных на контейнерах и MOA. Мои размышления о Docker, используя GoLang или Node, не означают, что PHP «умирает» или что-то в этом роде ... Я считаю, что разработчикам нужно оставаться в тренде. Если микросервисы и дальше будут развиваться в том же русле, в котором это происходит сейчас, то почему бы не изучить GoLang? Он идеально подходит (из-за низкой занимаемой площади, скорости и параллельной обработки) для разработки небольших контейнерных приложений. Node и GoLang позволяют создавать небольшие сервисы, которые являются частью более крупного проекта, связывают созданные сервисы и выпускают их как контейнеры Docker, если это необходимо в вашей работе. Тем не менее, все эти передовые решения и языки не уменьшают значимость и востребованность языка PHP. Разработчикам еще нужны будут стеки MVC и работа с  API. MOA пока не помогает решить архитектурные проблемы на стороне frontend, UI или Views, хотя при этом контейнеры помогают нам избежать работы с Monolith на backend. Мы можем создать чрезвычайно надежное backend-приложение, но оно среагирует на JSON, который каким-то образом должен быть представлен в клиентском приложении. Имеет ли значение, если результирующий объект ответа поступает из РНР кода, URL или от модулей принятия решений и обработки, разделенных интерфейсом обмена сообщениями? Это зависит от Ваших потребностей и требований к вашему приложению. Мой совет: в этом году учите Laravel, следите за Docker, GoLang и фокусируйтесь на конвейере развертывания. Продвижение от локального небольшого проекта к продакшену должно быть достаточно плавным, особенно при создании приложений MVC.   Оригинал статьи

Существует несколько причин для создания суперпростых и легких HTTP сервисов, которые еще называются «микросервисами». Нет нужды говорить обо всех операционных и архитектурных преимуществах такого подхода к построению системы, так как это не раз обсуждалось на разных ресурсах. Я хотел бы показать пару техник построения весьма простых и компактных HTTP сервисов на основе ASP.NET Core без использования каких-либо фреймворков и с минимальным разрастанием кода. Предпосылки То, что я буду обсуждать в данной статье, базируется на пакете ASP.NET Core 1.2, который на момент написания еще не был в релизе. Я использую CI, поданную в ASP.NET Core, поэтому мой Nuget.config выглядит таким образом: Когда версия 1.2 добавится в Nuget, этого больше не потребуется. ASP.NET HTTP endpoints без MVC ASP.NET Core позволяет определить HTTP endpoints непосредственно на спецификации OWIN, которая построена вокруг, не используя полномасштабную структуру MVC и ее контроллеры для обработки входящих запросов. Так было с самого начала – вы могли использовать компоненты промежуточного программного обеспечения для обработки входящих HTTP запросов и короткую схему ответа непосредственно клиенту. Во многих проектах на основе профиля ASP.NET Core уже используется такая техника, например, Identity Server 4.  Это не новая концепция – нечто подобное существовало (хотя и в ограниченной форме) в классическом ASP.NET с HTTP модулями и HTTP обработчиками. Позднее, в Web API можно было определить обработчики сообщений для обработки HTTP запросов без необходимости определения контроллеров. И, наконец, в OWIN и в Project Katana это также было возможно через подключение к пользовательским компонентам промежуточного ПО. Другой альтернативой является точное определение пользовательского IRouter и прикрепление от него различных endpoints. Основное различие между этим подходом и подключением пользовательских компонентов промежуточного ПО в том, что маршрутизация сама по себе представляет единое промежуточное ПО. Это также дает нам возможность для гораздо более сложного сопоставления URL шаблона и определения ограничения маршрута – то, что Вам нужно было бы обрабатывать вручную в случае промежуточного программного обеспечения. ASP.NET Core 1.2 скоро представит ряд новых методов расширения на IRouter, которые сделают создание простых и компактных HTTP endpoints еще проще. Станет возможным заполнить более ранние версии ASP.NET Core этой функциональностью путем простого копирования новых расширений в ваш проект. Настройка базы для простого и компактного HTTP API Это project.json для нашего микросервиса. Он содержит только самые базовые пакеты. Мы используем здесь абсолютный минимум: • Kestrel и IIS интеграция выступают в качестве хоста сервера • пакет маршрутизации • пакеты протоколирования и конфигурации Для того, чтобы привести и наш код к абсолютному минимуму, мы можем даже бросить концепцию Startup класса для нашей API установки, и просто писать весь код бэкэнда API в одном файле. Вместо того, чтобы закреплять все в типичные Startup точки расширения, такие как методы Configure() и ConfigureServices(), мы повесим все на WebHostBuilder. WebHostBuilder довольно часто игнорируется разработчиками ASP.NET Core, потому что генерируется шаблоном в качестве точки входа внутри класса Program, и, как правило, нам не нужно даже изменять его – поскольку он по умолчанию указывает на класс Startup, где происходит почти вся работа по настройке и конфигурации. Тем не менее, он также предоставляет аналогичные зацепки, которые есть у Startup, поэтому можно просто определить все непосредственно на WebHostBuilder. Наша базовая API конфигурация приведена ниже. Она еще ничего не делает с точки зрения воздействия HTTP endpoints, но она полностью функциональна со стороны процесса подготовки создания (маршрутизатор подключен), входа в консоль и захвата конфигурации из JSON и переменных окружения. Мне нравится этот подход, поскольку он поразительно краток. Примерно в 20 строках кода мы имеем отличную базу для легкого HTTP API. Естественно, мы могли бы обогатить ее более широкими возможностями по необходимости – например, добавить в наши собственные сервисы или добавить проверку маркера с использованием соответствующих пакетов интеграции из Microsoft.Security или IdetntityServer4. Добавление HTTP endpoints в наше решение Финальный шаг – это добавление HTTP endpoints. Мы сделаем это, используя вышеупомянутый расширяющий метод, который будет представлен в ASP.NET Core 1.2. Для демонстрации нам необходима любая модель и сымитированные данные, чтобы использовать стандартный Contact и примеры ContactRepository. Код ниже запускается в расширяющем методе Configure() на WebHostBuilder, о чем уже было упомянуто ранее. Он показывает HTTP обработчики для получения всех контактов и получения контакта по ID. Этот код должен быть достаточно самостоятельным в описании – мы делегируем справочную операцию в хранилище и затем просто выводим результат в HTTP ответе. Расширяющий метод-маршрутизатор также дает нам доступ к значениям данных маршрута, делая простым управление сложных URI. К тому же, мы можем использовать обычные шаблоны маршрутов ASP.NET Core со всей мощью ограничений, которые очень удобны, например, так как вы и ожидаете, contacts/{id:int} не будут поставлены в соответствие для нецелочисленных ID. Я также помог себе, добавив удобный расширяющий метод для написания ответного потока. Финальный шаг – это добавление в HTTP endpoints изменения состояния серверной части: POST (добавить) новый контакт PUT контакт (изменить существующий) DELETE (удалить) контакт Нам потребуется дополнительный расширяющий метод, чтобы упростить это, потому что необходимо дессерилизовать запрос тела потока в JSON и нам хотелось бы проверить аннотацию данных нашей модели, чтобы гарантировать, что запрос от клиента является валидным. Очевидно, что будет глупо повторять код раз за разом. Этот расширяющий метод приведен ниже и в нем используются JSON.NET и System.ComponentModel.DataAnnotations.Validator. Заметьте, что метод вернет клиенту ‘400 Bad Request’, если модель не окажется валидной. Например, требуемое поле будет пропущено – мы также получим ошибку валидации. Далее показано определение HTTP endpoints: Вот и все – вы можете улучшить этот код, добавив в него, например, удобные методы чтения и выбора значений из RouteDataDictionary. Также не вызовет проблем усиление кода аутентификацией и даже внедрение в него новой авторизационной политики ASP.NET Core. Полный код нашего «микросервиса» (без вспомогательных расширяющих методов, которые, я предполагаю, вы в любом случае захотите собрать воедино и заново использовать) показан ниже – и мне нравится полученный результат. Я считаю, что это весьма привлекательный, лаконичный способ построения простого и компактного API в ASP.NET Core. Исходники доступны на Github. Оригинал статьи тут: http://www.strathweb.com/2017/01/building-microservices-with-asp-net-core-without-mvc/

Введение Microsoft Azure является облачно-вычислительной платформой и инфраструктурой, предоставленной корпорацией Microsoft. Эта платформа выполняет такие функции, как построение, развертывания и управления приложениями и услугами, и они могут быть доступны по всему миру. Azure доступен как Платформа, как сервис (PaaS) и Инфраструктура, как сервис (IaaS). Чтобы сделать развертывание приложения.NET на Microsoft Azure, Visual Studio 2012 и Visual Studio 2013 предоставляет Вам необходимые инструменты. Вы можете загрузить полную версию Visual Studio 2013 года здесь. Чтобы использовать Azure, сначала нужно посетить сайт manage.windowsazure.com и подписаться на эту услугу. Вы также можете получить бесплатную пробную подписку, чтобы начать работу. После входа на портал, на следующем рисунке продемонстрированы некоторые службы/функции, которые можно получить: В этой статье мы будем использовать приложение, созданное с помощью Angular.js, MVC, WEB API для выполнения CRUD-операций. Мы будем публиковать приложения на Azure в качестве веб-сайта. Загрузите исходный код и откройте это приложение в Visual Studio 2013. Создание сервера базы данных с помощью SQL Azure Чтобы успешно запустить веб-сайт, Вы должны развернуть базу данных, используемую нашим веб-сайтом в облаке. Чтобы развернуть базу данных Azure, нужно создать сервер базы данных, используя Azure SQL. Шаг 1: Выберите SQL DATABASES, и Вы увидите страницы базы данных, как показано здесь: Выберите Servers, это позволит создать новую базу данных SQL SERVER. Нажмите кнопку  "CREATE A SQL SERVER DATABASE", ниже появится окно: Введите необходимые данные. После ввода данных выберите галочку в нижнем углу, чтобы создать базу данных сервера: Кликаем на кнопку "MANAGE" внизу страницы, это позволит Вам добавить сервер доступа в правила брандмауэра, так чтоб был получен доступ к приложению. Эти правила добавят IP-адрес вашей машины в правила брандмауэра. Чтоб узнать имя экземпляра сервера базы данных, кликаем по имени базы данных для отображения информационной панели. Прокрутите вниз страницы панели мониторинга для отображения MANAGE URL. Она начинается от https://.database.windows.net. Часть URL после https://, имя экземпляра базы данных. Шаг 2: Чтобы Соединиться с сервером базы данных, скопируйте часть URL после http://, и от локального экземпляра SQL Server, кликаем по Connect на объектном проводнике, и в Connect To Server окно вводит детали базы данных как показано здесь: Это выведет на экран Сервер базы данных Azure SQL экземпляр в объектном проводнике на локальном экземпляре SQL Server. Введите необходимые параметры. SERVICE TIERS позволит выбрать уровень базы данных, таких как BASIC | STANDARD | PREMIUM. Выберите уровень BASIC. Выберите SEERVER как сервер базы данных, его мы создали ранее. Создаваемая база данных будет такая, как показано на изображении: Кликните по кнопке MANAGE внизу страницы, она создаст правило Брандмауэра для того, чтобы установить доступ базы данных: Далее откроется следующая страница, где информация об Администраторе Базы данных обязательна к заполнению: Клик на Log On выведет на экран следующую страницу:  Кликните по “Design”, чтобы составить таблицы, Views и Stored Procedures. Кликаем по “New Table” и создаем список сотрудников, как показано: Введите простые записи в эту таблицу, используя ссылку New Query. Внесение изменений в Web.config файл MVC-приложения Откройте приложения MVC в Visual Studio 2013 и внесите следующие изменения в строку подключения. data source=; initial catalog=Application; user id=; password=; MultipleActiveResultSets=True; App=EntityFramework" "providerName="System.Data.EntityClient" />   (В качестве альтернативы Вы можете запустить Entity Framework в проект, в папку Models для создания строки подключения) Создание Веб-Сайта С Помощью Windows Azure Portal Нажмите кнопку на сайте, чтобы отобразить параметры создания веб-сайта. Нажмите на ссылку CREATE A WEBSITE. Это приведет к появлению следующих вариантов для создания веб-сайта:     Далее Вы можете ввести информацию о URL. Введённый URL уникальный и будет проверен Azure. Если это имя не будет корректное, то URL будет .azurewebsites.net. Центр обработки данных должен быть выбран согласно Вашему выбору. Как только Центр обработки данных выбран, тогда все другие ресурсы, необходимые веб-сайту, например, Базы данных SQL, должны быть размещены в том же Центре обработки данных, так как это поможет в управлении затратами. Как только будет создан Веб-сайт, портал покажет детали:     Чтобы получить детали о веб-сайте, кликните по его имени, ниже будет выведена инструментальная панель на экран, она поможет в управлении и мониторинге веб-сайта.     Чтобы опубликовать наш веб-сайт, созданный с помощью VS tools в Visual Studio, мы должны загрузить профиль публикации. Он может быть загружен и скачан по ссылке, как продемонстрировано на изображении. Публикация веб-сайта в Visual Studio Откройте SPA Application в Visual Studio 2013. Кликните правой кнопкой по названию проекта, чтобы вывести на экран контекстное меню Publish Option.     Эта опция выведет на экран следующее окно:     Данное окно имеет следующие параметры: Microsoft Azure веб-сайтов - поддержка прямого входа на Windows Azure на основе подписки. Import - позволяет импортировать веб-сайт и публиковать профиль, который загружается с портала Azure. Custom - позволяет создать новый профиль, публиковать для развертывания веб-сайта.   Нажмите на кнопку "Import" и будет отображено следующее окно для импорта профиля публикации:     После нажатия "OK", будет отображено следующее окно с деталями веб-развертывания:     Кликните “Next”. Так как мы уже развернули базу данных по Azure SQL, и последовательность подключений к базе данных уже обновлена в web.config файле, следующее окно покажет строку подключения:     Выберите “Далее”, чтобы отобразить список файлов, которые будут опубликованы:     Кликните по кнопке “Publish”, веб-сайт будет опубликован со всеми требуемыми ссылками.  Как только веб-сайт будет успешно опубликован, он может быть просмотрен.     Примечание: в этой статье не использовался CSS и, следовательно, неправильно расположение таблиц. Добавьте свои CSS, чтобы украсить страницу. Таким образом происходит развертывание веб-сайта на Azure. Источник: http://www.dotnetcurry.com/showarticle.aspx?ID=1064

Прошло много времени с момента релиза 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 и новую функциональность разор-страниц. Автор перевода: Евгений Лукашук Оригинал статьи

Введение ASP.Net Web API – это основа создания HTTP услуг широкого спектра клиентов, таких как браузеры, мобильные телефоны, планшеты и так далее. API должна быть совместима с современными браузерами, чтобы использовать эти услуги в простой форме. Мы можем быстро и просто сбрасывать служебные данные в браузер, а также приложения. Необходимость в Web API Если Вы нуждаетесь в Web Service и Вам не нужно SOAP, то API ASP.Net –лучший выбор. Он строит простые HTTP сервисы, основанные на базе существующей WCF. ASP.Net Web API на основе HTTP легко определяются. У них открытый исходный код. Легкая архитектура подходит для устройств с ограниченной шириной полосы, например, смартфонов. Создание простой Web API в ASP. NET MVC 6 Запустите Visual Studio 2015 Preview. В меню Файл выберите New > Project. В диалоговом окне New Project нажмите Tempates > Visual C# > Web и выберите ASP. NET шаблон проекта Web-приложений. Назовите проект "WebApplication1" и нажмите OK. В диалоговом окне New ASP.NET Project выберите "ASP.NET 5.0 Empty” шаблон. Проект включает в себя следующие файлы:   Global.json содержит настройки решения. В project.json находятся настройки проекта. Project_Readme.html – read me файл. Startup.cs содержит встроенный код конфигурации. Откройте файл Project.json. Добавьте библиотеки классов (class libraries) в разделе зависимостей (dependencies). ​ "dependencies": {           "Microsoft.AspNet.Server.IIS": "1.0.0-beta1",           " "Microfost.AspNet.Diagnostics": "1.0.0-beta1" } Затем откройте Startup.cs с кодом, показанным ниже.  public class Startup    {         public void Configure(IApplicationBuilder app)         {             // For more information on how to configure your application, visit http://go.microsoft.com/fwlink/?LinkID=398940              app.UseWelcomePage();             // app.UseMvc();          }     }  После отладки Visual Studio перейдите на http://localhost:port/ в браузере. Создание Web API Мы создадим Web API, чтобы упорядочить список клиентских продуктов. Сначала нужно добавить ASP.Net MVC6 в приложение. Добавьте пакет MVC6 в список зависимостей в Project.json. Используйте код ниже. "dependencies": {         "Microsoft.AspNet.Server.IIS": "1.0.0-beta1",         "Microsoft.AspNet.Diagnostics": "1.0.0-beta1",         "Microsoft.AspNet.Mvc": "6.0.0-beta1"       } Затем добавьте MVC в request pipeline в Startup.cs. Добавьте Using для Microsoft.Framework.DependencyInjection.   Добавьте следующий метод в Startup класс. using System; using Microsoft.AspNet.Builder; using Microsoft.AspNet.Http; using Microsoft.Framework.DependencyInjection;//add new  namespace WebApplication1 {     public class Startup     {         public void Configure(IApplicationBuilder app)         {                      app.UseWelcomePage();              app.UseMvc();         }         public void ConfigureServices(IServiceCollection services)         {             services.AddMvc();         }     } } Добавьте модель using System; using System.ComponentModel.DataAnnotations; namespace WebApplication1.Model {     public class Customer     {         public int CustomerId { get; set; }         [Required]         public string Name { get; set; }     } } Добавьте контроллер  using Microsoft.AspNet.Mvc; using System.Collections.Generic; using System.Linq; using WebApplication1.Model; namespace WebApplication1.Controllers {     public class HomeController : Controller     {                 static readonly new List<Customer> _items = new List<Customer>()             {                 new Customer  { CustomerId = 1, Name = "Henry" },                 new Customer { CustomerId = 2, Name = "John" },             };         public IEnumerable<Customer> Get()         {             return _items;         }         public IActionResult GetById(int id)         {             var its = _items.FirstOrDefault(x => x.CustomerId == id);             if (its == null)             {                 return HttpNotFound();             }             return new ObjectResult(its);         }         public void CreateCustomer([FromBody] Customer item)         {             if (!ModelState.IsValid)             {                 Context.Response.StatusCode = 400;             }             else             {                 item.CustomerId = 1 + _items.Max(x => (int?)x.CustomerId) ?? 0;                 _items.Add(item);                 string url = Url.RouteUrl("GetByIdRoute", new { id = item.CustomerId },                     Request.Scheme, Request.Host.ToUriComponent());                 Context.Response.StatusCode = 201;                 Context.Response.Headers["Location"] = url;             }         }         public IActionResult DeleteItem(int id)         {             var item = _items.FirstOrDefault(x => x.CustomerId == id);             if (item == null)             {                 return HttpNotFound();             }             _items.Remove(item);             return new HttpStatusCodeResult(204);         }     } } Выше описывается класс HomeController. Маршрутизация Атрибут маршрутизации определяет URL шаблоны контроллера. [Route("api/[controller]")] Методы HTTP [HttpGet], [HttpPost] и [HttpDelete] – атрибуты, определяющие методы HTTP для контроллера. public IEnumerable<Сustomer> Get() { }  //[HttpGet]  public IActionResult GetById(int id) { } //[HttpGetbyid}  public void СreateСustomer([FromBody] Сustomer item) { } // [HttpPost]  public IActionResult DeleteItem(int id) { } //[HttpDelete] {Customerid: int} int ограничивает переменную до соответствия целому числу, чтобы URL-адреса совпадали. http://localhost/api/home/1 http://localhost/api/home/42 Из этой статьи Вы узнали, как создавать Web API в MVC 6, используя модели, контроллер и HTTP методы. Источник: http://www.c-sharpcorner.com/UploadFile/85ed7a/create-web-api-in-mvc-6/

Введение 10 лет назад трудно было вообразить, что разработка ASP.NET веб-приложений вне интегрированной среды разработки Visual Studio .NET буде возможна. Но в прошлом году произошли изменения. В апреле 2014 года на конференции разработчиков (Build)  Microsoft анонсировал запуск нового легкого кросс-платформенного кодового редактора для разработки современных веб-приложений под именем Visual Studio Code. Visual Studio Code Visual Studio Code свободна для скачивания с официального сайта.  Работаете ли Вы на Linux, Mac или Windows – не имеет значения. Вы можете скачать и запустить VS код на своей платформе. Установка Visual Studio Code довольно проста, но если Вы застрянете, то всегда можете просмотреть документацию по установке. Visual Studio Code является просто редактором кода на файловой основе и не имеет всех преимуществ полной интегрированной среды разработки Visual Studio .NET. Он легче по дизайну. Тем не менее, у редактора есть множество особенностей, которые поддерживают такие технологии, как IntelliSense для дополнения кода, Peek Definition для быстрого взгляда на функциональный код без навигации,  реорганизацию кода и прочие. Visual Studio Code также поддерживает множество языков, например CoffeeScript, F#, Go, Jade, Java, Handlebars, Powershell и Python, для примера. Вы можете проверить языковую поддержку здесь. Также Visual Studio Code способен поддерживать такие среды выполнения, как ASP.NET 5 и Node.JS. Если Вы их используете для веб-разработки с Microsoft Stack, можете быть уверенны, что ASP.NET 5 (новая версия ASP.NET) сейчас поддерживает кросс-платформенную разработку. Это значит, что можно разрабатывать ASP.NET-приложение в среде Linux, Mac или Windows так же, как и запускать его в любой из них. И Вам даже не нужно иметь интегрированную среду разработки Visual Studio .NET, чтобы сделать это. Visual Studio Code – это все, что вам нужно, чтобы начать работать с ASP.NET 5, и это здорово! Установка ASP.NET 5 & DNX (среды выполнения .NET): ASP.NET 5 был построен с нуля, чтобы убедиться, что он придерживается современной парадигмы веб-приложений, и что приложения, разработанные с его помощью являются «облачными». Ключевыми аспектами ASP.Net 5 являются гибкость и модульность – он предлагает минимальные накладные расходы и позволяет нам выбирать только то, что мы хотим в рамках нашего веб-приложения. DNX расшифровывается как Dot Net eXecution Environment. Что такое Yeoman? Если Вы работали в интегрированной среде разработки Visual Studio .NET, Вам будет интересно: «Есть ли здесь File > New > ASP.NET шаблон проекта?» Visual Studio Code является редактором кода на файловой базе, так что Вы можете просто открыть файл и начать редактирование. Кроме того, нужны поддерживающие средства, чтобы работать с исполняемым шаблоном ASP.NET. Yeoman является популярным консольным инструментом для автоматического построения структуры проекта, а также обеспечивает базовым ASP.NET шаблоном для старта. Yeoman может быть установлен с помощью NPM, но для начала надо установить Node.JS. Если у Вас нет Node в системе, можете установить его. Кроме Yeoman, Вам также нужны другие поддерживающие средства, такие как генератор ASP.NET, исполнитель задач Grunt и Bower. Вы можете выполнить это за одну команду. В командной строке набрать следующую команду и нажать enter: npm install –g yo grunt-cli generator-aspnet bower Теперь Вы можете строить веб-приложения. Создание веб-приложения Разберем пошагово, как  построить структуру проекта нового ASP.NET 5 веб-приложения. 1. Откройте командную строку и перейдите в папку, где Вы хотите создать свое новое веб-приложение. 2. Введите в командную строку следующую команду:  yo aspnet 3. Yeoman отобразит варианты приложений для генератора aspnet. Возможные варианты: консольное приложение веб-приложение основное веб-приложение (без членов/аутентификации) веб-приложение API Nancy ASP.NET приложение библиотека классов тестовый проект Unit Выберите сейчас основное приложение. Используйте клавиши со стрелками для выбора опции и нажмите enter. 4. Дальше нам нужно назвать веб-приложение. Используем HelloWorld как имя нашего образца ASP.NET 5 веб-приложения. Введите имя и нажмите enter. Yeoman построит структуру проекта. 5. Каталог, в котором будет создано наше веб-приложение будет иметь то же имя, что мы дали только что Yeoman. В данном случае - “HelloWolrd”. cd HelloWorld   6. Через командную строку откройте Visual Studio Code code 7. Visual Studio Code запустит проект HelloWorld. Файлы в проекте будут отображаться в окне Проводника. 8. В редакторе Visual Studio Code выберите View > Command Palette option и в командной палитре введите следующую команду: dnx: dnu restore - (HelloWorld) Выше написанная команда restore устанавливает нужные NuGet пакеты, необходимые для запуска веб-приложения. Она запустит командную строку, куда будут загружаться все пакеты. После выполнения будет получено сообщение, что загрузка завершена. Запуск веб-приложения Теперь, когда мы успешно создали веб-приложение, пришло время запустить его и посмотреть на результат. 1. В Visual Studio Code откройте Command Palette, выбрав View > Command Palette. Введите следующую команду для запуска приложения: dnx: kestrel -(HelloWorld,Microsoft.AspNet.Hosting--server Kestrel–config hosting.ini Примечание: Когда Вы начинаете набирать команду, командная палитра подскажет Вам полную команду в списке. Вы можете выбрать команду из списка и команда будет выполнена. 2. Откройте браузер и перейдите по ссылке http://localhost5000 Мы только что создали ASP.NET веб-приложение вне интегрированной среды разработки Visual Studio. Фактически, в настоящее время ASP.NET больше не только в Windows. Мы переходим на кросс-платформу – как с точки зрения разработки, так и размещения. Интеграция Telerik UI для набора ASP.NET MVC Teleric предлагает пользовательский интерфейс, известный как UI для ASP.NET MVC. Он произошел от Kendo UI и предусматривает HTML-помощников, которых называют “Kendo UI wrappers.” Они упрощают работу с элементами управления Kendo UI и ускорят вашу разработку. Представим пошагово добавление пользовательского интерфейса для ASP.NET MVC в наш проект: 1. Откройте файл project.json и в узле (“dependencies”) добавьте Kendo (в настоящее время доступна бинарная версия Kendo Mvc – 2015.2.805). "dependencies":{     ...     "Kendo.Mvc":"*" } 2. Дальше откройте Startup.cs и найдите метод “ConfigureServices”. Добавьте следующий фрагмент в метод. //Register UI for ASP.NET MVC Helpers Services.AddKendo(); 3. Затем откройте ~/Views/_ViewImports.cshtml и импортируйте пространство имен Kendo.Mvc.UI. @using Kendo.Mvc.UI 4. Скопируйте Kendo UI ресурс с клиентской стороны. Для этого Вам нужно установить пакет Kendo UI Professional (Commercial Package). Его можно установить через Bower с помощью следующей команды: bower install https://bower.telerik.com/bower-kendo-ui.git Пакет Kendo UI Professional Bower размещается в частном git-хранилище и требует активировать аккаунт Telerik. Во время установки Вам предложат ввести пароль несколько раз. Bower установит пакет Kendo UI Professional как “kendo-ui” в папку wwwroot/lib. 5. Дальше нам необходимо зарегистрировать скрипты Kendo UI и стили в ~/Views/Shared/_Layout.cshtml. <head>     ...     <link rel="stylesheet" href="~/lib/kendo-ui/styles/kendo.common-bootstrap.min.css" />     <link rel="stylesheet" href="~/lib/kendo-ui/styles/kendo.bootstrap.min.css" />     <link rel="stylesheet" href="~/lib/kendo-ui/styles/kendo.dataviz.bootstrap.min.css" /> head> 6. Теперь  давайте используем виджет Kendo UI в одном из видов. Мы будем использовать виджет Kendo UI DatePicker. Откройте ~/Views/Home.Index.cshtml и добавьте следующий фрагмент: <body>     ...     <script src="~/lib/kendo-ui/js/kendo.all.min.js">script>     <script src="~/lib/kendo-ui/js/kendo.aspnetmvc.min.js">script>     @RenderSection("scripts", required: false) body> 7. Запустите веб-приложение через dnx: kestrel команду, что мы использовали ранее. Результат представлен ниже. Заключение Готово. У нас есть законченное веб-приложение ASP.NET 5, интегрированное с Telerik UI для ASP.NET MVC виджетов, разработанное только использованием Visual Studio Code с поддержкой таких инструментов, как Yeoman и Bower. Надеемся, Вам понравилось! Источник -  http://developer.telerik.com/featured/developing-asp-net-5-web-apps-with-visual-studio-code/

В мире дедлайнов правильный выбор технологии играет ключевую роль. Имея многолетний опыт за спиной, мы были вовлечены в разработку на десятках языков, с использованием фреймворков и библиотек. Собрав вместе наши знания, мы решили пролить свет на вопрос: React или Angular? и поделиться своими мыслями с вами. Так что в этой статье мы собираемся преобразовать наш опыт frontend разработки в информацию, которая поможет определить лучшую для вас технологию. Почему Angular 2? Angular JS – это open-source библиотека, предоставляющая всё необходимое для создания клиентской части сайта. Используя Angular 2, вы можете заметить, что вторая версия избавлена от ненужной сложности, которая присутствовала в предыдущей версии. Команда, работавшая над Angular 2, устранила или заменила почти все концепции первой версии. Я говорю о модулях, контроллерах, областях видимости, директивах и так далее. Однако они не остановились только на упрощении фреймворка. Они также добавили новые примечательные фичи и некоторые улучшения. Среди фич мы хотели бы выделить встроенную поддержку приложений и server-side рендеринг. Говоря об улучшениях, мы не можем упустить тот факт, что производительность Angular 2 резко возросла. Как Angular стал популярным? Тот факт, что Angular – создание Google, внушает доверие сам по себе. Фреймворк разработан таким образом, что не травмирует психику разработчиков, которые ранее учили другие технологии и языки. Многие разработчики утверждают, что если код на Angular кажется сложным – тогда ты делаешь что-то не так. Сайты, созданные на Angular JS: YouTube (for PS3), GoodFilms, Freelancer, Upwork. Итак, почему Angular 2 может быть полезным? Давайте рассмотрим его основные плюсы и минусы. Angular pros and cons by Cleveroad Почему ReactJS? В отличие от Angular, ReactJS – это JavaScript-based библиотека с открытым исходным кодом и JSX компилятором. Он в основном сосредоточен на пользовательском интерфейсе и разрешает создавать многоразовые UI рассматриваемые компоненты. Используя React, вы всегда должны помнить, что это не MVC фреймворк, а только библиотека для рендеринга вашего View (V из MVC). Таким образом, React – это интерфейс-ориентированное решение, когда ваши пользователи получают весьма отзывчивый интерфейс с плавной загрузкой. Как React стал популярным? За этим проектом стоит Facebook. ReactJS-решения дружественны с SEO. Производительность и гибкость ReactJS очень высоки. Известные сайты, сделанные с помощью ReactJS: Netflix, Feedly, Airbnb, Walmart Сейчас давайте рассмотрим, почему ReactJS может быть полезным. React pros and cons by Cleveroad Как сделать выбор? Сейчас мы глубже рассмотрим детали и нюансы, которые могут быть достаточно важными при выборе технологии. Лицензия Вы должны быть ознакомлены с видами лицензий фреймворка. Большинство лицензий довольно гибкие в работе, и вы можете использовать их для создания коммерческих приложений без каких-либо проблем. Однако существует целый ряд лицензий, которые не дают вам такой свободы действий. Лучше просто поискать информацию, нежели потом узнать, что вы не имеете права на коммерческое распространение своего продукта, не так ли? Примечание: Одним из преимуществ Angular JS и ReactJS является то, что это open-source фреймворки без каких-либо ограничений в использовании. Стоит отметить, что Angular использует MIT лицензию вместо 3-clause BSD лицензии, которая используется в React. Однако BSD отличается от MIT только присутствием запрета на использование имени владельца прав в рекламных целях. Паттерн MVC Паттерн Model-View-Controller разрешает разделять проекты на три компонента: модель, вид и контроллер. Таким образом, модификацию каждого компонента можно проводить независимо друг от друга, что способствует сжатию кода и повышению качества конечного результата. Помимо шаблонов MVC существуют также Model-View-Presenter (MVP) и Model-View-View-Model (MVVM). Примечание: Среди всех особенностей Angular 2 наличие out-of-the-box MVC паттерна является значительным преимуществом перед React. Из трёх букв акроним MVC имеет только букву «V» – View (в переводе «вид»). Так что если вам нужны буквы «М» и «С», то придётся искать их в другом месте. Размещение шаблонов Говоря о преимуществах Angular 2, стоит упомянуть о простоте написания шаблонов отображения. Имея действительно простой интерфейс, Angular позволяет получить конечный результат с более интуитивным подходом к пользовательскому интерфейсу, который требует меньше кода и кажется «очевидным». React же требует специальные функции для управления отображением данных. В основном это значит, что вам следует определить способ представления данных перед тем, как они будут внесены в DOM. Это может привести к отключению во время попыток определить, как будет отображаться определённый элемент.  Примечание: До 80% того, что вы делаете при создании онлайн-сервиса, основывается на написании пользовательского интерфейса. Так что, лучше взвешивайте подходы этих технологий к шаблонизации, чтобы понять, какой из фреймворков соответствует вашим предпочтениям в написании кода. Привязка данных Angular использует двухстороннюю привязку данных. С её помощью фреймворк может присоединить DOM к данным Model через контроллер. В двух словах: когда пользователь взаимодействует с входными данными и задаёт новое значение вашему приложению, то не только View может быть обновлен, а и Model тоже. Соответственно, вам не нужно писать какой-либо метод отслеживания этих изменений в приложении. Примечание: Подход Angular влияет на производительность из-за того, что создается вотчер (watcher) при каждой привязке данных. React использует одностороннюю привязку, где поток данных направлен только в одном направлении. Благодаря этому, вы всегда будете знать, в каком месте ваши данные меняются. Примечание: Подход React гораздо проще отлаживать, когда речь идёт о больших приложениях. Стоит сказать пару слов о клиентском и серверном рендеринге. Фактически server-side рендеринг использовался в первых версиях Angular и создавал трудности для маркетинга. Поскольку браузер воспринимает рендеринг клиентской стороны, то JavaScript дает отличные возможности для SEO оптимизации. Это является существенным недостатком, ведь большинство цифровых продуктов нуждаются в маркетинговой поддержке, дабы остаться в живых. Кроме того, client-side рендеринг может сильно повлиять на загрузку страниц. Однако начиная со второй версии, разработчики Angular исправили эту проблему, перенеся модель рендеринга на сторону сервера. Производительность Как вы знаете, Angular создает наблюдатель (watcher) для каждой привязки данных, чтобы отслеживать все изменения в DOM. Как только View получает некоторые обновления, Angular начинает сравнивать полученные значения с начальными. Дело в том, что данная технология проверяет не только те значения, которые изменились, но и все остальные тоже. Примечание: Производительность Angular 2 может стать причиной проблем для массивных приложений. Разработчики ReactJS ввели концепцию виртуального DOM, которая позволяет создавать легкое дерево DOM, сохраняя его на сервере. Каждый раз, когда пользователь взаимодействует с сайтом, например, заполняет форму, React создает новый виртуальный DOM для сравнения с предыдущим. После того, как библиотека обнаружит все различия между этими двумя моделями – виртуальный DOM будет перестроен. Весь процесс на сервере выполняется, таким образом снижая нагрузку на браузер. Примечание: Производительность ReactJS возрастает, когда дело доходит до больших объемов данных, поскольку в этом фреймворке нет вотчеров. Взгляните на график, показывающий оценку React и Angular по некоторым критериям. Эти оценки основаны на нашем личном опыте. Cleveroad evaluation of technologies У нас было небольшое собрание, посвященное вопросу «React или Angular?», в ходе которого наши frontend разработчики имели возможность обсудить все плюсы и минусы этих технологий. Они пришли к выводу, что Angular лучше подходит для их предпочтений в написании кода, а также для рабочих задач, с которыми они сталкиваются ежедневно. Для подведения итога всему сказанному выше мы подготовили для вас график. В нём сравниваются Angular 1.X, Angular 2 и React. React vs Angular versions Опыт Cleveroad Из этих двух технологий наши разработчики предпочитают Angular. Имея много наработок, связанных с этим фреймворком, мы способны работать более эффективно, сокращая время, необходимое для реализации проекта. Таким образом наши клиенты экономят на стоимости проекта из-за сокращения часов разработки. Все наши проекты, основанные на этой технологии, имели большое количество frontend-логики в своей структуре, которая часто изменяется. Кроме того, в проектах предусматривался ряд изменений в дизайне. Использование библиотеки React может увеличить время разработки и повысить общую стоимость конечного продукта. Вот некоторые из наших проектов: Age In Days, Count, Lifetile. Все эти веб-сайты основаны на AngularJS в нашей компании. Вы также можете посмотреть наш tech stack, который мы обычно применяем вместе с разработкой на Angular 2. Серверные решения: AWS, DigitalOcean, Hetzner, Microsoft Azure Back-end технологии: Node.js + Typescript 2, Angular 2 Базы данных: MySQL, MongoDB, Redis, PostgreSQL Облачные хранилища: WS S3, Azure storage Платёжные системы: Stripe, Braintree Инфраструктура и управление проектами: Webpack 2, Docker и CI, Jira, Bitbucket / Git Подводя итог Вероятно, проблема выбора между Angular и React в мире frontend может быть сопоставима с выбором между iOS и Android. Обе технологии имеют свои преимущества и недостатки, своих поклонников и ненавистников. Таким образом, у каждого разработчика есть определенные причины использовать ReactJS или другую технологию. В 2017 году все больше веб-проектов будет основано на Angular 2 благодаря фичам, позволяющим упростить жизнь разработчиков. Например, хорошая отладка, шаблон MVC, рендеринг на стороне сервера и т. д. В результате это сократит количество часов, необходимых для разработки, и, соответственно, снизит цены на разработку и обслуживание. Оригинал- https://www.cleveroad.com/blog/react-vs-angular-ultimate-performance-research-2017#.WKMPN5BkZMM.twitter

ASP.NET Core представляет собой существенный редизайн ASP.NET. В этом разделе представлены новые концепции в ASP.NET Core, а также содержатся объяснения, как они помогают разрабатывать современные веб-приложения.   Что такое ASP.NET Core? ASP.NET Core – это новый общедоступный и кроссплатформенный фреймворк для создания современного облака приложений, связанных с подключением к интернету, таких как веб-приложения, приложения для интернета вещей и мобильных серверов. Приложения ASP.NET Core могут работать на .NET Core или на полной платформе .NET Framework. Этот фреймворк был спроектирован таким образом, чтобы обеспечить оптимизированную платформу разработки для приложений, которые перемещаются в облако или выполняются локально. Он состоит из модульных компонентов с минимальной перегрузкой, поэтому вы сохраняете гибкость при построении своих решений. Существует возможность разрабатывать и запускать кроссплатформенные ASP.NET Core приложения на Windows, Mac и Linux. Фреймворк ASP.NET Core общедоступен на GitHub. Зачем строить ASP.NET Core? Первая предварительная версия ASP.NET появилась почти 15 лет назад как часть платформы .NET Framework. С тех пор миллионы разработчиков использовали технологию для создания и запуска отличных веб-приложений. За эти годы удалось добавить и разработать множество возможностей. ASP.NET Core имеет ряд архитектурных изменений, которые приводят к более компактной и модульной структуре. ASP.NET Core больше не основывается на файле System.Web.dll. Он основан на наборе детальных и хорошо структурированных пакетов NuGet. Это позволяет оптимизировать приложение с помощью пакетов NuGet, которые вам необходимы. Преимущества меньшей площади поверхности приложения включают: более строгую защиту, сниженный уровень обслуживания, улучшенную производительность и снижение затрат в модели «плати за то, что используешь». С помощью ASP.NET Core вы достигните таких основных улучшений: Единая история создания для Web UI и Web APIs Интеграция современных клиентских фреймворков и схем разработки Конфигурация, готовая для работы в облаке и основывающаяся на окружении Встроенная поддержка внедрения зависимостей Новый легкий и модульный HTTP-запрос Возможность хостироваться в IIS либо в вашем собственном приложении Фреймворк построен на платформе .NET Core, которая поддерживает истинное совместное управление версиями приложений Поставка как полные NuGet пакеты Новый инструментарий, который упрощает разработку современных веб-приложений Сборка и работа кроссплатформенных ASP.NET приложений на Windows, Linux и Mac Общедоступный и социально-ориентированный фремворк   Создание web UI и web APIs с использованием ASP.NET Core MVC Вы можете создавать службы HTTP, которые охватывают широкий круг клиентов, включая браузеры и мобильные устройства. Поддержка нескольких форматов данных и согласования содержимого – уже встроены. ASP.NET Core - идеальная платформа для создания web APIs и RESTful приложений на .NET Core. Вы можете создавать хорошо факторизованные и тестируемые веб-приложения, которые следуют шаблону Модель-Вид-Контроллер (MVC). Razor обеспечивает продуктивный язык для создания Views Тег-хэлперы позволяют серверному коду участвовать в создании и рендеринге HTML- элементов в файлах Razor Привязка модели автоматически отображает данные из HTTP-запросов в параметры метода действия Проверка модели автоматически выполняет проверку на стороне клиента и на стороне сервера   Разработка клиентской стороны ASP.NET Core предназначен для беспроблемной интеграции с различными клиентскими платформами, включая AngularJS, KnockoutJS и Bootstrap. Материал подготовлен на основе статьи: https://docs.microsoft.com/en-us/aspnet/core/. Авторы: Daniel Roth, Rick Anderson, Shaun Luttin

Здравствуйте, друзья! Провожая очень необычный 2020 год, который для многих стал проверкой на прочность и готовность к переменам, мы подвели итоги работы ITVDN и выбрали для вас все самое лучшее. Представляем вашему вниманию ТОП-10 видео курсов ITVDN, вебинаров и статей за 2020 год.  Лучшие курсы В 2020 году мы выпустили 21 видео курс по таким направлениям как C#/.NET, Java, FrontEnd разработка, Python, C++, мобильная разработка, UX/UI дизайн и другие. ТОП-10 лучших новых видео курсов в 2020 (по количеству просмотров): C# Стартовый от Александра Шевчука ASP.NET Core Web API. Практический курс JavaScript Starter Верстка сайта на FlexBox CSS React Essential UX/UI Design Essential Django Starter Spring MVC Решение практических задач на С++ Unit тестирование в Java с JUnit Лучшие вебинары В 2020 году мы провели 61 вебинар, в которых было много практики программирования, а также особенно популярные среди новичков вебинары по выбору специальности. Топ-10 вебинаров 2020 года по количеству просмотров и “лайков”: Как стать C# разработчиком в 2021 году. .NET или .NET Core? Как стать программистом? Frontend, Java, Python или .NET - что выбрать? Что нужно знать .NET разработчику в 2020? ➤ Как стать программистом на C# c нуля? Адаптивная верстка на Flexbox и Grid Что нужно знать FrontEnd разработчику в 2020? ➤ Пошаговая инструкция для начинающих JS больше не нужен?! Blazor - революция в веб-разработке Типичные ошибки в коде на примере С++, С# и Java Как прокачать английский для собеседования в IT-компанию Создание игры “Space Invaders” на C# с нуля Пишем пошаговую боевую систему на JavaScript с нуля. На примере игры Final Fantasy в 2D. Лучшие статьи В 2020 году мы опубликовали 19 статей, вот 10 самых читаемых из них:  Как не провалить своё IT-обучение Мифы о программировании и программистах Как стать Full-Stack разработчиком Что должен знать Python разработчик в 2020 году Как стать Android разработчиком FAQ начинающего программиста Что должен знать Java разработчик в 2020 году? Как стать разработчиком игр? С чего начинается создание сайтов? Специальность верстальщик Онлайн обучение программированию: подводные камни и советы   Открывайте для себя новые возможности с ITVDN! Будьте счастливы в Новом году!