Что такое нет фреймворк: Microsoft NET Framework — что это такое зачем он нужен и как установить его на Windows

Что такое .NET Framework?



Доброго времени суток. На связи Алексей Гулынин. В прошлой статье мы познакомились со способами передачи аргументов методу в C#. В данной статье я бы хотел ещё раз рассказать (более простыми словами), что представляет из себя платформа .Net Framework и Visual Studio. Данная статья является продолжением статей Visual Studio описание и Платформа .Net Framework .Net Framework — это среда CLR (Common Language Runtime — основная компонента .Net Framework), которая обеспечивает выполнение управляемого кода (managed code). CLR управляет этим кодом. Что такое управляемый код? Код, написанный для платформы .NET Framework компилируется не в конечный машинный код, а в промежуточный язык (так называемый IL — Intermediate Language). Затем эта сборка передаётся пользователю (на машине обязательно должен стоять .Net Framework), загружается в память и транслирует команды IL в действия, которые нужно выполнить.

Какой смысл в промежуточном языке IL?

Во-первых, он платформа-независимый, не привязан к конкретному процессору.

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

Вторая важная компонента после CLR — это библиотека классов (Class Library). В состав .NET Framework входит большое количество классов, разбитых по пространствам имен, которые предоставляют весь базовый функционал. Это тот функционал, который может потребоваться вашей программе, например работа с файлами, сетью, процессами, с графической подсистемой.

Третья компонента — это Development Frameworks (другими словами библиотеки разработки). Сюда входят такие библиотеки, как WPF (Windows Presentation Foundation), ASP.NET, Entity Framework, WCF (Windows Communication Foundation), Windows Store и др. Фактически это тоже классы. Отличие заключается в том, что эти классы предназначены для решения специфических задач:

  • WPF — для работы с графическими приложениями
  • ASP.NET — для работы с web-приложениями
  • WCF — для работы с сетью и создания распределенных (клиент-серверных) приложений
  • Entity Framework — для работы с базой данных.

На момент написания данной статьи последней версией является .Net Framework 4.6

