Net архитектура приложений — Мир ПК

Принципы работы и структура Web-приложений на основе ASP.NET

Краткое описание архитектуры ASP.NET и .NET Framework

ASP . NET — это платформа для создания Web-приложений и Web-сервисов, работающих под управлением IIS . Сегодня существуют другие технологии, позволяющие создавать Web-приложения. К ним относятся прежде всего, очень популярные сегодня языки PHP и PERL, более старая и менее популярная технология CGI и т. д. Однако ASP . NET отличается от них высокой степенью интеграции с серверными продуктами, а также с инструментами Microsoft для разработки доступа к данным и обеспечения безопасности. Кроме того, ASP . NET позволяет разрабатывать Web- и Windows -приложения, используя очень похожие технологические цепочки, одинаковые языки программирования, технологии доступа к данным и т. д. Более того, базовые языки программирования, с помощью которых сегодня возможна разработка Web-приложений, являются полностью объектно-ориентированными, что делает разработку исполнимой части, а также ее модификацию, обслуживание, отладку и повторное использование гораздо более простым занятием, чем в других технологиях. Существует достаточно большой перечень сильных сторон использования ASP . NET для создания сложных Web-приложений. Целью данного курса не является описание всех сильных и слабых сторон этой платформы. Более подробно об этом можно узнать на сайте http://www.microsoft.com, а также в [ 1 ] .

Заметим лишь, что ASP . NET функционирует исключительно на серверах Windows , так как требует наличия IIS . Для создания Web-приложений, не требующих IIS , а использующих, например, Web- сервер Apache и работающих на серверах под управлением операционных систем, отличных от Windows , применяются другие технологии.

Важным моментом в понимании архитектуры ASP . NET является тот факт, что она является частью инфраструктуры . NET Framework. Более подробно об архитектуре и принципах работы . NET Framework можно узнать в [ 2 ] . Так как эта тема является слишком объемной и выходит за рамки данного курса, ограничимся лишь кратким описанием инфраструктуры . NET Framework.

Архитектура .NET Framework

Как утверждает корпорация Microsoft, до 80% средств, направленных на исследования и разработки, тратится на платформу .NET и связанные с ней технологии. Результаты такой политики на сегодняшний день выглядят впечатляюще. Так, область охвата платформы .NET просто огромна. Платформа состоит из четырех групп программных продуктов:

набор языков, куда входят С# и Visual Basic .NET; набор инструментальных средств разработки, в том числе Visual Studio .NET; обширная библиотека классов для построения Web-служб и приложений, работающих в Windows и в Интернете; а также среда выполнения программ CLR ( Common Language Runtime — общеязыковая среда выполнения), в которой выполняются объекты, построенные на этой платформе;

набор серверов .NET Enterprise Servers, ранее известных под именами SQL Server 2000, Exchange 2000, BizTalk 2000 и др., которые предоставляют специализированные функциональные возможности для обращения к реляционным базам данных, использования электронной почты, оказания коммерческих услуг «бизнес-бизнес» (В2В) и т. д.;

богатый выбор коммерческих Web-служб, называемых .Net My Services. За умеренную плату разработчики могут пользоваться этими службами при построении приложений, требующих идентификации личности пользователя и других данных;

новые некомпьютерные устройства, поддерживающие средства .NET, — от сотовых телефонов до игровых приставок.

Microsoft .NET поддерживает не только языковую независимость, но и языковую интеграцию. Это означает, что разработчик может наследовать от классов, обрабатывать исключения и использовать преимущества полиморфизма при одновременной работе с несколькими языками. Платформа .NET Framework предоставляет такую возможность с помощью спецификации CTS ( Common Type System — общая система типов), которая полностью описывает все типы данных, поддерживаемые средой выполнения, определяет, как одни типы данных могут взаимодействовать с другими и как они будут представлены в формате метаданных .NET. Например, в .NET любая сущность является объектом какого-нибудь класса, производного от корневого класса System.Object. Спецификация CTS поддерживает такие общие понятия, как классы, делегаты (с поддержкой обратных вызовов), ссылочные и размерные типы.

