По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Model-View-Controller - популярный шаблон программирования, где логика приложения делится на три различных компонента.
В этой статье расскажем о роли компонентов архитектуры MVC, начнем с короткой истории, а далее покажем, как её можно использовать в приложении.
История паттерна Model View Controller
Модель MVC была впервые представлена в 1979 году учёным Трюгве Миккьелем Хейердалом Реенскаугом. Он хотел придумать решение, как разбить сложное пользовательское приложение на более мелкие управляемые компоненты.
Шаблон MVC был впервые использован в языке программирования Small Talk. Изначально шаблоне хотели назвать «Model-View-Editor», но затем оно было изменено на «Model-View-Controller».
В 1980-х и начале 90-х годов шаблон MVC использовался главным образом в настольных приложениях. Но к концу 1990-х годов она стала довольно популярной в разработке веб-приложений. В современных веб-приложениях шаблон MVC является популярным архитектурным дизайном для организации кода.
Ниже приведен список нескольких популярных веб-фреймворков, использующих шаблон MVC:
Ruby on Rails
ASP.NET MVC
Laravel
Angular
Какие три компонента включает в себя MVC?
Шаблон программирования MVC состоит их трёх следующих компонентов:
Model – отвечает за логику данных, лежащую в основе приложения
View – это видимая часть приложения, то с чем взаимодействует пользователь
Controller – работает как мозг приложения и обеспечивает связь между моделью и видом
Как шаблон MVC работает в веб-приложении?
Чтобы лучше понять, как работает шаблон MVC, лучше всего показать его в демонстрационном приложении.
Это приложение стека MERN (MongoDB, Express, React, Node) своего рода помощник менеджера офиса и отображает таблицу недавно нанятых тренеров средней школы.
Он также показывает, какие тренеры не сдали тесты на туберкулез, не прошли вакцинацию от Covid, не заполнили резюме и не прошли проверку.
Менеджер может отправлять напоминания по электронной почте тем тренерам, у которых отсутствуют документы.
Компонент Model
Модель отвечает за логику данных нашего приложения. Мы используем MongoDB для базы данных тренеров.
Для начала определяем свойства, которые будут применены к каждому тренеру в базе данных. У каждого тренера есть свойства name, email, program, application, backgroundCheck, tbTest и covidTest.
const coachSchema = new Schema({
name: {
type: String,
trim: true,
maxLength: 32,
required: true
},
email: {
type: String,
trim: true,
maxLength: 32,
required: true,
unique: true
},
program: {
type: String,
trim: true,
maxLength: 32,
required: true
},
application: {
type: Boolean,
required: true
},
backgroundCheck: {
type: Boolean,
required: true
},
tbTest: {
type: Boolean,
required: true
},
covidTest: {
type: Boolean,
required: true
}
}, { timestamps: true })
type: Boolean представляет значение true или false для свойств приложения, backgroundCheck, tbTest и covidTest.
Если у тренера одно из этих четырех свойств, помечены как false, это означает, что они не завершили процесс найма.
Создаем семь записей для нашей базы данных тренеров, и эта информация хранится в MongoDB Atlas.
Ниже приведен пример одной из записей базы данных.
Компонент "контроллер"" будет взаимодействовать с базой данных и получать необходимую информацию для отправки компоненту представление.
Компонент View
Компонент View (вид, представление или вью) отвечает за все визуальные аспекты приложения. Для отображения данных пользователю мы использовали React.
При первой загрузке приложения на экране отображается приветственное сообщение.
При нажатии кнопки «View Dashboard» происходит переход к таблице тренеров и списку отсутствующих документов.
Компонент Вид не взаимодействует напрямую с базой данных, поскольку это делает наш контроллер. Контроллер предоставляет эту информацию компоненту представление, чтобы ее можно было отобразить на странице.
Вот как выглядит код, когда представление выполняет вызов выборки (fetch) для получения данных от контроллера:
await fetch('https://mvc-project-backend.herokuapp.com/coaches')
Затем мы используем метод map(), чтобы пройтись по списку тренеров и отобразить их имена, адреса электронной почты и программу в виде таблицы.
coachData.map(data => (
<tr key={data._id}>
<td>{data.name}</td>
<td>{data.email}</td>
<td>{data.program}</td>
</tr>
))
Для отображения раздела отсутствующих документов мы отправляем запрос к бэкнэду и получием список тренеров, которые не заполнили анкету, не сдали тесты на туберкулез, не привиты от Covid и не прошли проверки.
Для отображения имен для каждой категории снова используется метод map().
Если нажать кнопку «Send reminder email», эта информация будет отправлена React-ом на бэкэнд. Контролер отвечает за отправку сообщения электронной почты и обмен информацией с компонентом представление о том, отправилось ли сообщение.
На основе информации, которую он получает от контроллера, во View отображается сообщение об успехе или сообщение об отказе.
Компонент Controller
Контроллер взаимодействует с компонентами «Модель» и «Представление» и выполняет все логические операции для нашего приложения. Этот раздел кода был построен в Node.JS и Express.
Контролер получает полный список тренеров из «Модели» и отправит эту информацию в «Представление». Контролер также отвечает за фильтрацию через «Модель» и предоставление списка тренеров, которые не сдали необходимые документы.
Все эти данные отправляются в «Представление», чтобы их можно было отобразить пользователю.
Что касается функциональности электронной почты, то «Контролер» перед отправкой проверяет валидность адреса электронной почты.
Для отправки электронных писем использована Nodemailer:
transporter.sendMail(mailOptions, (err) => {
if (err) {
console.log(`Applications: There was an error sending the message: ${err}`)
res.json({ status: 'Email failure' })
} else {
console.log(`Applications Success: Email was sent`)
res.json({ status: "Email sent" });
}
})
Если сообщение электронной почты успешно отправлено, пользователь получает уведомление, и сообщение электронной почты отображается в почте демонстрационной учетной записи.
Если при отправке сообщения возникает ошибка, то «Контроллер» посылает эту информацию в «Вид», чтобы пользователю отобразилось уведомление об ошибке.
Заключение
А в заключение повторим пройденное:
Model-View-Controller - популярный шаблон программирования, используемый для разделения логики приложения на три различных компонента.
Хотя шаблон MVC первоначально использовался в настольных приложениях, в конце 1990-х он стал популярным в разработке веб-приложений.
Модель отвечает за логику данных, лежащую в основе приложения.
Представление - это то, что пользователь видит в приложении и взаимодействует с ним.
Контроллер действует как мозг приложения и взаимодействует с моделью и представлением.
Веб-инфраструктуры, использующие шаблон MVC - это Ruby on Rails, ASP.NET MVC, Laravel и Angular.
Nginx - это веб-сервер на базе Linux и прокси-приложение. Nginx - это мощный инструмент для перенаправления и управления веб-трафиком. Его можно легко настроить для перенаправления незашифрованного веб-трафика HTTP на зашифрованный HTTPS-сервер.
Это руководство покажет вам, как перенаправить HTTP на HTTPS с помощью Nginx.
Что нам потребуется
Сервер Linux под управлением Nginx
Учетная запись пользователя с привилегиями sudo
Удаленный вход на веб-сервер (необязательно, требуется только в том случае, если вы не работаете непосредственно с веб-сервером)
Доступ к терминалу/командной строке (Ctrl-Alt-T или Ctrl-Alt-F2)
Редирект с HTTP на HTTPS
Для принудительного перенаправления HTTP на HTTPS вам необходимо отредактировать файл конфигурации Nginx.
В большинстве случаев вы можете найти этот файл в каталоге /etc/nginx/sites-available. Если не найдено, найдите его здесь: /etc/nginx/nginx.conf, /usr/local/nginx/conf или /usr/local/etc/nginx.
Найдя файл конфигурации Nginx, откройте его в текстовом редакторе с помощью команды:
sudo nano /etc/nginx/sites-available/server.conf
Замените местоположение фактическим местоположением и именем вашего файла конфигурации.
Когда файл конфигурации будет открыт для редактирования, вставьте один из блоков кода ниже. Как только вы закончите редактирование, сохраните файл и выйдите. Затем перезапустите службу Nginx с помощью следующей команды:
sudo service nginx restart
Перенаправить весь HTTP-трафик на HTTPS
Откройте файл конфигурации Nginx для редактирования, затем вставьте следующий код:
server {
listen 80 default_server;
server_name _;
return 301 https://$host$request_uri;
}
Вот разбивка команд:
Listen 80: Это дает команду системе перехватывать весь HTTP-трафик через порт 80
Server_name _ ;: Это будет соответствовать любому имени хоста
Return 301: Это говорит браузеру и поисковым системам, что это постоянное перенаправление
https://$host$request_uri: Это короткий код для указания версии HTTPS того, что набрал пользователь
После редактирования весь трафик сервера HTTP по умолчанию перенаправляется на HTTPS.
Примечание: Это должен быть единственный блок сервера, прослушивающий порт 80. Блок сервера - это единица кода конфигурации в Nginx. Он помечен именем и фигурными скобками.
Перенаправить определенный сайт
У вас может быть несколько серверов, но только некоторые из них могут требовать HTTPS. Укажите имя сервера в блоке сервера для перенаправления выбранного трафика:
server {
listen 80 default_server;
server_name my_app.com;
return 301 https://my_app.com$request_uri;
}
Замените имя my_app.com на имя сервера, который вы собираетесь перенаправить. Вы также можете добавить дополнительные сайты, добавив еще один блок сервера. Просто скопируйте код и измените имя сервера.
Принимать только SSL-соединения
Добавьте этот код, чтобы убедиться, что сервер будет принимать только SSL-соединения через порт 443:
server {
listen 443 ssl default_server;
server_name my_app.com;
}
server {
listen 443 ssl;
server_name my_website.com;
}
Этот блок кода настроит два веб-сайта, my_app.com и my_website.com, на прием только SSL-соединений. Вы можете добавить дополнительные сайты, используя дополнительные блоки серверов.
Редирект страниц
Вы можете использовать rewrite для быстрого управления 301 (постоянным) или 302 (временным) перенаправлением:
Location /index.html {
rewrite ^/oldURL$ https://www.your_domain.com/newURL redirect;
}
В большинстве случаев это будет index.html, но вы можете указать любой путь или шаблон.
Обратите внимание, что команда rewrite должна использоваться только с перенаправлениями 301 или 302.
Как перенаправить домен с помощью Nginx
Это полезно, если вы сменили домен (например с .org на .com). Nginx также можно использовать для перенаправления со старого доменного имени на новое доменное имя.
server {
listen 80;
listen 443 ssl;
server_name www.old_company.com;
return 301 $scheme://www.new_company.com$request_uri;
}
В большинстве случаев команда return предпочтительнее команды rewrite.
Редирект с сайта www на сайт без www
Этот процесс аналогичен стандартному перенаправлению страницы:
server {
server_name www.new_company.com;
return 301 $scheme://new_company.com$request_uri;
}
Причины для перенаправления трафика
Есть несколько причин для перенаправления HTTP-трафика на HTTPS:
Принудительное установление более безопасного зашифрованного соединения.
Сохранение страницы с хорошим SEO-рейтингом, но перенаправление своего трафика на новую страницу.
Уведомлять и временно отправлять трафик на страницу «на обслуживании».
Постоянно отправлять трафик с одного сайта на другой, например после корпоративного слияния.
Заключение
Теперь вы знаете, как перенаправить HTTP на HTTPS в Nginx. Редактируя файл конфигурации, вы можете отправлять трафик из определенного места назначения на другой сайт и принудительно использовать сертификаты SSL. Это поможет вам безопасно управлять изменениями на вашем сайте, не нарушая пользовательский опыт.
Использование REST API является полезной функцией для реализации ваших сценариев. Вы можете получить доступ к новым функциям, а также расширить возможности создания новых, более продвинутых сценариев.
Опыт многих пользователей показывает, что, когда начинаешь использовать REST API в скриптах, то чувствуешь себя довольно неуклюже и непривычно. В этой заметке мы обсудим:
Что такое REST API
Как читать документацию
Как использовать API REST с PowerShell
Некоторые советы и подсказки, как облегчить и улучшить практику
Что такое "REST"?
REST, или RESTful API, это API, который использует HTTP запросы для получения, добавления, удаления или манипулирования данными в различных сервисах.
Как правило, то, что нужно сделать с данными, решается тем, какой HTTP-метод вы используете. Вот краткий список методов HTTP и их применение в REST API:
GET-Read
POST-Create
PATCH-Partial update/modify
PUT-Update/replace
DELETE-Remove
Данные, которые возвращает API REST, обычно представляются в формате JSON.
Теперь давайте начнём с нашего первого API запроса!
Что такое API
Работа с документацией
Для использования различных API REST необходимо научиться читать и интерпретировать документацию. К счастью, если вы знаете, как читать один тип документации, вы сможете быстро научиться читать другие.
В этой статье мы используем petstore.swagger.io, так как он использует популярный фреймворк Swagger, который довольно часто используется в разработке.
На предыдущем рисунке показана наиболее важная информация о конечных точках REST API:
HTTP-метод-GET/POST/DELETE и т.д.
URL-адрес, связанный с конечной точкой REST API (Базовый URL, как правило, представлен в верхней части страницы документации)
Краткое описание
Подробности
Первая страница документации просто замечательная, и, как правило, с помощью этой информации можно выполнить большинство запросов, требующих использования метода HTTP GET. Но такие методы, как POST и SET, обычно требуют, чтобы вы щелкнули и развернули строку, чтобы получить больше информации.
Если вы нажмете на одну из строк, то получите информацию, которая выглядит так:
Здесь мы представили конечную точку REST, которая может создать новый объект pet. Здесь указывается, как должен выглядеть JSON, предоставленный в теле POST, и какой тип контента он принимает. Другие конечные точки REST указывают, что это за параметры, каким типом данных они должны быть и т.д.
Это основы для чтения документации. Теперь, когда общие принцип более-менее ясны, пора начать использовать REST API с PowerShell.
Получение первых данных (GET)
Используя REST API с PowerShell обычно довольно просто, используется встроенные командлеты, таким образом, нет необходимости в дополнительных модулях. Мы собираемся извлечь данные с помощью метода GET в конечной точке /pet/{ petId}.
Если развернуть конечную точку /pet/{ petId} в документации, можно увидеть, что {petId} на самом деле является параметром, который принимает целое число.
Это делает URL-адрес для выборки объекта pet с идентификатором 1: https://petstore.swagger.io/v2/pet/1
В документации SWAGGER REST API обычно отображается базовый URL-адрес в верхней части страницы.
Теперь начнем с PowerShell. Откройте окно терминала и введите:
PS51 > Invoke-RestMethod -Method GET -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1"
id : 1
category : @{id=0; name=string}
name : doggie
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
Поскольку в ответе от сервера возвращается тип содержимого "application/json" используется метод Invoke-RestMethod, который автоматически преобразует возвращаемый JSON в объект.
Ошибка 404 Not found, как правило, означает, что объект не найден или URL-адрес введен неправильно.
Итак, мы выполнили первый вызов REST API. Но возможности метода GET для получения данных довольно ограничены, так что давайте создадим что-нибудь с помощью метода POST.
Создание объекта методом POST
Метод POST чаще всего используется для создания, например, пользователей или записей и т.д. Запрос POST отправляет BODY, содержащий информацию, конечной точке REST, обычно в формате JSON, но он также может быть в виде формы с кодировкой URL.
Вы узнаете, как создать объект JSON, который можно отправить в конечную точку/pet.
Можно увидеть, как должен выглядеть JSON, если развернуть строку POST/pet в документации.
Начнем с создания хэштаблицы, который можно преобразовать в объект JSON. Raw JSON следует избегать в скриптах PowerShell, поскольку он ограничивает его возможности.
$Body = @{
id = 19
category = @{
id = 45
name = "Whatever"
}
name = "Dawg"
photoUrls = @(
"string"
)
tags = @(
@{
id = 0
name = "string"
}
)
status = "available"
}
Если вам трудно создать хештаблицу, который преобразуется в нужный JSON, установите модуль PsdKit и используйте команду $ JsonString | ThreadTo-Psd
Теперь имеется хэш-таблица, которую можно преобразовать в строку JSON и POST в конечную точку/pet:
$JsonBody = $Body | ConvertTo-Json
$Uri = "https://petstore.swagger.io/v2/pet"
Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method Post -Body $JsonBody
id : 19
category : @{id=45; name=Whatever}
name : Dawg
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
При создании объекта он обычно получает созданный для подтверждения объект. Использование DELETE. Метод DELETE используется для удаления данных, а применение очень схоже с методом GET.
PS51 > Invoke-RestMethod -Method DELETE -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/1"
Только убедитесь, что не удалите ничего важного
Использование PUT
Метод PUT используется для обновления данных. Это делается аналогично методу POST путем представления полного или частичного объекта JSON:
PS51> $Body = [PSCustomObject]@{
id = 19
name = "Dawg with a new name"
}
PS51> $JsonBody = $Body | ConvertTo-Json
PS51> $Uri = "https://petstore.swagger.io/v2/pet"
PS51> Invoke-RestMethod -ContentType "application/json" -Uri $Uri -Method PUT -Body $JsonBody
id name photoUrls tags
-- ---- --------- ----
19 Dawg with a new name {} {}
Обычно API REST возвращает объект JSON с использованными и/или обновленными данными. Можно увидеть, что объект был обновлен с помощью метода GET:
PS 51> Invoke-RestMethod -ContentType "application/json" -Uri "https://petstore.swagger.io/v2/pet/19"
id : 19
category : @{id=45; name=Whatever}
name : Dawg with a new name
photoUrls : {string}
tags : {@{id=0; name=string}}
status : available
Создание функций
Писать эти команды каждый раз вручную может стать довольно утомительным и на самом деле не масштабируемым. Если мы вызываем конечную точку несколько раз, то лучше создать для нее функцию. Это довольно просто и нужно написать всего несколько строк:
Function Get-PetstorePet {
[cmdletbinding()]
param(
# Id of the pet
[Parameter(Mandatory,ValueFromPipeline)]
[int]$Id
)
Begin{}
Process{
$RestMethodParams = @{
Uri = "https://petstore.swagger.io/v2/pet/$Id"
ContentType = "application/json"
Method = "GET"
}
Invoke-RestMethod @RestMethodParams
}
End{}
}
После создания функции ее можно вызвать в сценарии:
PS51> Get-PetstorePet -Id 1
id name photoUrls tags
-- ---- --------- ----
1 Doggie {http://picture.url} {}
Это можно сделать и для метода POST для создания нового объекта pet в Petstore:
Function Add-PetstorePet {
[cmdletbinding()]
param(
# Id of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[int]$Id,
# Name of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$Name,
# Status of the pet (available, sold etc)
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$Status,
# Id of the pet category
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[int]$CategoryId,
# Name of the pet category
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string]$CategoryName,
# URLs to photos of the pet
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[string[]]$PhotoUrls,
# Tags of the pets as hashtable array: @{Id=1;Name="Dog"}
[Parameter(Mandatory,ValueFromPipelineByPropertyName)]
[Hashtable[]]$Tags
)
Begin{}
Process{
$Body = @{
id = $Id
category = @{
id = $CategoryId
name = $CategoryName
}
name = $Name
photoUrls = $PhotoUrls
tags = $Tags
status = $Status
}
$BodyJson = $Body | ConvertTo-Json
$RestMethodParams = @{
Uri = "https://petstore.swagger.io/v2/pet/"
ContentType = "application/json"
Method = "Post"
Body = $BodyJson
}
Invoke-RestMethod @RestMethodParams
}
End{}
}
И вызов этой функции PowerShell намного упрощает задачу:
PS51> $AddPetStorePetsParams = @{
Id = 44
Name = "Birdie"
Status = "available"
CategoryId = 50
CategoryName = "Hawks"
PhotoUrls = "https://images.contoso.com/hawk.jpg"
Tags = @(
@{
Id=10
Name="Not eagles"
}
)
}
PS51> Add-PetStorePet @AddPetStorePetsParams
id : 44
category : @{id=50; name=Hawks}
name : Birdie
photoUrls : {https://images.domain.com/hawk.jpg}
tags : {@{id=0}}
status : available
Возможно, что многие модули, которые вы ежедневно используете, состоят из функций, который за кулисами используют REST API.
Заключение
Обучение работы с REST API, главным образом основано на чтении документации. Мы использовали документацию на основе SWAGGER в этом посте, так как она представляет, как могут выглядеть другие стили документации.
Кроме того, преобразование вызовов API в функцию может сэкономить много времени, упростить работу и очистить сценарии.