Car sharing center
1.0.0
Основная идея проеат: Разработать приложение-сервис каршеринговой службы с отображением доступных автомобилей на карте. По содержанию - всё, что можно сопоставить с сущностью Vehicles: Автомобили, мотоциклы, любые транспортные средства и тд. Приложение должно быть многофункциональным: Необходимо наличие большого числа страниц с возможностью получать, добавлять, изменять и удалять сущности.
pager-а на страницу.httpContextAccessor.UserStatusProvider. Добавление JS сообщений с использованием сервиса SweetAlert2.ReadMe.Stripe к проекту. Добавление функционала выбора времени и даты на страницу с оформлением заказа.JS кода (разнёс по файлам).Brief Description аккаунта разместившего автомобиль пользователя. Начал делать часть с выставлением рейтинга для автомобилей..NET 7. Работа над поисковой системой страницы каталога.RepositoryProvider и сведение всей функциональности под него.JWToken Authentication на контроллеры Web-приложения.JWToken и настройка отображения страницы с ошибкой на стороне клиента.JSON-файлах к хранению в MongoDB Local.MongoDB Atlas с целью дальнейшей работы с облачным сервисом.UI. Изменение маркера Google Maps API с красного на автомобиль с названием и изображением.Официальное начало стажировки
Web-приложения к полноценной Clean Architecture.Domain Layer и настройка первых моделей. Модели создаются в стиле Rich Domain Models заместо Anemic Domain Models.Application и Infrastructure Layers, а также настройка первых взаимодействий с сервисом и настройка DI.PublicAPI.endpoints и их ручное тестирование.Errors Handling и его обработки.Errors Handling в часть модели Vehicle.endpoints.Azure Key Vault для получения секретных данных с Azure. Внедрение битовых флагов как одного из вариантов хранения информации об автомобилях.endpoints в CustomerController и их ручное тестирование.endpoints в VehicleController и их ручное тестирование.IHttpClientFactory для создания клиентов для отправки requests в сторону PublicAPI. Настройка Polly для недетерминированной отправке сообщений с возможностью их ожидания и повторной отправки в случае критических ситуаций.PublicApi вместе с Web-частью и проверка endpoints и межпрограммной сериализации и десериализации.JWToken с сервера на стороне клиента при успешном входе в аккаунт.UI страниц регистрации, авторизации и добавления нового автомобиля.errors handling на клиентской части при добавлении нового автомобиля.html-страниц и некоторых endpoints.Bootstrap 5+ и переделывание логики страниц регистрации и авторизации.GoogleMaps Api и исправление ошибок.Appsettings.json файлом. Настройка и первое взаимодействие с Duende Identity Server.Identity Server и очистка проекта от ненужных файлов.Duende Identity Server к Web Application (клиентской части).Duende Identity Server к использованию кастомной JWT-Authorization и создание страницы Dashboard (личный кабинет пользователя).Duende Identity Server для работы с MongoDB Entities.Duende Identity Server. Настройка AzureAD как одного из способов авторизвции. Добавление новых сущностей в MSSQL Server.Identity Server.JwtBearer. Настройка AzureAD. Подключение Azure Blob Storage как одного из механизмов для хранения изображений автомобилей.Pipeline между серверным приложением и обеими БД. Добавление ActionNotes Repository как один из сервисов в приложение.Dashboard. Обновлена структура БД, где был добавлен новый столбец. Настроен Pipeline при получении данных для представления информации об учетной записи клиента.Dashboard.Dashboard. Добавлены функции ajax для загрузки страницы без обновления. Добавлена функция поиска по критериям.pipeline для отображения данных об автомобилях в каталоге.GoogleMaps Api.Stripe.VehicleInformation.Azure VM. Настройка сервиса логгирования исключений Seq и его хостинг на AzureVM. Настройка доступа задеплоенного приложения к своей БД MSSQL.GitHub Actions и автоматическим Publish при Merge с Main branch.Http на Https и добавление новых функций.Rental и Payment и настрока Azure VM.Stripe Payment Service на стороне сервера.Stripe. Работа над созданием Stripe Checkout Sessions.Requests и Responses при манипуляции с заказами на клиенте.Runtime обработки и получения формы при изменении статуса заказа.DateTime, запросами в БД и работа над функциональными возможностями приложения.Routing-ом и настройка отображения страниц с информацией об ошибках..tagets файла для решения проблемы версионности одинаковых пакетов в разных проектов.Endpoints для редактирования данных об автомобиле.pipeline между всеми контроллерами клиента и сервера после добавления атрибутов к параметрам контроллеров.server response на клиентской стороне и настройка универсального обработчика этих responses.DateTime.Now (локального времени) на объект DateTime.UtcNow (UTC времени).Routing на серверной части в стиле REST.pipeline для редактирования информации.Этот проект представляет из себя полноценное Web-приложение, работающее на одном уровне с PublicAPI, написанным в стиле Clean Architecture, позволяющее любому человеку, имеющему валидную карту для оплаты аренды и водительское удостоверение получить возможность арендовать на время машину другого пользователя, который также зарегистрировался, но не с целью аренды чужого автомобиля, а с целью предоставления своих автомобилей для пользования другим пользователям. Таким образом, выгоду могут получить как и разработчики приложения, получая процент с осуществляемых пользователями сделок, так и непосредственно сами пользователи, арендующие либо предоставляющие в аренду свои автомобили.
Stripe)SweetAlert2)Google Maps API)Stripe)ErrorOr NuGet Package)JWT Bearer NuGet Package)Azure Key Vault)Azure Blob Storage)Azure AD)Seq Service)Polly)Lets Encrypt Service)PVS Studio)MSSQL и MongoDB)GitHub Actions и Action Runners)Azure VM)и другие...
Весь проект был написан с нуля, с использованием bootstrap 5+ для оформления визуальной составляющей, а также с использованием функциональных возможностей Razor Pages, ну и C# .NET Core для написания backend составляющей. В качестве модели взаимодействия мной был сделан выбор в сторону MVC. На выходе мы имеем дело с Client-Server MVC Wep App.
Как только неавторизованный пользователь запускает приложение, он сразу же видит главный экран с информацией о сервисе. На данной странице находится вся необходимая информация для ознакомления нового пользователя со всеми возможностями сервиса. Сверху можно видеть элемент navbar, который всё время находится на любой из страниц и не пропадает из поля видения, предназначенный для осуществления навигации пользователя по страницам приложения. Navbar предоставляет следующие возможности:
Также, на странице присутствует карта от google, которая показывает расположение всех доступных, не арендованных автомобилей из каталога (на карте появляются маркеры, по котороым можно отследить текущее местоположение транспортных средств. При наведени на маркер появится изображение транспортного средства с его названием). В качестве ограничения, я выбрал город Минск, то есть карта расположена таким образом, чтоб охватить всю область города. Если автомобиль, скажем, будет находиться где-то на улицах Бреста, то на карте мы его не увидим (либо же нужно будет менять масштаб карты). В качестве доступных локаций для размещения автомобилей, я решил ограничиться Беларусью, то есть автомобиль, размещаемый авторизованным пользователем, должен находиться на территории РБ. Однако, ничего не мешает пользователю создать заказ на автомобиль в другом городе или даже стране.
Касательно самой карты, она была подключена в приложение при помощи специального ключа, который работает без каких либо ограничений для поиска местоположения по известным Latitude и Longitude.
Независимо от страницы, в самом низу, будет расположена информация о разработчиках приложения и ссылки на соответствующие соц. сети и ресурсы Sam Solutions.
На странице с каталогом пользователям будет предоставлена возможность просмотреть всю доступную краткую информацию об автомобилях, а также осуществлять поиск по критериям среди автомобилей, приведенных в каталоге. На странице есть возможность:
Касательно информации об автомобилях, в каталоге представлены:
На странице также присутствует возможность вызвать форму, необходимую для осуществления точечного поиска транспортных средств. Тут пользователю предоставляется множество разных фильтров, с помощью которых он может найти интересующие его автомобили в каталоге.
Таким образом, каталог позволяет рассмотреть ассортимент представленных транспортных средств и выбрать какой-либо экземпляр на свой вкус и цвет.
Как только пользователь нажимает кнопку Log In, он немедленно перенаправляется на страницу авторизации.
На странице авторизации, неавторизованному пользователю потребуется ввести свой Email (или Login) и Password для успешной авторизации. При ошибке в заполнении поля - будет отображаться сообщение об ошибке при заполнении:
Если все поля заполнены правильно, но авторизация не прошла - пользователю будет представлено сообщение о неудачной авторизации:
При успешной авторизации, уже авторизованный пользователь, будет перенаправлен на страницу Dashboard (личный кабинет), на которой появится сообщение об успешной авторизации, которое автоматически пропадает через 3 секунды после своего появления.
Если же у пользователя нет своего аккаунта, пользователю необходимо создать свой аккаунт, переход на страницу для осуществления чего осуществляется через нажатие кнопки Sign Up справа элемента Navbar.
На странице с регистрацией нового пользователя, необходимо будет ввести ряд данных, чтобы программа внесла клиента в базу и регистрация была пройдена успешно. Вся страница наполнена валидацией, и, если что-то не пройдёт - пользователь будет уведомлён о том, в каком поле произошла ошибка (такой же приинцип, как и со сраницей авторизации). После успешной регистрации, пользователь будет перенаправлен на страницу с регистрацией, на которой появится сообщение об успешной регистрации.
Как только пользователь успешно войдёт в свой только что созданный аккаунт, он получит возможность не только просматривать более детальную информацию об автомобилях в каталоге, но и добавлять свои собственные автомобили, а также отслеживать статистику по своим действиям и действиям другими пользователями с его автомобилями.
На данной странице пользователь должен будет предоставить соответствующую информацию о своём автомобиле, а также установить тариф, по которому будет производиться аренда автомобиля. На странице также присутствует валидация (аналогично странице авторизации и регистрации). Как только пользователь успешно поделится своей машиной, она сразу же появится в его аккаунте, однако для её публикации, администратор должен одобрить заявку, после чего пользователь сможет опубликовать автомобиль через свой личный кабинет, а также редактировать информацию и всячески взаимодействовать с этим автомобилем. (Так как пользователь добавил свой автомобиль, логично, что показывать его в каталоге этому же пользователю будет не совсем логично и правильно. Однако, они всё же показываются в каталоге, НО, перейдя на страницу с информацией об этом автомобиле, владелец не сможет арендовать его, однако сможет ознакомиться с его описанием и представлением для других пользователей).
На странице Dashboard авторизованному пользователю предлагается просомтреть статистику своего аккаунта. На данной странице пользователь может просмотреть такую информацию, как:
Со страницы Dashboard, пользователь имеет возможность попасть на страницы с редактированием информации об автомобиле, либо же на страницу с редактированием информации аккаунта.
Головная страница позволяет пользователю изменить некоторые поля, связанные с его аккаунтом (такие, как Имя, Фамилия, Никнейм, Почта и др.)
Головное меню имеет несколько кнопок слева, после нажатия 2-ух из которых появляются мини-окна, которые также служат для изменения некоторой информации аккаунта.
При нажатии на соответствующую кнопку на головной странице, пользователю предлагается выбрать один из аватаров, который будет представлять его профиль. Как только пользователь выберет один из аватаров, после чего нажмёт на кнопку Apply и Save changes, аватар будет обновлён и пользователь сможет наблюдать другое изображение в своём аккануте.
При нажатии следующей по счёту кнопки, пользователю представится возможность ввести новый пароль от своего аккаунта, после чего пароль от его учётной записи будет полностью обновлён и старый пароль будет недействительным при повторном входе в аккаунт.
После того, как пользователь добавит в аккаунт новый автомобиль и он будет успешно подтверждён администратором, пользователь сможет опубликовать свой автомобиль (он станет дотупным для аренды другим пользователям), либо спрятать его. Если автомобиль спрятан, при нажатии на соответствующее меню, пользователь сможет нажать на соответствующую кнопку Modify, после чего перейти на страницу с редактированием информации об автомобиле.
На данной странице он сможет изменить общую информацию об автомобиле (однако не сможет изменить изображение автомобиля и его категории с той целью, что если у него была бы такая возможность, после подтверждения автомобиля администратором, он бы мог загрузить в это объявление авсолютно любое изображение, абсолютно любую информацию, после чего другие пользователи видели бы у себя в каталоге неправильную и невалидную информацию).
TODO: Change everything that goes below.
Как только авторизованный пользователь нажимает кнопку Information на карточке транспортного средства из каталога, у него открывается соответствующая страница с выбранным автомобилем и более детальной информацией о экземпляре. С этой страницы, вскоре, можно будет оформлять заказы, которые будут фиксироваться в личном кабинете пользователя.
Мной была добавлена кнопка перехода в личный кабинет пользователя после авторизации, которая позволяет пользователю отслеживать свои заказы и добавленные им автомобили (Пока что активны только кнопки Publish и Hide для взаимодействия с автомобилями).
На данной странице, пользователь сможет не только просматривать и изменять информацию своего акканута, но и управлять своими автомобилями и своими заказами. После данных пользователя, можно увидеть следующие счётчики:
Также, на этой странице можно просматривать такую информацию, как:
При работе с таблицей автомобилей, можно наблюдать 3 цвета:
В зависимости от состояния и цвета автомобиля, пользователю открываются/блокируются новые/старые функции
Как было сказано выше, для авторизованного в систему пользователя появляется возможность заходить в свой личный кабинет и отслеживать всю информацию, связанную с его заказами, а также автомобилями, которые данный пользователь предоставил для пользования другим пользователям нашего сервиса. Но что, если какая-то информация была введена не совсем корректно, если данные пользователя поменялись... А может быть опубликовавший автомобиль пользователь решит каким-то образом выделться на фоне других??? Для решения этих задач мной были разработаны страницы с редактированием информации как о текущем пользователе, так и о его автомобилях:
Из своего личного кабинета, перейти на страницу с редактированием информации о себе, пользователь может при помощи нажатия на соответствующую кнопку Edit Profile
При нажатии, пользователю открывается страница, на которой он может менять любую информацию, что отображена на странице
В частности: аватар своего профиля (на выбор 7 изображений из предложенных (1 default-ная, которая присваивается каждому новому пользователю, и 6 других на выбор))
Также можно поменять свой пароль. Установление нового пароля я сделал таким образом, что вводить предыдущий не понадобится (в реальности же, необходимо было бы запрашивать реальный пароль перед тем, как устанавливать новый)
Из простого, пользователь может менять любое из полей на данной странице (например, описание профиля, свой номер телефона, e-mail и тд). После того, как все интересующие пользователя поля были изменены, необходимо нажать на соответствующую кнопку Save Changes (новый пароль устанавливается автоматически при нажатии кнопки Save на странице с установлением нового пароля). Если была произведена какая-то ошибка при заполнении полей, пользователь может нажать на кнопку Cancel Chnages, что вернёт страницу в её первоначальный вид (тобиш к старым данным), либо же нажать на кнопку Get Back, которая перенесёт его обратно в свой личный кабинет.
Собственно, касаемо автомобилей, пользователь также может менять ту или иную информацию, преведенную на странице:
Однако, количество доступных полей для изменения в несколько раз меньше, чем у пользователя. Почему так? Дело в том, что при разработке, мне в голову пришла мысль: У каждого автомобиля ведь отслеживается число заказов. А что, если пользователь мог бы менять автомобиль полностью, скажем, поменять его изображение и название? Рейтинг у этого автомобиля остался бы тот же, а вот детальное описание полностью бы изменилось. Как по мне, такой подход смог бы играть ключевую роль в определении другими пользователями, какой автомобиль ему выбрать: например, пользователь, разместивший свой автомобиль год назад, явно проигрывал бы пользователю, который поменял бы описание своего старого автомобиля на описание более нового. Таким образом, мной был сделан вывод, что информацию нужно скрыть от редактирования, а доступными оставить только самые необходимые поля: поля с тарифом, описанием, а также местоположением.
Дюбой из авторизованных пользователей может просматривать детальную информацию об автомобилях других пользователей в каталоге. Со страницы каждого автомобиля, пользователь может перейти на страницу с оформлением заказа на пользование этим автомобилем:
На этой странице ему предлагается выбрать временной промежуток, в который он сможет пользоваться автомобилем.
Выбор промежутка времени осуществляется с помощью элемента daterangepicker, в котором мной было установлено: Время начала - округление в сторону ближайшего часа. Время конца (default-ное) - время начала + 1 час. Таким образом, минимальное время для использования авто - 1 час. Макисмальное же время, которое я поставил - 7 дней со времени начала. Подсчёт суммы к оплате же происходит по формуле: Число дней умноженное на тариф/день + число часов * тариф/час. Как только пользователь сделает все необходимые приготовления и подтвердит заказ - он будет перенаправлен на страницу с оплатой:
На странице с оплатой приведена вся информация, необходимая пользователю для того, чтоб ещё раз перепроверить свой заказ. Как только оплата будет произведена, пользователи смогут найти автомобили в их личном кабинете: Пользователь, который владеет автомобилем - увидит, что автомобиль был арендован, а пользователь, что арендовал автомобиль - увидит полную информацию об оплаченном времени а также всю информацию касательно оставшегося времени и времени окончания аренды на этот автомобиль. Выглядит это следующим образом:
Когда пользователь решит завершить свой заказ досрочно (заказ завершается не системой, отвечаемой за просроченные заказы, а самим пользователм, совершившим заказ), у него появляется возможность выставить рейтинг для автомобиля, которым он пользовался на протяжении N-го промежутка времени:
Опять же, у пользователя есть выбор: Поставить рейтинг автомобилю, после чего нажать на соответствующую кнопку Submit and Finish и завершить заказ вместе с рейтингом, либо же пропустить шаг с выставлением рейтинга, нажав на кнопку Finish and not submit, и завершить заказ без отправки рейтинга.
Сам же рейтинг можно увидеть на странице с информацией об автомобиле. В зависимости от поставленыых пользователями оценок, на странице будет отображаться общая статистика. Автомобиль с 0 звёздами можно было увидеть выше, а страница с автомобилем с проставленным рейтингом от одного пользователя показана ниже:
В данном разделе я постараюсь описать, а как проект устроен изнутри, что происходит внутри <Чёрного ящика>. Это поможет лучше разобраться в проекте тем, кто хоть немного имеет представление о языке программирования C# и аспекты программирования на нём.
Конечно, для того, чтобы работать с какими-либо данными, для начала, нужно определиться, а как именно их хранить? Конечно, супер крупные проекты используют для хранения такие БД, как Oracle, PostgreSQL, MySQL, MSSQL и другие. Однако, проблема такого подхода состоит в том, что доступ к приложениям, привязанным к базам данных, можно получить только в том случае, если подключение к той самой базе данных может быть получено на устройстве пользователя (За такую функцию приходится платить крупные суммы денег компаниям-гигантам). Так как я не располагаю большими суммами денег, для возможности любому пользователю запускать проект и не испытывать проблемы с его тестированием и пользованием, мной была выдвинута идея использования сериализации и десериализации в контекстах относительных путей. Таким образом, проблем с получением доступа у пользователей, скачавших приложение из репозитория, возникнуть не должно.
Каким же образом происходит получение данных из JSON-файлов и как вообще устроено получение данных? (Для всех локальных хранилищ)
Для того, чтобы не привязываться к какому-то определённому типу хранилищ, мной был применён подход Dependency Injection, а именно внедрение Singleton зависимостей между хранилищами и локальным репозиторием программы. То есть: в моей программе есть интерфейс:
public interface IVehiclesRepositoryЭтот интерфейс будет являться связующим звеном для получения данных. В данном интерфейсе есть набор методов, которые должны быть реализованы для того или иного сервиса, чтоб им можно было пользоваться независимо от реализации методов. Главное, чтоб эти методы были реализованы в том классе, который решит реализовать этот интерфейс. Для реализации локального интерфейса, так как я исользую локальное хранилище данных в файлах, а не в БД, я решил использовать Singleton подход, что будет означать, что объект сервиса будет создаваться только при первом обрпщении к нему, после чего все последующие запросы будут проходить через тот самый сервис. Ниже, мы явно указываем, что если кто-то захочет получить объект этого сервиса через интерфейс, мы дадим ему конкретную реализацию (В данном случае реализацию локального репозитория):
builder.Services.AddSingleton<IVehiclesRepository, VehiclesLocalRepository>(); // Где требуется IVehiclesRepository - дай реализацию VehiclesLocalRepositoryСами же локальные репозитории реализованы таким образом, чтоб уменьшить количество загрузок из файлов в само приложение. Как только происходит первое обращение к сервису - производится работа метода SetUpLocalRepository. Этот метод запишет в путой объект List<> модели, считанные из JSON - файла, после чего все манипуляции будут проходить непосредственно через сам этот List<>, а если данные будут меняться - будет вызываться асинхронный метод SaveChanges(), который призван асинхронно записать изменения в файл (Повторное считывание файла не происходит, так как мы работаем с объектом List<>, который мы также изменили перед тем, как запрашивать обновление JSON-файла). Таким образом, применённый мной подход не только позволит пользователю получать доступ в кратчайшие сроки, но и позволит избежать излишних нагрузок системы для загрузки данных из файлов каждый раз при обращении к сервису.
При проектировнии, мной была выявлена следующая проблема - А должен ли пользователь, добавивший автомобиль в каталог, иметь возможность взаимодействовать с тем же самым автомобилем из каталога? Конечно же нет. Такой подход позволит пользователю, добавившему автомобиль в каталог, арендовать свой же автомобиль (В чём смысл???). Для избежания этой проблемы, мной был выбран следующий подход:
Представим, что на данный момент, нет ни пользователей, ни добавленных автомобилей. Вот мы запускаем наше приложение. На главной странице мы видим карту с 0 маркерами, а в каталоге также 0 автомобилей. Мы создаём новый аккаунт, входим в него, делимся своим автомобилем. НО! Автомобиль не появляется в каталоге. В чём же проблема? Дело в том, что перед тем, как отобразить автомобиль в каталоге, добавивший его пользователь должен явно опубликовать автомобиль из своего личного кабинета путём нажатия кнопки Publish напротив выбранного автомобиля. Как только он произведёт публикацию, для этого пользователя в каталоге ничего не изменится, он также будет видеть 0 автомобилей. ОДНАКО! Если мы выйдем из аккаунта или создадим новый - В каталоге будет виднеться тот самый автомобиль, которым поделился и который опубликовал предыдущий пользователь. Таким образом, пользователь, добавивший автомобиль и разместивший его в каталог, не может увидеть свои же собственные автомобили (Все свои добавленные автомобили пользователь может увидеть в своём личном кабинете). ЗАТО! После того, как пользователь поделится своим автомобилем и разместит его в каталог из личного кабинета, хотя он не видит этот автомобиль в каталоге, он может перейти на главную страницу и обратить внимание, что его автомобиль появился на карте в виде маркера (Однако в каталоге его по-прежнему нет). Дело в том, что система показывает ЛЮБОМУ пользователю ВСЕ автомобили на карте в виде маркера, которые были ОПУБЛИКОВАНЫ в личном кабинете не зависимо от того, какой пользователь сейчас находится в системе. Однако в каталоге, система показывает те же самые автомобили, что изображены на карте на главной странице в виде маркеров, НО ещё проверяется условие, что ID владельца автомобиля не равно ID текущего пользователя, вошедшего в аккаунт. Для неавторизованного пользователя ID не проверяется. Ему показываются те же самые автомобили в каталоге, что и на карте на главной странице.
Таким образом, подводя итог:
Publish (И пропадёт, если он решит убрать его из каталога путём нажатия кнопки Hide)При добавлении автомобиля, на странице использованы такие технологии, как локальное хранилище данных (Local Storage) для хранения координат местоположения автомобиля, а также специальные скрипты и элемент C# IFormFile для получения файла изображения со сраницы.
Local Storage
Предположим, что мы - очень невнимательные пользователи, которые всё время допускают ошибки на страницах. Для того, чтобы избежать повторного ввода координат каждый раз при обновлении страницы, пной было принято решение хранить координаты GoogleMaps в локальном хранилище и чистить эти данные в случае покидания пользователем страницы добавления своего автомобиля. Так как данные, применяемые при работе с GoogleMaps являются специфическими (представление типа данных float отличаются знаком разделителя) чтоб избежать большого количества манипуляции с данными, используется локальное хранилище, которое призвано сократить число операция приведения данных из одного представления в другое.
IFormFile и скрипты
При работе с изображеним, мы не можем получать доступ к файловой системе пользователя со страницы Razor, так как это просто недопустимо в рамках работы системы безопасности, поэтому приходится использовать определённые подходы, например, как работа с IFormFile. Объекты этого типа хранят всю необходимую информацию о выбранном изображении, которое выберет пользователь, при этом не представляет никакой угрозы для файловой системы компьютера в целом. Однако использование такого подхода имеет недотаток - пользователю необходимо каждый раз выбирать изображение снова и снова, если пользователем повторно допускаются ошибки на странице добавления автомобиля.
Ниже я постарался описать интересные технические моменты, которые я предпринимал в течение проектирования и разработки проекта.
При работе с получением автомобилей из репозитория у меня было 2 идеи, как решить данную задачу: Либо при каждом обращении к контроллеру формировать новый объект с информацией о машинах и передавать его во View, либо же принимать этот объект из View, если он уже был передан однажды, при этом не делая никаких дополнительных запросов в репозиторий, и модифицировать согласно предпочтениям пользователя по количеству отображения автомобилей на странице и тд. Сначала я принял решение пойти через получение модели из View, однако столкнулся с такой проблемой, как Model Binding, которая просто так не даёт получить List переданных в качестве модели автомобилей: Либо нужно использовать Ajax, при этом заранее сериализовать модель в JSON и после чего десериализовать полученную JSON-строку в Controller-е, либо никак) Поэтому я выбрал первый путь (через создание объекта), так как в этом случае придётся манипулировать в основном со ссылками на данные, нежели чем с самими данными. (p.s. Также, работа через первый подход потребовала бы накладных расходов на проверку, а не добавилась ли в репозиторий новая машина, но уже другим пользователем, и если добавилась, также необходимо было бы добавить её в модельку, пришедшую из View)
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