Важно понимать, что не во всех языках программирования .NET обязательно должны поддерживаться все типы данных, которые определены в CTS. Спецификация CLS (Common Language Specification — общая языковая спецификация ) устанавливает основные правила, определяющие законы, которым должны следовать все языки: ключевые слова, типы, примитивные типы, перегрузки методов и т. п. Спецификация CLS определяет минимальные требования, предъявляемые к языку платформы .NET. Компиляторы, удовлетворяющие этой спецификации, создают объекты, способные взаимодействовать друг с другом. Любой язык, соответствующий требованиям CLS, может использовать все возможности библиотеки FCL (Framework Class Library — библиотека классов платформы). CLS позволяет и разработчикам, и поставщикам, и производителям программного обеспечения не выходить за пределы общего набора правил для языков, компиляторов и типов данных.

Платформа .NET Framework является надстройкой над операционной системой, в качестве которой может выступать любая версия Windows 1 Благодаря архитектуре среды CLR в качестве операционной системы может выступать любая версия Unix и вообще любая ОС. . На сегодняшний день платформа .NET Framework включает в себя:

• четыре официальных языка: С#, VB.NET, Managed C++ (управляемый C++) и JScript .NET;
• объектно-ориентированную среду CLR ( Common Language Runtime ), совместно используемую этими языками для создания приложений под Windows и для Internet;
• ряд связанных между собой библиотек классов под общим именем FCL (Framework >

Отношения архитектурных компонентов платформы .NET Framework с концептуальной точки зрения представлены на рис. 1.2.

Самым важным компонентом платформы .NET Framework является CLR ( Common Language Runtime ), предоставляющая среду, в которой выполняются программы. Главная ее роль заключается в том, чтобы обнаруживать и загружать типы .NET и производить управление ими в соответствии с полученными командами. CLR включает в себя виртуальную машину, во многих отношениях аналогичную виртуальной машине Java. На верхнем уровне среда активизирует объекты, производит проверку безопасности, размещает объекты в памяти, выполняет их, а также запускает сборщик мусора.

Под сборкой мусора понимается освобождение памяти, занятой объектами, которые стали бесполезными и не используются в дальнейшей работе приложения. В ряде языков программирования (например, C/C++) память освобождает сам программист, в явной форме отдавая команды как на создание, так и на удаление объекта. В этом есть своя логика — «я тебя породил, я тебя и убью». Однако в CLR задача сборки мусора (и другие вопросы, связанные с использованием памяти) решается в нужное время и в нужном месте исполнительной средой, ответственной за выполнение вычислений.

На рис. 1.2 над уровнем CLR находится набор базовых классов платформы, над ним расположены слой классов данных и XML, а также слой классов для создания Web-служб (Web Services), Web- и Windows-приложений (Web Forms и Windows Forms). Собранные воедино, эти классы известны под общим именем FCL (Framework Class Library). Это одна из самых больших библиотек классов в истории программирования. Она открывает доступ к системным функциям, включая и те, что прежде были доступны только через API Windows, а также к прикладным функциям для Web-разработки (ASP.NET), доступа к данным (ADO.NET), обеспечения безопасности и удаленного управления. Имея в своем составе более 4000 классов, библиотека FCL способствует быстрой разработке настольных, клиент-серверных и других приложений и Web-служб.

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

Над этим уровнем находится уровень классов, которые расширяют базовые классы с целью обеспечения управления данными и XML. Классы данных позволяют реализовать управление информацией, хранящейся в серверных базах данных. В число этих классов входят классы SQL (Structured Query Language, язык структурированных запросов), дающие программисту возможность обращаться к долговременным хранилищам данных через стандартный интерфейс SQL. Кроме того, набор классов, называемый ADO.NET, позволяет оперировать постоянными данными. Платформа .NET Framework поддерживает также целый ряд классов, позволяющих манипулировать XML-данными и выполнять поиск и преобразования XML.

Базовые классы, классы данных и XML расширяются классами, предназначенными для построения приложений на основе трех различных технологий: Web Services (Web-службы), Web Forms (Web-формы) и Windows Forms (Windows-формы). Web-службы включают в себя ряд классов, поддерживающих разработку облегченных распределяемых компонентов, которые могут работать даже с брандмауэрами и программами трансляции сетевых адресов (NAT). Поскольку Web-службы применяют в качестве базовых протоколов связи стандартные протоколы HTTP и SOAP, эти компоненты поддерживают в киберпространстве подход «Plug & Play».

Инструментальные средства Web Forms и Windows Forms позволяют применять технику RAD ( Rapid Application Development — быстрая разработка приложений) для построения Web- и Windows-приложений. Эта техника сводится к перетаскиванию элементов управления с панели инструментов на форму, двойному щелчку по элементу и написанию кода, который обрабатывает события, связанные с этим элементом.

Внутреннее устройство ASP.NET: архитектура запроса

Written on 14 Ноября 2013 . Posted in ASP.NET

Далее подробно объяснена архитектура запроса ASP.NET.

Введение

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

Данная статья изучает, как ASP.NET (и IIS) обрабатывает запросы. Подробно рассмотрено, что происходит внутри архитектуры ASP.NET с момента ухода запроса из браузера до того, как он пройдет сквозь среду выполнения ASP.NET.

Замечание: После того как запрос покинет среду выполнения ASP.NET, начинает выполняться модель страницы ASP.NET. Это выходит за рамки данной статьи, но будет темой следующей статьи.

Браузер выдает запрос

Процесс начинается, как только пользователь запросит ресурс ASP.NET посредством браузера. Например, пользователь запросил следующий URL: http://www.myserver.com/myapplication/mypage.aspx. Запрос достигнет “myserver”, где установлены Windows Server 2003 и IIS 6.0.

Драйвер http.sys режима ядра перехватывает запрос

Как только запрос достигает IIS, запрос обнаруживается драйвером режима ядра http.sys. Дальше рассказано, что такое драйвер режима ядра http.sys и что он делает.

В общем, Windows предоставляет два режима: режим пользователя и режим ядра. Пользовательские приложения работают в режиме пользователя, а код операционной системы работает в режиме ядра. Если пользовательскому приложению надо работать непосредственно с оборудованием, эту конкретную операцию выполняет процесс режима ядра. Очевидное назначение этих режимов – защитить компоненты операционной системы от повреждения пользовательскими приложениями. Теперь, когда ясно, что такое режим пользователя и режим ядра, в чем заключается роль драйвера режима ядра http.sys?

При создании нового веб-сайта IIS IIS регистрирует сайт в http.sys, который далее получает все запросы HTTP для любого веб-приложения внутри сайта. http.sys работает как ретранслятор, направляя запросы HTTP процессу режима пользователя, выполняющего веб-приложение. В данном случае процесс режима пользователя является рабочим процессом, выполняющим пул приложений, в котором работает веб-приложение. http.sys реализует механизм ведения очередей, создавая столько очередей, сколько пулов приложений имеется в IIS.

Продолжая пример, как только запрос достигает “myserver”, http.sys перехватывает запрос. Допустим, “myapplication” настроено на работу в пуле приложений “myapplicationpool”; в таком случае http.sys проверяет очередь запросов “myapplicationpool” и пересылает запрос рабочему процессу, в котором работает “myapplicationpool”.

Запрос пересылается пулу приложений

Запрос пересылается пулу приложений, как сказано выше. Каждым пулом приложений управляет экземпляр рабочего процесса “w3wp.exe”. По умолчанию “w3wp.exe” выполняется под учетной записью “NetworkService”. Это можно изменить следующим образом: щелкнуть правой кнопкой мыши по пулу приложений, вмещающему приложение—Свойства—вкладка Идентичность. Вспомните, что пулом приложений управляет рабочий процесс “w3wp.exe”. Сейчас рабочий процесс берет управление на себя.

Рабочий процесс загружает ASP.NET ISAPI

Рабочий процесс “w3wp.exe” ищет URL запроса, чтобы загрузить нужное расширение ISAPI. Запрошенный ресурс в URL — “mypage.aspx”. Что происходит дальше? Полный разбор расширений ISAPI (и фильтров) не входит в статью, но вкратце, расширения ISAPI являются способом, посредством которого IIS обрабатывает запросы на разные ресурсы. После установки ASP.NET он устанавливает свое собственное расширение ISAPI (aspnet_isapi.dll) и добавляет привязку в IIS. IIS увязывает разные расширения с их расширениями ISAPI. Привязки в IIS можно посмотреть так: щелкнуть правой кнопкой мыши по веб-сайту-Свойства-вкладка Домашний каталог-кнопка Конфигурация-вкладка Привязки. Рисунок ниже показывает привязки:

Как видно, расширение “.aspx” увязано с расширением aspnet_isapi.dll. Рабочий процесс передает запрос расширению aspnet_isapi. Расширение aspnet_isapi, в свою очередь, загружает среду выполнения HTTP, и начинается обработка запроса.

Перед изучением того, что происходит внутри среды выполнения HTTP, рассмотрены детали того, как рабочий процесс загружает веб-приложение. Рабочий процесс загружает сборку веб-приложения, выделяя один домен приложения для приложения. Когда рабочий процесс запускает веб-приложение (в его домене приложения), веб-приложение наследует идентичность процесса (NetworkService по умолчанию), если перевоплощение запрещено. Но если перевоплощение разрешено, каждое веб-приложение работает под учетной записью, аутентифицированной IIS, или под учетной записью пользователя, настроенной в web.config.

•
o Если IIS разрешает только анонимный доступ, переданной веб-приложению идентичностью будет [machine]IUSR_[machine].
o Если только встроенная аутентификация Windows разрешена в IIS, переданной веб-приложению идентичностью будет аутентифицированный пользователь Windows.
o Если разрешены встроенная аутентификация Windows и анонимный доступ, переданная веб-приложению идентичность будет зависеть от той, которая была аутентифицирована IIS. IIS сначала пытается использовать анонимный доступ, чтобы предоставить пользователю доступ к ресурсу веб-приложения. Если эта попытка проваливается, то он пытается использовать аутентификацию Windows
•
o Позволяет веб-приложению работать под конкретной идентичностью.

Замечание: IIS 6.0 и IIS 5.0 по-разному обрабатывают запросы. Режим ядра http.sys реализован только в IIS 6.0. Такого свойства у IIS 5.0 нет. В IIS 5.0 запрос перехватывается непосредственно модулем aspnet_asapi, передающим запрос рабочему процессу. Рабочий процесс и модуль ISAPI взаимодействуют посредством конвейеров, приводя к издержкам вызова. Более того, один экземпляр рабочего процесса обслуживает все веб-приложения; нет пулов приложений. Модель IIS 6.0 намного лучше модули IIS 5.0. Рабочим процессом в IIS 5.0 является “aspnet_wp.exe”, в отличие от “w3wp.exe” в IIS 6.0. Рабочий процесс “aspnet_wp.exe” работает под стандартной учетной записью “ASPNET”, в отличие от “NetworkService” в IIS 6.0. Можно изменить эту учетную запись, найдя элемент

в файле “machine.config”.

Замечание: IIS 7.0 предоставляет два способа обработки запросов ASP.NET. Первый – классический способ, работающий так же, как в IIS 6.0; полезен для совместимости. Второй – новый комплексный способ, в котором ASP.NET и IIS входят в один и тот же конвейер обработки запроса. Во втором способе модули и обработчики .NET подключаются непосредственно к общему конвейеру обработки запроса, что эффективней способа IIS 6.0.

В среду выполнения HTTP

Обобщено, что пока произошло: запрос был передан от браузера к http.sys, передавшему запрос пулу приложений. Рабочий процесс, управляющий пулом приложений, изучает URL запроса и использует привязку расширения приложения IIS для загрузки ASP.NET ISAPI “aspnet_isapi.dll”. ASP.NET ISAPI загружает среду выполнения HTTP, также называемую средой выполнения ASP.NET.

Начинается изучение того, что происходит внутри HTTP. Точка входа среды выполнения — класс HttpRuntime. Метод HttpRuntime.ProcessRequest сообщает о начале обработки. В следующих подразделах рассмотрено, что происходит внутри среды выполнения после вызова метода ProcessRequest:

Создается новый экземпляр HttpContext запроса

HttpContext существует в течение времени жизни запроса и доступен через статическое свойство HttpContext.Current. Объект HttpContext представляет контекст активного сейчас запроса, так как он содержит ссылки на объекты, к которым можно обратиться в течение времени жизни запроса, а именно Request,Response, Application, Server и Cache. В любой момент при обработке запроса HttpContext.Current дает доступ ко всем перечисленным объектам. Более того, объект HttpContext содержит коллекцию Items, которую можно использовать для хранения специфичной информации запроса.

HttpRuntime советует классу HttpApplicationFactory загрузить объект HttpApplication

Класс HttpApplicationFactory создает пул объектов HttpApplication для приложения ASP.NET и связывает каждый запрос с объектом HttpApplication из того пула. Если в момент запроса в пуле нет объектов, то HttpApplicationFactory создает объект и передает его запросу. В результате запрос направляется приложению, работающему в пространстве AppDomain, и объект HttpApplication назначается для запроса. Теперь, когда ясно, что происходит, возникает вопрос, зачем нужен объект HttpApplication. HttpApplication – внешний контейнер для конкретного веб-приложения, увязанный с классом, определенным в Global.asax. При изучении файла Global.asax выясняется, что он унаследован от класса System.Web.HttpApplication. Есть набор предопределенных событий, возбуждающихся в течение времени жизни запроса; эти события представлены в файле Global.asax. HttpApplication служит контроллером этих событий. К тому же, HttpApplication хранит список сконфигурированных HttpModules, загружаемых динамически в ходе обработки запроса. Где выполняются эти события и HttpModules и чем именно являются HttpModules и HttpHandlers? Ответы на эти вопросы находятся внутри конвейера HTTP:

Внутри конвейера HTTP

Конвейер HTTP является, как намекает имя, конвейером для обработки запроса. Он называется конвейером, потому что содержит набор HttpModules, перехватывающих запрос на пути к HttpHandler. HTTPModules являются классами, имеющими доступ к входящему запросу. Эти модули проверяют входящий запрос и принимают решения, влияющие на внутренний поток запроса. Пройдя через заданные HTTPModules, запрос достигает обработчика HTTP, чьей задачей является генерация вывода, отправляемого обратно запрашивающему браузеру.

Запрос проходит через модули HTTP

HttpModules конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). В ASP.NET есть много встроенных HttpModules, осуществляющих доступ к запросу и выполняющих разные функции. Этими HttpModules являются аутентификация, управление состоянием и модули кеширования. ASP.NET 2.0 добавляет дополнительные модули, а именно членство, управление ролями и персонализация. Рисунок ниже взят из файла “machine.config” и показывает, как определены встроенные модули:

Разработчики могут написать свои собственные модули и подключить их в “machine.config”, чтобы применить модули ко всем приложениям, или в “web.config” конкретного приложения, чтобы применить модули только к нему. Запросы внутри конвейера HTTP проходят через все модули, определенные в “machine.config” и “web.config”. Как сказано в предыдущем разделе, эти модули хранятся внутри HttpApplication и динамически загружаются при выполнении.

Запрос попадает в обработчик HTTP

Обработчики HTTP являются конечными точками в конвейере HTTP. Задача обработчика HTTP – сгенерировать вывод для запрошенного ресурса. Для страниц ASPX это означает перевод страниц в HTML и возврат этого HTML. Обработчики HTTP конфигурируются на уровне машины (machine.config) и на уровне приложения (web.config). Рисунок ниже взят из “machine.config” и показывает, как устанавливаются обработчики HTTP.

Как видно на рисунке выше, разные ресурсы настраиваются на использование разных обработчиков. Страницы ASP.NET ASPX настроены на использование “PageHandlerFactory”. Задача “PageHandlerFactory” – предоставить экземпляр HTTP, способный обработать запрос. “PageHandleFactory” пытается найти скомпилированный класс, представляющий запрошенную страницу “mypage.aspx”. В случае успеха он передает данный скомпилированный класс в качестве обработчика HTTP. Если нет скомпилированного класса, представляющего запрошенную страницу, потому что запрос первый или потому что страницу изменили с момента последнего запроса, то “PageHandlerFactory” компилирует запрошенную страницу “mypage.aspx” и возвращает скомпилированный класс. Все последующие запросы будут обслуживаться тем же самым скомпилированным классом, пока страницу не изменят.