Основной средой для разработки, рекомендуемой Microsoft, является Visual Studio. У Microsoft обычно такая ситуация: как выходит новая версия .NET Framework, то через некоторое время выходит и новая версия Visual Studio. Что входит в состав Visual Studio (основное):

  1. Текстовый редактор с синтаксической подсветкой кода
  2. Система помощи IntelliSence (вызывается автоматом или сочетанием клавиш Ctrl + Space (пробел)
  3. Компиляторы с разных языков
  4. Средства быстрой разработки (RAD — Rapid Application Development)
  5. Визуальный дизайнер интерфейсов, диаграмм
  6. Компонент работы с серверами, с базами данных
  7. web-сервер IIS и sql-сервер Express варианта
  8. Отладчики, профилировщики, компоненты позволяющие обрабатывать ошибки
  9. Система помощи MSDN

На момент написания данной статьи последней версией является Visual Studio 2015.

Как в Visual Studio устроено понятие программ. В студии есть понятие «Проект» (Project) и «Решение» (Solution). Проект — это единица компиляции. Он состоит из набора файлов. Проект компилируется целиком обычно в сборку (exe-файл, либо dll-файл). Проекты могут быть сгруппированы в Solution. Solution — это просто набор проектов, которые могут быть связаны друг с другом (обычно так и происходит), а могут быть не связаны друг с другом.

Для создания проекта в Visual Studio существует понятие шаблона проекта.

Примеры основных проектов:

  • Console Application
  • Windows Forms Application
  • WPF Application
  • Class Library
  • WCF Service Application
  • Windows Store
  • ASP.NET Web Application
  • ASP.NET MVC 5 Application

В реальности шаблонов гораздо больше. Также существуют шаблоны от сторонних разработчиков.

В данной статье вы узнали что такое .Net Framework, а также узнали про Проект (Project) и Решение (Solution) в Visual Studio.

На связи был Алексей Гулынин, оставляйте свои комментарии, увидимся в следующих статьях.

Опубликовано

от Алексей Гулынин

Оставить комментарий

Следующая статья >


Комментарии:



В чем разница между .NET Framework и .NET Core?

Microsoft предоставляет две разные среды выполнения .NET: .NET Framework и .NET Core. Оба реализуют .NET Standard, и код между ними достаточно кросс-совместим, но .NET Framework работает только в Windows. Мы обсудим различия между двумя средами выполнения.

Краткий ответ: кроссплатформенная совместимость

Быстрый ответ: .NET Core работает в Linux и macOS, а .NET Framework работает только в Windows. Вы бы использовали . NET Core, когда вам нужна кросс-платформенная совместимость, и вы бы использовали .NET Framework, когда вам нужны специальные службы Windows и пакеты NuGet, которые не были перенесены в .NET Core.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

.NET Core является преемником .NET Framework, так что это определенно то, что вы хотите выбрать в будущем. Он оставляет после себя некоторые функции только для Windows, но многие из них все еще могут поддерживаться Пакет обеспечения совместимости с Windows расширение.

В целом Core и Framework почти одинаковы, но на практике у них есть небольшие различия. И .NET Core, и .NET Framework используют один и тот же API, называемый .NET Standard, но Core имеет открытый исходный код, а Framework — это реализация Microsoft только для Windows.

В общем, Core немного легче, чем Framework, так как он разработан и часто используется с Docker в серверных модулях на основе микросервисов. Помимо возможности использовать Linux в первую очередь (что необходимо для Docker), получившийся образ будет немного меньше с .NET Core.

Помимо этого, большая часть различий заключается в различиях пакетов NuGet. Например, Entity Framework Core немного отличается от Entity Framework 6, который работает на .NET Framework. ASP.NET Core сильно отличается от ASP.NET 4, поскольку они многое переработали для .NET Core.

Когда использовать .NET Core

Вы должны использовать .NET Core поверх .NET Framework в следующих случаях:

  • Вы необходимость кроссплатформенная совместимость. Сюда входит использование архитектур Docker и микросервисов.
  • Вы начинаете новый проект, и вам просто нужно выбрать один. (.NET Core новее.)
  • Вы не используете специальные инструменты, библиотеки или пакеты NuGet для Windows, которые зависят от .NET Framework.
  • Вы хотите максимально возможную производительность. Microsoft рекомендует .NET Core с ASP.NET вместо .NET Framework.
  • Вы хотите запускать несколько версий .NET Core одновременно друг с другом. Framework не поддерживает это.
  • Вы хотите получить доступ к интерфейсу командной строки в Linux или запустить сервер сборки CI / CD в Linux.

Когда использовать .NET Framework

Вы должны использовать .NET Framework поверх .NET Core в следующих случаях:

  • Вы ориентируетесь только на развертывание Windows.
  • Вы интенсивно используете пакеты и библиотеки Windows, такие как Windows Forms, WPF, ASP.NET Web Forms / Pages и Windows Workflow Foundation.
  • Используемые вами технологии не добавляются Пакет обеспечения совместимости Windows для .NET Core.
  • Вы уже используете его, и миграция потребует слишком много усилий.

Как перейти на .NET Core

Обычно это будет «как переключиться с Framework на Core», потому что любой существующий работающий проект на .NET Core, скорее всего, не нуждается в переключении обратно на старую .NET Framework.

Если вы используете что-то специфичное для Windows, вы не сможете. Вы застряли на .NET Framework до тех пор, пока используемые вами компоненты не получат версии Core, а некоторые вещи не будут происходить, как с ASP.NET WebForms.

Самым простым решением было бы создать новое Решение и проект на основе .NET Core и перенести туда свой код. Если у вас есть простое приложение, это, вероятно, самое простое решение.

В противном случае вы можете использовать dotnet try-convert, или следовать Руководство Microsoft по портированию.

Для больших сложных проектов вы можете использовать Анализатор переносимости .NET. Это инструмент от Microsoft, который просканирует ваш проект, расскажет, насколько сложным может быть преобразование, и покажет, какими должны быть ваши следующие шаги.

Он также может создать ориентированный график ваших зависимостей, который поможет вам увидеть, что еще требует анализа. Некоторые проекты будет сложнее перенести, чем другие, и если вы используете что-то, недоступное в Core, возможно, вы вообще не сможете перенести без обходного пути.

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

Метки записи:
#NET

Похожие записи

Веб-разработка без фреймворка

Содержание

  • Что такое фреймворк?
  • Нужны ли фреймворки?
  • Что нам нужно
    • Безопасность
    • Государственное управление
    • Маршрутизация
    • просмотров / рендеринг
    • Постоянство
    • Исходный язык и сборка
  • Библиотеки
  • Проект и демонстрация

Введение

Как однажды умолял президент Кеннеди:

«Мои коллеги-разработчики, не спрашивайте, что ваш фреймворк может сделать для вас .
Спросите, что вы можете сделать для своего фреймворка!».

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

Два года назад я работал с Angular 2, и если вам удавалось получить сжатую полезную нагрузку javascript менее 200 КБ, вы думали, что у вас все хорошо. Я вспомнил об этом, когда понял, что теперь у меня может быть приложение с гораздо большей функциональностью и легко в пределах 15 КБ.

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

Что такое фреймворк?

Прежде всего, давайте проясним, что мы подразумеваем под фреймворком . Для меня фреймворк воплощает некоторую архитектуру приложения, и, если вы правильно заполните нужные части, он вызовет ваш код и заставит его работать. Но главное — структура, и вы работаете так, как это диктует и . Фреймворки могут быть великолепны, когда вы начинаете, потому что они предоставляют некоторую структуру, которую вы, возможно, не знаете, как построить самостоятельно, но если вы не возражаете против «требуется некоторая сборка», библиотеки обеспечивают гораздо большую гибкость и меньшую блокировку. Теоретически вы можете выбрать библиотеки, которые хотите использовать, и заменить любую из них по мере необходимости, если появится что-то лучшее. Вы можете рассматривать фреймворк как готовую группу библиотек, но фреймворк устанавливает правила.

Нужны ли фреймворки?

Но времена меняются. Точно так же, как jQuery сделал безупречным смыслом и предоставил ценные абстракции для маскировки бесчисленных несоответствий браузеров, но стал менее ценным сейчас, когда все стало более стандартизированным, так и слишком многие из функций, предоставляемых фреймворками, уже не так необходимы, как браузеры. имеют возможности, встроенные напрямую.

Какой бы фреймворк вы ни использовали, легко попасть в ловушку, предполагая, что он нужен, но причины, по которым он был нужен около двух с лишним лет назад или когда вы начали его использовать, могут больше не применяться или быть недействительными. Платформа браузера постоянно развивается, поэтому полезно время от времени пересматривать свой выбор, чтобы убедиться, что он нам по-прежнему нужен, и мы используем его не только потому, что он стал удобным одеялом, с которым мы знакомы.

Подумайте об этом, представьте, что в вашем браузере уже есть встроенная веб-инфраструктура, разработанная в собственном коде, быстрая и ничего лишнего для загрузки. Разве вы, , не хотели бы, чтобы использовал его? Или подумайте об этом с другой стороны, если бы вы уже использовали встроенный фреймворк, вы бы действительно «купились» на идею добавления дополнительных 100 КБ JavaScript в ваше приложение только для того, чтобы делать то, что оно уже может делать, с немного другим API? Добавляет ли он достаточную ценность, чтобы оправдать затраты?

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

Что нам нужно

Есть еще вещи, которые нам нужны и которые имеет смысл повторно использовать в разных проектах, а не изобретать и повторно реализовывать для каждого из них, поэтому я, конечно, не выступаю за отсутствие каких-либо зависимостей, но это полезно относитесь к ним как к библиотекам, которые нам нужны для выполнения конкретных задач. Итак, давайте рассмотрим основные части и варианты использования библиотек для обеспечения необходимой нам функциональности и способы их объединения.

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

Безопасность

Если у вас есть веб-приложение, у вас есть пользователи, и вам необходимо их аутентифицировать. Если нет, то у вас просто статический веб-сайт, поэтому перестаньте все усложнять и просто используйте свою любимую CMS или генератор сайтов, такой как Jekyll или Hugo, или напишите свой собственный.

Я большой поклонник аутентификации Firebase, потому что она «дешевая как чипсы», отлично работает и очень проста в использовании. Так что я использую это, но вы можете подключить любую другую систему аутентификации, которую вы используете вместо этого.

Государственное управление

Двусторонняя привязка данных раньше была в моде, но как подход она действительно потеряла популярность и вымирает (как эволюционный тупик). Как только вы почувствуете преимущества односторонних / неизменяемых потоков данных с использованием чего-то вроде Redux, вы никогда не вернетесь назад. Так что используйте Redux и научитесь правильно его использовать — это стоит вложений.

Хотя есть альтернативы, стоит помнить, что для Redux существует целая экосистема инструментов и библиотек. Мы будем использовать некоторые из распространенных, чтобы упростить обработку удаленных вызовов API и других асинхронных действий, а также некоторые связанные библиотеки для эффективного создания представлений данных в нашем магазине.

Маршрутизация

Сеть — это URL-адреса, и сопоставление URL-адресов с представлениями в вашем приложении — это то, что делает маршрутизатор. Для одностраничного приложения это также предотвращает повторную загрузку приложения ссылками на представления каждый раз, а вместо этого перехватывает их и переключает представления, поэтому все происходит очень быстро.

Активный вид и параметры для него — это просто состояние, как и любое другое, и это состояние должно быть в магазине Redux. Если мы используем промежуточное ПО для синхронизации хранилища Redux с адресной строкой браузера, наше приложение может просто работать из этого состояния.

Представления / Рендеринг

Мы хотим, чтобы наши представления были инкапсулированными компонентами, а для этого нужны две вещи — компоненты или классы и какой-то способ преобразовать их в HTML для отображения в браузере. К счастью, стандарт WebComponents теперь предоставляет систему компонентов, изначально встроенную в браузер, с методами жизненного цикла, к которым мы можем подключиться. Так что остается только рендеринг нашего состояния через компоненты в HTML. Хотя мы могли бы сами кодировать манипулирование DOM, это одна из тех частей, которые можно сделать универсальными, и в городе есть новая игра для шаблонов HTML-представлений под названием Lit-Html.

TL;DR; Lit-Html позволяет вам определить HTML-шаблон как специальный тип «помеченной» строки, а затем может заменять переменные в нем всякий раз, когда эти переменные изменяются, но очень эффективно, поэтому не нужно тратить время на обновление каких-либо частей, которые не изменились.

Думайте об этом как о DOM-диффинге React, но без какого-либо сравнения — посмотрите это сравнительное сравнение производительности фреймворка javascript, которое показывает, что это быстро.

Постоянство

Раньше это означало бэкэнд JSON REST API, но крутые ребята будут смеяться над нами, если мы не «бессерверные», и, по правде говоря, бессерверные действительно удобны, и поскольку мы используем Firebase для аутентификации, мы также можем использовать Firebase для хранилища данных.

Возможно, вы слышали или уже пробовали базу данных Firebase Realtime, но есть и более новая база данных Firestore, которая как бы объединяет RTDB с хранилищем данных Google Cloud Platform и обеспечивает более красивую структуру ваших данных (по сравнению с «большим документом JSON»). ” из RTDB), сохраняя при этом возможности синхронизации данных в реальном времени и даже добавляя некоторые приятные автономные возможности из коробки. Это также может быть значительно дешевле и обеспечивает более простые/богатые запросы (это будет очень знакомо, если вы использовали Google Cloud Datastore)

