Car sharing center
1.0.0
The main idea of the proceed: to develop an application-service of the car sharing service with displaying available cars on the map. In content - everything that can be compared with the essence Vehicles : cars, motorcycles, any vehicles, etc. The application should be multifunctional: it is necessary to have a large number of pages with the ability to receive, add, change and delete entities.
pager -a to the page.httpContextAccessor .UserStatusProvider status. Adding JS messages using the SweetAlert2 service.ReadMe .Stripe payment service to the project. Adding the functionality of the selection of time and date to the page with the placement of the order.JS code (smashed by files).Brief Description of the account that placed the user's car. He began to make a part with the rating for cars..NET 7 . Work on the search engine of the catalog page.RepositoryProvider and reducing all the functionality for it.JWToken Authentication to Web -Application controllers.JWToken and setting up the page display of an error on the client side.JSON files to storage in MongoDB Local .MongoDB Atlas cluster in order to further work with the cloud service.UI . Changing the Google Maps API marker from red to a car with the name and image.The official start of the internship
Web application to the full -fledged Clean Architecture .Domain Layer and setting up the first models. Models are created in the Rich Domain Models style. Anemic Domain Models .Application and Infrastructure Layers , as well as setting up first interactions with the service and setting up DI .PublicAPI .endpoints and their manual testing.Errors Handling and its processing.Errors Handling to part of Vehicle model.endpoints .Azure Key Vault functionality to obtain secret data with Azure . Implementation of biting flags as one of the options for storing information about cars.endpoints to CustomerController and their manual testing.endpoints to VehicleController and their manual testing.IHttpClientFactory to create customers for sending Requets towards PublicAPI . Polly configuration for non -metnamic sending messages with the possibility of waiting and re -sending them in case of critical situations.PublicApi along with Web part and checking Endpoints and inter -program serialization and deserization.JWToken from the server on the client side with a successful entrance to the account.UI pages of registration, authorization and adding a new car.errors handling on the client part when adding a new car.html pages and some endpoints .Bootstrap 5+ and removing the logic of the page of registration and authorization.GoogleMaps Api and error correction.Appsettings.json File. Settings and the first interaction with Duende Identity Server .Identity Server and clean the project from unnecessary files.Duende Identity Server to Web Application (client part).Duende Identity Server to the use of custom -made JWT-Authorization and creating the Dashboard Page (User Personal Account).Duende Identity Server for working with MongoDB Entities .Duende Identity Server . Setting AzureAD as one of the ways of authorization. Adding new entities to MSSQL Server .Identity Server .JwtBearer . Setting AzureAD . Connection Azure Blob Storage as one of the mechanisms for storing car images.Pipeline set up between the server app and both databases. Add ActionNotes Repository as one of the services to the application.Dashboard page. Updated the structure of the database, where a new column was added. Pipeline is configured to receive data to submit information about the client’s account.Dashboard page.Dashboard page. ajax functions are added to download a page without update. Added a search function by criteria.pipeline Supply to display data on cars in the catalog.GoogleMaps Api .Stripe payment service.VehicleInformation page.Azure VM . Setting Seq and Hosting Exceptions Service on Azurevm. Setting up the access of a naval application to your MSSQL database.GitHub Actions and Automatic Publish at Merge with Main branch .Http to Https and adding new functions.Rental and Payment models and Azure VM mood.Stripe Payment Service on the server side.Stripe . Work on the creation of Stripe Checkout Sessions .Requests and Responses when manipulating orders on the client.Runtime processing and obtaining a form when changing the status of an order.DateTime , requests in the database and work on the functionality of the application.Routing-ом and setting up pages display with error information..tagets file to solve the problem of the version of the same packages in different projects.Endpoints to edit car data.pipeline between all controllers of the client and the server after adding attributes to the parameters of controllers.server response analyzer on the client side and setting up the universal handler of these responses .DateTime.Now (local time) to the object DateTime.UtcNow (UTC time).Routing setting on the server part in REST style.pipeline to edit information. This project is a full -fledged Web application working at the same level with PublicAPI , written in the Clean Architecture style, which allows any person who has a valid rental card and a driver’s license to get a car of another user for a while, which also registered, but not with the aim of renting someone else's car, but to provide their cars for their cars using other users. Thus, the advantage can be obtained both by the developers of the application, receiving a percentage of transactions made by users, and directly the users themselves renting or leasing their cars.
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 and MongoDB )GitHub Actions and Action Runners )Azure VM )and others ...
The entire project was written from scratch, using bootstrap 5+ to decorate the visual component, as well as using the functionality of Razor Pages , well, C# .NET Core for writing a backend component. As a model of interaction, I made a choice towards MVC . At the exit we are dealing with Client-Server MVC Wep App .
As soon as an unauthorized user launches the application, he immediately sees the main screen with information about the service. This page contains all the necessary information to familiarize yourself with the new user with all the capabilities of the service. On top you can see the navbar element, which is all the time on any of the pages and does not disappear from the vision field designed to carry out the user navigation in the appendix. Navbar provides the following opportunities:
Also, on the page there is a map from Google, which shows the location of all available, not rented cars from the catalog (markers appear on the map, according to which the current location of the vehicles can be tracked. When entrusted to the marker, an image of a vehicle with its name will appear). As a restriction, I chose the city of Minsk, that is, the map is located in such a way as to cover the entire area of the city. If the car, say, will be somewhere on the streets of Brest, then we will not see it on the map (or it will be necessary to change the scale of the card). As available locations for placing cars, I decided to limit myself to Belarus, that is, a car placed by an authorized user should be in the Republic of Belarus. However, nothing prevents the user from creating an order for a car in another city or even a country.
Regarding the card itself, it was connected to the application using a special key, which works without any restrictions for finding a location according to the famous Latitude and Longitude.
Regardless of the page, at the very bottom, there will be information about the developers of the application and links to the corresponding social. Sam Solutions networks and resources.
On the page with the catalog, users will be given the opportunity to view all the affordable brief information about the cars, as well as to search for criteria among cars given in the catalog. On the page there is an opportunity:
Regarding information about cars, the catalog is presented:
The page also has the opportunity to cause the form necessary for the implementation of a point search for vehicles. Here, many different filters are provided to the user, with which he can find cars of interest to him in the catalog.
Таким образом, каталог позволяет рассмотреть ассортимент представленных транспортных средств и выбрать какой-либо экземпляр на свой вкус и цвет.
Как только пользователь нажимает кнопку 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 , которая перенесёт его обратно в свой личный кабинет.
Собственно, касаемо автомобилей, пользователь также может менять ту или иную информацию, преведенную на странице:
Однако, количество доступных полей для изменения в несколько раз меньше, чем у пользователя. Why so? Дело в том, что при разработке, мне в голову пришла мысль: У каждого автомобиля ведь отслеживается число заказов. А что, если пользователь мог бы менять автомобиль полностью, скажем, поменять его изображение и название? Рейтинг у этого автомобиля остался бы тот же, а вот детальное описание полностью бы изменилось. Как по мне, такой подход смог бы играть ключевую роль в определении другими пользователями, какой автомобиль ему выбрать: например, пользователь, разместивший свой автомобиль год назад, явно проигрывал бы пользователю, который поменял бы описание своего старого автомобиля на описание более нового. Таким образом, мной был сделан вывод, что информацию нужно скрыть от редактирования, а доступными оставить только самые необходимые поля: поля с тарифом, описанием, а также местоположением.
Дюбой из авторизованных пользователей может просматривать детальную информацию об автомобилях других пользователей в каталоге. Со страницы каждого автомобиля, пользователь может перейти на страницу с оформлением заказа на пользование этим автомобилем:
На этой странице ему предлагается выбрать временной промежуток, в который он сможет пользоваться автомобилем.
Выбор промежутка времени осуществляется с помощью элемента 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 автомобилей. Мы создаём новый аккаунт, входим в него, делимся своим автомобилем. BUT! Автомобиль не появляется в каталоге. What is the problem? Дело в том, что перед тем, как отобразить автомобиль в каталоге, добавивший его пользователь должен явно опубликовать автомобиль из своего личного кабинета путём нажатия кнопки Publish напротив выбранного автомобиля. Как только он произведёт публикацию, для этого пользователя в каталоге ничего не изменится, он также будет видеть 0 автомобилей. HOWEVER! Если мы выйдем из аккаунта или создадим новый - В каталоге будет виднеться тот самый автомобиль, которым поделился и который опубликовал предыдущий пользователь. Таким образом, пользователь, добавивший автомобиль и разместивший его в каталог, не может увидеть свои же собственные автомобили (Все свои добавленные автомобили пользователь может увидеть в своём личном кабинете). BUT! После того, как пользователь поделится своим автомобилем и разместит его в каталог из личного кабинета, хотя он не видит этот автомобиль в каталоге, он может перейти на главную страницу и обратить внимание, что его автомобиль появился на карте в виде маркера (Однако в каталоге его по-прежнему нет). Дело в том, что система показывает ЛЮБОМУ пользователю ВСЕ автомобили на карте в виде маркера, которые были ОПУБЛИКОВАНЫ в личном кабинете не зависимо от того, какой пользователь сейчас находится в системе. Однако в каталоге, система показывает те же самые автомобили, что изображены на карте на главной странице в виде маркеров, НО ещё проверяется условие, что 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-е , либо никак) Поэтому я выбрал первый путь (через создание объекта), так как в этом случае придётся манипулировать в основном со ссылками на данные, нежели чем с самими данными. (ps Также, работа через первый подход потребовала бы накладных расходов на проверку, а не добавилась ли в репозиторий новая машина, но уже другим пользователем, и если добавилась, также необходимо было бы добавить её в модельку, пришедшую из View )
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