Возникает вопрос, почему “PageHandlerFactory” возвращает экземпляр скомпилированного класса, выступающий обработчиком запроса. Является ли скомпилированным класс фактическим обработчиком HTTP? Ответ очевиден из изучения отделенного кода страницы, “mypage.aspx.cs”. Страница унаследована от класса “System.Web.UI.Page”; этот класс реализует интерфейс “IHttpHandler”, что делает его пригодным в качестве обработчика HTTP.

Замечание: Компиляция страницы не входит в эту статью, но будет описана в следующей статье, рассматривающей модель страницы ASP.NET.

Начинается выполнение страницы

Как объяснить маме, что такое архитектура приложения?

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

Это тема сложна для понимания, даже если вы немного разбираетесь в технологиях. Но если коротко, архитектура приложения − это набор методов и шаблонов, которые помогают разработчикам создавать структурированные приложения. В этом материале специалисты из команды Crypterium разбирают тему архитектуры и рассказывают о подходе компании к её разработке.

Front-end и Back-bend

Давайте в объяснении того, что есть архитектура приложения, отойдем от технических терминов и проведем аналогию с повседневной жизнью. Посмотрите на свое тело. Все, что находится снаружи, − голова и тело, − это front, а всё, что внутри, − сердце, мозг и внутренние органы, − back.