Исходный язык и сборка

Многие фреймворки предоставляют интерфейс командной строки для создания приложения, поэтому нам тоже понадобится что-то для создания нашего. Хотя мы могли бы использовать для этого модули JavaScript и ES, использование TypeScript дает много преимуществ — мы получаем хороший интеллект из-за статической типизации, и он выполняет транспиляцию в JavaScript, который может работать в браузере, поэтому мы можем использовать более новый язык. Особенности. Babel — еще один вариант для этого, но я «хочу немного» intellisense и статической безопасности типов!

Мы собираемся использовать Rollup для управления процессом сборки — это позволит удалить код, который мы не используем, и позволит нам использовать плагины для предоставления других функций сборки, которые могут нам понадобиться (таких как минимизация переданного javascript).

Это означает, что мы можем использовать функции JavaScript завтрашнего дня (например, оператор распространения), чтобы сделать разработку проще и быстрее, но чтобы она работала с механизмами JavaScript сегодняшних браузеров.

Библиотеки

Вот полный список библиотек, которые мы собираемся использовать, и то, что они нам предоставляют:

  • Веб-компоненты для инкапсуляции компонентов и жизненного цикла
  • Аутентификация Firebase для аутентификации
  • Firebase Firestore для сохранения
  • Lit-Html для рендеринга шаблонов HTML
  • Redux для управления состоянием
  • Redux Routing для синхронизации состояния URL-адреса браузера с магазином
  • Redux Thunk для асинхронных действий (например, разговор с Firestorm)
  • Redux Reselect для эффективного выбора данных из хранилища
  • Универсальный маршрутизатор для сопоставления URL с компонентами и параметрами
  • Typescript для разработки с сильными типами и intellisense
  • Rollup для объединения и оптимизации окончательного кода