Crypterium занимается разработкой платёжного сервиса. Back-end команда разрабатывает технологии, отвечающие за обмен, передачу, хранение и прочее, а Front-end следят за тем, чтобы пользователю было удобно взаимодействовать с функциями приложения.

Ключевые принципы разработки Agile-приложения

Теперь, когда мы разобрались с различием front и back частей, давайте рассмотрим два ключевых подхода, которые используют современные разработчики: API First и Loose Coupling. Они позволяют программистам легко менять структуру приложения. Более того, они делают так, что каждая отдельная часть приложения может быть изменена без затрагивания остальных частей.

Метод API First отвечает за высокую скорость работы и нововведения. Идея в том, чтобы ввести данные и получить в ответ API, необходимый для Front-end и Back-end команд разработки: это позволяет им одновременно писать код и параллельно тестировать его. Преимущества метода заключаются в снижении издержек на разработку, увеличении скорости и снижении рисков.

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

Одна из функций, за которую команда приложения любит подход API First, называется Swagger − это open-source фреймворк, который помогает разработчикам строить архитектуру, проектировать и создавать документацию для своих приложений. Swagger автоматически генерирует описание API для большинства языков и фреймворков, для обеих − Front-end и Back-end − команд.

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

Система Loose Coupling уменьшает риск случайного изменения отдельных объектов, без изменения других − так как в приложении всё взаимосвязано, это может привести к поломкам и уязвимостям. Так вот, благодаря возможности ограничения работы отдельных соединений, система помогает найти и решить проблему быстрее, прямо во время тестирования.