Проект и демонстрация

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

https://github. com/CaptainCodeman/web-app-starter

Вы можете увидеть работающую демонстрацию, которая очень проста, но содержит все элементы, необходимые для начала создания реального приложения, и полезную нагрузку JavaScript (за исключением Firebase время выполнения) в настоящее время сжато всего 14 КБ.

Дайте мне знать, что вы думаете, и если у вас есть какие-либо конкретные вопросы или предложения о том, что охватить в будущем.

К сожалению, у нас нет фреймворка

История фреймворков PHP начинается в середине нулевых, а точнее в 2005 году. Хотя PHP существует с 1995, только в версии 4 была рудиментарная поддержка того, что можно было бы назвать — с большой долей доброй воли — объектно-ориентированным. Однако это не помешало некоторым смельчакам сделать свои первые объектно-ориентированные шаги. Они опубликовали библиотеки и классы, которые в основном просто объединяли определенные функции: родился PEAR, PHP Extension and Application Repository. И даже если эти решения имеют мало общего с тем, что мы могли бы сегодня понимать под фреймворком, модульную концепцию PEAR можно найти и в современных фреймворках.

Следующее поколение фреймворков PHP требовало версии 5 языка, которая была выпущена в 2004 году с серьезной поддержкой объектно-ориентированной разработки, бума доткомов и, что не менее важно, Дэвида Хайнемайера Ханссона. Стоит ли сегодня с точки зрения PHP гордиться тем, что способствовал буму доткомов, вероятно, вопрос, который можно превосходно обсудить или даже поспорить. Что, однако, бесспорно, так это то, что Дэвид Хайнемайер Ханссон со своим фреймворком Ruby on Rails оказал большое влияние, особенно на мир PHP, и, вероятно, все еще оказывает его сегодня.

Сначала сообщество PHP с завистью смотрело на ранние истории успеха о том, насколько продуктивным может быть программирование с помощью такой среды, как Ruby on Rails. По общему признанию, сравнение между языком программирования и фреймворком не имеет особого смысла, но кто в сегодняшнем (медийном) мире все еще спрашивает о пользе сравнений?

Стандартный пример приложений Ruby on Rails, создание блога менее чем за 10 минут, впечатляет, но он вводит в заблуждение относительно сложности реального приложения с серьезной бизнес-логикой. И это до того, как мы перейдем к проблемному использованию Active Record и сильной связи кода с базой данных, стоящей за ним.

Вероятно, из-за страха, что PHP — не в последнюю очередь из-за фреймворка Rails — может уступить долю рынка Ruby, а также из-за того, что в то время почти не было доступных серьезных фреймворков PHP, компания Zend анонсировала свой собственный продукт с открытым исходным кодом: Zend Фреймворк.

Однако прошло около двух лет до его первого выпуска 30 июня 2007 года. Это время, когда другие команды разработчиков также работали над своими фреймворками для PHP, и некоторые из них добились довольно значительного распространения. Среди наиболее известных фреймворков первыми, вероятно, были CakePHP, Agavi и Symfony 1 в 2005 г., за ними последовали CodeIgniter в 2006 г. и его ответвление Kohana в 2007 г.

Разумеется, разрабатывались не только универсальные фреймворки, но и более-менее готовые решения для систем управления контентом, интерактивных порталов или создания интернет-магазинов. Помимо Typo 3 и Drupal, особенно Magento стала одной из самых популярных (и часто ненавидимых) платформ для электронной коммерции. Забавный факт: изначально Zend рекламировала его как демонстрацию мощи собственного фреймворка, Magento 1 использовала очень мало частей раннего предварительного релиза фреймворка, и даже тогда основные концепции были искажены почти до неузнаваемости.

Какой из фреймворков лучше?