Микросервисы против монолита

Благодаря принципам API First и Loose Coupling, приложение может выступать микросервисом − приложением, состоящем из независимых служб, способных работать самостоятельно, свободно масштабироваться на разных устройствах.

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

Представьте себе умный дом, где все можно контролировать и управлять с помощью одного устройства. Допустим, это устройство − * core *, а управляемыми элементами являются * services *. С помощью основного устройства вы можете открывать окна, включать телевизор или даже закрывать шторы. Так работает архитектура микросервисов.

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

Представьте себе многослойный шоколадный торт. Каждый новый слой делает торт ещё вкуснее, но вы не можете добавить слой с клубникой в середину, не изменив вкус и структуру торта. Можно считать, что у торта − монолитная архитектура.

.NET Core против JVM-платформ

Мультифункциональные приложения, например, мобильные кошельки, обычно связаны ещё с сотнями различных служб. Чтобы структурировать работу приложения, в Crypterium разделили команду Back-end разработчиков на две. Одна работает только над ядром продукта, вторая − над всем остальным, то есть авторизацией, коммуникацией и так далее.

Каждая команда использует собственные фреймворки. Основная выбрала .NET Core − платформу, которая характеризуется быстрой разработкой, отладкой и тестированием. Вдобавок, она высокопроизводительна, подходит для работы с кросс-платформенными приложениями и ориентирована на микросервисы. В то же время, остальные сервисы разрабатываются с помощью JVM-фреймворка, который, кстати, является прямым конкурентом продукту от Oracle.

Использование сразу двух популярных фреймворков позволяет выбирать из большего количества специалистов на рынке. Для .NET мы используем языки C, а для JVM − Kotlin и Java. Кроме того, эти же языки используются Android-разработчиками.

Функции Front-end команды

Команда Front-end специалистов следит за тем, чтобы приложение было удобным, а интерфейс − интуитивно-понятным и быстрым.

Android-версия приложения Crypterium основана на языках Java и Kotlin (как и среда JVM), а приложение iOS − на новом, простом в использовании языке программирования Swift. Функции языка включают в себя контроль доступа, управление памятью, отладку, цепочку вызовов и протокол-ориентированное программирование.

MVVM и роутинг для iOS

Команда разработчиков Crypterium для iOS, выбрала стиль архитектуры MVVM и роутинг. Благодаря структуре, архитектуры удобны и для разработчиков, и для пользователей.