Растущее разнообразие фреймворков и концепций быстро привело к вопросу о том, какой фреймворк лучше. Конечно, этот вопрос кажется очевидным, если (больше) нельзя спрашивать, какой язык программирования является лучшим. Дискуссии, которые следуют за попытками ответить на этот вопрос, конечно, в высшей степени религиозны. В конце концов, вряд ли в какой-либо теме разработчики могут столько спорить, разве что об отступах и о том, где ставить фигурные скобки.

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

То, что произошло потом, должно быть, стало горьким разочарованием для организаторов: представители разных фреймворков, которые и так знали друг друга, выражали друг другу большое уважение, кое-где расхваливали техническое преимущество «конкурса» и рассказывали, где они были вдохновлены друг другом. «Война фреймворков», высказанная в названии мероприятия, никогда не существовала в таком виде. Сообщество PHP, даже если это не всегда так кажется со стороны, всегда было тесно переплетено.

Если вам не нужно стремиться к доле рынка, чтобы еще больше увеличить собственные продажи и продолжать публиковать новые истории успеха в бизнесе, вы можете вдохновляться идеями, концепциями и решениями других, точно так же, как это делал и продолжает делать PHP как язык . Именно это «обучение друг у друга» ускоряет инновации. В мире с открытым исходным кодом это еще лучше и еще быстрее, потому что вы можете легко просматривать исходный код других без технических и юридических препятствий и — в зависимости от лицензии — даже напрямую использовать его или интегрировать его как компонент в свой собственный. решение.

Фабьен Потенсье, основатель Sensio Labs и отец Symfony, оказал выдающиеся услуги сообществу PHP, как никто другой. Он всегда знал, как выйти за рамки PHP и учиться на других языках и их платформах. Таким образом, он принес новые идеи и множество лучших практик сообществу PHP. Все эти годы Symfony была движущей силой инноваций в мире PHP и повлияла на многие другие решения и фреймворки. Конечно, вы не обязаны соглашаться со всеми решениями, концепциями и вытекающими из них решениями, но многие инновации — по крайней мере, в мире PHP-фреймворков — сегодня трудно представить без них.

Например, последовательное использование внедрения зависимостей (DI), которое должно быть само собой разумеющимся в объектно-ориентированном программировании, не всегда было очевидным выбором при разработке PHP. На треке Unconference в кулуарах ZendCon в Санта-Кларе, где проходила сессия по внедрению зависимостей, Фабьен, Стефан и один из основных разработчиков Zend Framework, Ральф Шиндлер, собрались вместе и обсудили плюсы и минусы DI. Сначала Ральф не был убежден, почему и как вообще следует использовать внедрение зависимостей. Очевидно, аргументы Фабьена и Стефана были убедительны, потому что в следующем выпуске Zend Framework появился новый компонент — контейнер внедрения зависимостей (DIC), написанный Ральфом Шиндлером.

Интересно, что, несмотря на свое название, Zend Framework изначально позиционировался как свободный набор компонентов, которые можно было использовать вместе и которые следовали относительно единой схеме разработки. Это очень отличается от многих других фреймворков, которые имели фиксированную, довольно монолитную структуру, следуя принципу «все или ничего», и поэтому также называются фреймворками с полным стеком.

Инверсия управления

Что приводит нас к захватывающему вопросу: что такое фреймворк? Если вы спросите в Интернете, вы получите, как это часто бывает, бесчисленное множество объяснений, некоторые из которых даже противоречат друг другу. С академической точки зрения, структура — это просто инверсия контроля. На практике это означает, что приложение не управляет потоком управления само по себе, а оставляет это на усмотрение фреймворка. Таким образом, повторяющиеся процессы могут быть закодированы в общем виде, так что разработчик приложения может сосредоточиться на написании самого приложения, компоненты которого затем вызываются структурой.

Неудивительно, что большинство фреймворков в мире PHP связаны с абстрагированием HTTP-запросов и хотят максимально упростить для разработчика создание приложения и его интеграцию с Интернетом.

Многие платформы утверждают, что полагаются на шаблон проектирования MVC. Тот факт, что паттерн Модель-Представление-Контроллер, который Трюгве Реенскауг изобрел в 1979 году для настольных приложений на языке Smalltalk, концептуально не может функционировать в сети и в межклиент-серверных границах, был и остается просто проигнорированным. Следствием этого является то, что никто не может точно ответить, какой код на самом деле относится к модели, а какой к контроллеру, даже авторы соответствующих фреймворков. Только когда дело доходит до точки зрения, большинство людей более или менее согласны.