MVVM − это Model-View-ViewModel, где Model означает информацию о продукте, а View показывает, как клиенты видят продукт. В MVVM есть структура слоев: первый уровень − UI (пользовательский интерфейс). Другие уровни содержат сетевые и логические сервисы. Роутинг отвечает за технические процессы − действия пользователей, перемещения внутри приложения, регулируются именно им.

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

Чистая архитектура для Android

Чтобы повысить простоту обслуживания и гибкость приложений, команда Android решила использовать метод под названием «Чистая архитектура». Он гарантирует отсутствие ненужных связей и делает приложение более тестируемым.

Результатом является чистое, новое, свежее, простое в использовании приложение для Android с четырьмя уровнями:

• веб, базы данных, пользовательский интерфейс;
• шлюзы, презентаторы;
• варианты использования;
• юридическая информация.

Заключение

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

Если вам понравился материал о том, что такое архитектура приложения, посмотрите следующее:

Источник: Объясни это маме − что такое архитектура приложения on Hackernoon

Архитектура приложений: концептуальные слои и договоренности по их использованию

ru-RU | создано: 03.02.2017 | опубликовано: 03.02.2017 | обновлено: 23.03.2019 | просмотров за всё время: 6244

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

Пример договоренностей

Разберем для примера общеизвестный фреймворк ASP.NET MVC. Если вы работали с этой системой, то наверное обратили внимание на то, что в проекте, который создается Visual Studio по умолчанию присутствуют папки Models, Views, Controllers. Это первая договоренность, что каждый тип файла (класса) лежит в своей собственной папке.

В первых версиях фреймворка ASP.NET MVC контролеры могли лежать только в папке Controllers. Позже это ограничение было снято.

Eсли при разработки какого-либо метода контролера вы попробуете создать метод и открыть его, не создав представление (View) этого метода, то система выдаст вам сообщение об ошибке:

Обратите внимание на то, где система попыталась найти «потерянное» представление, прежде чем выдать сообщение. Такое поведение также предопределено договоренностями фреймворка. В данном случае, правило гласит, что если представление (View) не найдено в папке контролера Home, то следует ее поискать сначала в папке Shared, потом всё то же самое, но уже с другим расширением для другого движка рендеринга (при наличии подключенных нескольких движков рендеринга разметки). На самом деле договоренностей подобного рода в ASP.NET MVC очень большое количество. И тем больше вы их будете встречать, чем глубже будете погружаться в «дебри» фреймворка.

ASP.NET MVC фреймворк как и все фреймворки, во всяком случае в большинстве своем, построены на основе парадигмы «соглашения по конфигрурации» (configuration over convention).

Принцип соглашения по конфигрурации как правило, применяется в разработке фреймворков, и позволяет сократить количество требуемой конфигурации без потери гибкости.

Суть данной статьи показать, что использование упомянутой выше парадигмы применительно к коллективной разработке, может существенно ускорить (упростить) процесс разработки приложений, особенно если в разработке учавствует большое количество разработчиков. «Соглашения по конфигурации» позволяют решить вопросы, на которые зачастую тратятся драгоценные минуты, часы и даже дни и недели. Например, часто возникает вопрос, как правильно назвать создаваемый класс, свойство, метод, проект, переменную, решение (solution)? Сколько разработчиков, столько и вариантов, если не договорится заранее о правилах именования. А если в коллектив пришел новый разработчик, то как он может начать писать корректный код, не зная о правилах, по которым этот код пишется? Безусловно, существуют огромное количество вспомогательных утилит (например, StyleCop), которые упрощают задачу, но и они бывают бессильны в некоторых случаях.

Надо признать, что с каждым годом задачи для разработчиков усложняются в силу сложности задач, которые решает бизнес. Более сложные задачи требуют более комплексных подходов в их решении. Зачастую бывает недостаточно создать приложение (программу, систему), обычно требуется ее поддерживать и развивать после выпуска окончательной версии. И если в вашем коллективе существуют подобные правила и договоренности, вам будет гораздо проще найти место в коде, правильный контролер и метод. Договоренности и правила именования помогают быстрее ориентироваться в коде.

Немного истории

В качестве примера нарастания сложности, приведу эволюцию паттернов Business Logic, которые описывают, как и где дожна быть релизована бизнес-логика. Паттерны для организации бизнес-уровеня (бизнес-логика) с течением времени претерпели существенные изменения, от простого к сложному. Более того, на этом эволюция не остановилась.