Но независимо от того, какую инфраструктуру HTTP вы выберете, поток управления для ответа на HTTP-запрос всегда один и тот же: в зависимости от того, какой запрос присутствует, вы должны решить, какой код выполнять — процесс, называемый маршрутизацией. Для отображения результата обычно используется HTML и, таким образом, только что упомянутое представление. Ошибки «конвертируются» в соответствующие коды ошибок HTTP или, в случае обработки формы, подготавливаются в удобной для пользователя форме.

Между прочим, форма или обработка данных также является типичным вариантом использования фреймворка реверсирования потока управления. Вместо реализации потока управления разработчик приложения определяет только саму форму, определяет, какими значениями она должна быть предварительно заполнена, а затем определяет правила проверки с соответствующими сообщениями об ошибках. После этого все, что остается сделать, — это определить, какие действия должны быть выполнены в случае успеха, а какие — в случае ошибки. Затем управление передается контейнеру-инверсии-управления, в простейшем случае самописному абстрактному базовому классу.

Хотите понять современные тенденции? Посмотрите на наши тренировки.

Даже предположительно современная структура CQRS не сильно отличается, за исключением того, что делается различие между командой и запросом, которые маршрутизируются отдельно. Кроме того, команды обычно не возвращают содержимое, в то время как запросы, очевидно, служат для доставки содержимого. Тот факт, что этот контент в идеале уже статически генерируется вне запроса и, таким образом, доступен в форме, которая оптимально соответствует запросу, не сильно меняет фактический поток обработки.

Становится интересно, когда требования меняются, и это приводит к тому, что базовые допущения, особенно фреймворка, перестают применяться: Что произойдет, если вместо HTML ответом будет JSON или одна и та же бизнес-транзакция должна обрабатываться независимо и без запуск HTTP-запроса? Как это выглядит, когда вместо полноценной HTML-страницы нужны небольшие фрагменты в разных форматах? Классические решения с полным стеком, такие как Magento или Typo3, по-прежнему страдают от того, что их архитектура на самом деле не предназначена для таких случаев использования.

У тех, кто не разрабатывал бизнес-логику собственного приложения чисто изолированным образом, а тесно связан с фреймворком, тоже возникают проблемы. Решение часто представляет собой такой инструмент, как wget, который можно использовать для запуска HTTP-запроса из командной строки. Или иногда используются сложные дополнительные технологии для вырезания, парсинга или преобразования доставленной страницы.

Пока не сломается

Интересно, что осознание того, что используемая до сих пор структура больше не может удовлетворить все требования, редко приводит к тому, что сначала извлекается фактическая бизнес-логика. Похоже, правило заключается в том, что кто-то пытается все больше и больше изгибать текущее решение, тем самым теряя шанс на обновление или напрямую повторяя те же ошибки при переходе на другой фреймворк.

Большинство поставщиков фреймворков усвоили урок: хотя пути миграции с Zend Framework 1 на версию 2 практически не существовало, современные фреймворки стремятся поддерживать обратную совместимость с более ранними версиями, насколько это возможно.

Нам всегда интересно испытать в нашей повседневной консультационной работе, что разработчики буквально извиняются перед нами за то, что не использовали фреймворк. Помимо того, что это не соответствует действительности в большинстве случаев согласно приведенному выше определению фреймворка, просвечивает совершенно ненужное обесценивание собственного труда. Вам не должно быть стыдно, если вы разработали свою собственную структуру, адаптированную к вашим собственным требованиям, и вам не должно быть стыдно за использование стандартной среды.

Фреймворк не обязательно должен быть — и, возможно, даже не должен быть — реализован как решение с полным стеком, а должен эффективно решать ровно одну задачу. За прошедшие с тех пор десять лет наметилась четкая тенденция перехода от фреймворков с полным стеком к так называемым микрофреймворкам, таким как Slim. Это было спровоцировано осознанием того, что тяжеловесный фреймворк, предназначенный для загрузки большого количества данных, чтобы динамически собрать из него сложную HTML-страницу, не обязательно подходит для ответов на AJAX-запросы от фронтенда с высокой производительностью.