Каждый из них подробно описал Martin Fowler, поэтому я не буду на них останавливаться подробно. Эволюция говорит о том, что программировать системы, которые манипулируют данными становится всё сложнее. Надо понимать, что использование паттернов проектирования для построения архитектуры сложных систем существенно упрощает дальнейшую поддержку системы (maintainability) и введение нового функционала, но при этом разработка сильно усложняется. Для упрощения этой самой разработки, я и предлагаю использовать договоренности правила, то есть «соглашения по конфигурации» но применительно к процессу написания кода.

Что говорить, если уже не только среди разработчиков, но и среди заказчиков всё чаще и чаще слышатся подобные слова и фразы: ORM, Repository, Business Layer, Abstraction​ и Dependency Injection, MVVM и другие.

Среди разработчиков ходят давнишние споры относительно того, следует ли использовать дополнительную «прослойку» типа ORM между базами данных и DAL. Например, на sql.ru или на habrahabr.ru частенько поднимаются темы. Лейтмотивом в подобных спорах звучит мысль: «. для сложных проектов использование ORM существенно сокращает рутину. «.

Так повелось, что с некоторого времени я перестал разделять проекты на сложные и простые, взяв за основу использование ORM для проектов любой сложности. Особенно если учесть, что ORM позволяет использовать подход CodeFirst (в частности, EntityFramework).

Осмелюсь предположить, что вы уже знакомы с паттернами проектирования, и в частности, с паттернами Repository и UnitOfWork, именно на их основе я и буду говорить о договоренностях для построения уровня доступа к данным (Data Access Layer). А также предположу, что вы имеете представление о Dependency Injection.

Использование паттернов не дает гарантии, что ваш код будет написан правильно.

Первичные правила и договоренности по именованию

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

Не устаю повторять фразу «всё уже придумано за нас», повторю ее и в данном контексте. В мире разработки уже существуют договоренности об именовании, например от компания Microsoft или те, другой вариант в Wikipedia. За основу для своих правил я взял договоренности от Microsoft. Итак, начнем.

Правила именования пространства имен для проекто компании:

✓ Название любого проекта должно начинаться с <CompanyName>. Данное правило актуально для разработчиков компании .

✓ После первого слова <CompanyName> через точку должно быть указано имя проекта.

✓ За названием проекта обязательно должна следовать название платформы.

✓ После указанной платформы части внутренней архитектуры проекта.

X Запрещается использовать знаки подчеркивания, дефисы и другие символы.

X Запрещается использовать сокращения и общеизвестные аббревиатуры

X Запрещается использовать цифры в именованиях.

X Рекомендуется избегать использования сложно составных названий в указанных частях именования

Правила именования переменных:

✓ Используйте легко читаемые имена идентификаторов. Например, свойство с именем HorizontalAlignment является более понятным, чем AlignmentHorizontal.

✓ Читабельность важнее краткости. Имя свойства CanScrollHorizontally лучше, чем ScrollableX (непрозрачными ссылка на ось x).

X Запрещается использовать знаки подчеркивания, дефисы и другие символы.

X Запрещается использовать венгерскую нотацию.

X ИЗБЕГАЙТЕ использования имен идентификаторов, конфликтующих с ключевыми словами широко используемых языков программирования.

X Не используйте аббревиатуры или сокращения как часть имени идентификатора. Например, используйте GetWindow вместо GetWin.

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

✓ Используйте семантически значимые имена вместо зарезервированных слов языка для имен типов. Например GetLength является именем лучше, чем GetInt.

✓ Используйте имя универсального типа CLR, а не имя конкретного языка, в редких случаях, когда идентификатор не имеет семантического значения за пределами своего типа. Например, преобразование в метод Int64 должен быть назван ToInt64, а не ToLong (поскольку Int64 — это имя среды CLR для C#-псевдоним long). В следующей таблице представлены некоторые базовые типы данных с помощью имен типов среды CLR (а также соответствующие имена типов для C#, Visual Basic и C++).

✓ Используйте обычные имена, таких как value или item, вместо того чтобы повторение имени типа в редких случаях, когда идентификатор не имеет семантического значения и тип параметра не имеет значения.

Примеры, которые не стоит использовать при именовании пространства имен:

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

Для примера именованя решения возмем несуществующий сайт http://project.company.ru. Проект портала на платформе ASP.NET MVC должен иметь следующие пространство имен.

Название решения (solution):

Названия проектов (projects) по типу принадлежности к уровню абстракции: