Car sharing center
1.0.0
L'idée principale du projet: développer un service d'application du service de partage de voitures avec l'affichage des voitures disponibles sur la carte. Dans le contenu - tout ce qui peut être comparé à l'essence Vehicles : voitures, motos, tous véhicules, etc. L'application doit être multifonctionnelle: il est nécessaire d'avoir un grand nombre de pages avec la possibilité de recevoir, d'ajouter, de modifier et de supprimer des entités.
pager -a à la page.httpContextAccessor .UserStatusProvider . Ajout de messages JS à l'aide du service SweetAlert2 .ReadMe .Stripe au projet. Ajout de la fonctionnalité de la sélection du temps et de la date à la page avec le placement de l'ordre.JS (brisé par des fichiers).Brief Description du compte SO-So-Salled du compte qui a placé la voiture de l'utilisateur. Il a commencé à faire une part avec la notation des voitures..NET 7 . Travaillez sur le moteur de recherche de la page du catalogue.RepositoryProvider et réduisant toutes les fonctionnalités.JWToken Authentication aux contrôleurs de l'application Web .JWToken et configurant l'affichage de la page d'une erreur du côté client.JSON au stockage dans MongoDB Local .MongoDB Atlas afin de travailler davantage avec le service cloud.UI . Modification du marqueur Google Maps API du rouge vers une voiture avec le nom et l'image.Le début officiel du stage
Web à l' Clean Architecture complète.Domain Layer et configurant les premiers modèles. Les modèles sont créés dans le style Rich Domain Models . Anemic Domain Models .Infrastructure Layers Application et d'infrastructure, ainsi que de configurer les premières interactions avec le service et la configuration DI .PublicAPI .endpoints et de leurs tests manuels.Errors Handling et son traitement.Errors Handling à une partie du modèle Vehicle .endpoints .Azure Key Vault pour obtenir des données secrètes avec Azure . La mise en œuvre des drapeaux mordants comme l'une des options de stockage d'informations sur les voitures.endpoints à CustomerController et à leurs tests manuels.endpoints à VehicleController et à leurs tests manuels.IHttpClientFactory pour créer des clients pour envoyer des requet vers PublicAPI . Configuration Polly pour les messages d'envoi non métnamique avec la possibilité d'attendre et de les redevenir en cas de situations critiques.PublicApi avec Web Part et vérifier les points de terminaison et la sérialisation et la désérisation inter-programme.JWToken reçu du serveur du côté client avec une entrée réussie du compte.UI de l'enregistrement, l'autorisation et l'ajout d'une nouvelle voiture.errors handling sur la partie client lors de l'ajout d'une nouvelle voiture.html et quelques endpoints .Bootstrap 5+ et en supprimant la logique de la page de l'enregistrement et de l'autorisation.GoogleMaps Api et la correction d'erreur.Appsettings.json . Paramètres et première interaction avec Duende Identity Server .Identity Server et nettoyer le projet à partir de fichiers inutiles.Duende Identity Server to Web Application (Client Part).Duende Identity Server à l'utilisation de JWT-Authorization personnalisés et création de la page Dashboard (compte personnel de l'utilisateur).Duende Identity Server pour travailler avec MongoDB Entities .Duende Identity Server . Définir AzureAD comme l'un des moyens d'autorisation. Ajout de nouvelles entités à MSSQL Server .Identity Server .JwtBearer . Définition AzureAD . Connexion Azure Blob Storage comme l'un des mécanismes de stockage des images de voiture.Pipeline entre l'application Server et les deux bases de données. Ajouter ActionNotes Repository comme l'un des services à l'application.Dashboard . Mise à jour de la structure de la base de données, où une nouvelle colonne a été ajoutée. Pipeline est configuré pour recevoir des données pour soumettre des informations sur le compte du client.Dashboard .Dashboard . Les fonctions ajax sont ajoutées pour télécharger une page sans mise à jour. Ajout d'une fonction de recherche par critères.pipeline pour afficher des données sur les voitures dans le catalogue.GoogleMaps Api .Stripe Payment Service.VehicleInformation .Azure VM . Définition Seq et hébergement sur AzureVM. Configuration de l'accès d'une application navale à votre base de données MSSQL .GitHub Actions et Publish automatique à Merge with Main branch .Http à Https et l'ajout de nouvelles fonctions.Rental et Payment et d'humeur Azure VM .Stripe Payment Service du côté serveur.Stripe . Travaillez sur la création de Stripe Checkout Sessions .Requests et Responses du serveur lors de la manipulation des commandes sur le client.Runtime et de l'obtention d'un formulaire lors de la modification de l'état d'une commande.DateTime , Demandes dans la base de données et travaillent sur la fonctionnalité de l'application.Routing-ом et la configuration des pages afficher avec des informations d'erreur..tagets pour résoudre le problème de la version des mêmes packages dans différents projets.Endpoints pour modifier les données de la voiture.pipeline entre tous les contrôleurs du client et le serveur après avoir ajouté des attributs aux paramètres des contrôleurs.server response côté client et configurant le gestionnaire universel de ces responses .DateTime.Now (heure locale) à l'objet DateTime.UtcNow (UTC Time).Routing sur la partie du serveur dans le style REST .pipeline pour modifier les informations. Ce projet est une application Web à part entière travaillant au même niveau avec PublicAPI , écrite dans le style Clean Architecture , qui permet à toute personne qui a une carte de location valide et un permis de conduire pour obtenir une voiture d'un autre utilisateur pendant un certain temps, qui a également enregistré, mais pas dans le but de louer la voiture de quelqu'un d'autre, mais de fournir ses voitures pour leurs voitures en utilisant d'autres utilisateurs. Ainsi, l'avantage peut être obtenu à la fois par les développeurs de l'application, recevant un pourcentage de transactions effectuées par les utilisateurs, et directement par les utilisateurs eux-mêmes louant ou louent leurs voitures.
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 et MongoDB )GitHub Actions and Action Runners )Azure VM )Et d'autres ...
L'ensemble du projet a été écrit à partir de zéro, en utilisant bootstrap 5+ pour décorer le composant visuel, ainsi que l'utilisation des fonctionnalités Razor Pages , eh bien, C# .NET Core pour écrire un composant backend . En tant que modèle d'interaction, j'ai fait un choix vers MVC . À la sortie, nous avons affaire à Client-Server MVC Wep App .
Dès qu'un utilisateur non autorisé lance l'application, il voit immédiatement l'écran principal avec des informations sur le service. Cette page contient toutes les informations nécessaires pour vous familiariser avec le nouvel utilisateur avec toutes les capacités du service. En haut, vous pouvez voir l'élément navbar , qui est tout le temps sur l'une des pages et ne disparaît pas du champ de vision conçu pour effectuer la navigation utilisateur en annexe. Navbar offre les opportunités suivantes:
De plus, sur la page, il y a une carte de Google, qui montre l'emplacement de toutes les voitures disponibles, non louées dans le catalogue (les marqueurs apparaissent sur la carte, selon laquelle l'emplacement actuel des véhicules peut être suivi. Lorsqu'il est confié au marqueur, une image d'un véhicule avec son nom apparaîtra). En tant que restriction, j'ai choisi la ville de Minsk, c'est-à-dire que la carte est située de manière à couvrir toute la zone de la ville. Si la voiture, par exemple, sera quelque part dans les rues de Brest, alors nous ne le verrons pas sur la carte (ou il sera nécessaire de modifier l'échelle de la carte). Comme les emplacements disponibles pour placer des voitures, j'ai décidé de me limiter au Bélarus, c'est-à-dire qu'une voiture placée par un utilisateur autorisé devrait être en République du Bélarus. Cependant, rien empêche l'utilisateur de créer une commande pour une voiture dans une autre ville ou même un pays.
En ce qui concerne la carte elle-même, elle a été connectée à l'application à l'aide d'une clé spéciale, qui fonctionne sans aucune restriction pour trouver un emplacement selon la célèbre latitude et la longitude.
Quelle que soit la page, tout en bas, il y aura des informations sur les développeurs de l'application et des liens vers le social correspondant. SAM Solutions réseaux et ressources.
Sur la page avec le catalogue, les utilisateurs auront la possibilité de voir toutes les informations brèves abordables sur les voitures, ainsi que de rechercher des critères entre les voitures données dans le catalogue. Sur la page, il y a une opportunité:
En ce qui concerne les informations sur les voitures, le catalogue est présenté:
La page a également la possibilité de provoquer le formulaire nécessaire à la mise en œuvre d'une recherche de véhicules. Ici, de nombreux filtres différents sont fournis à l'utilisateur, avec lesquels il peut lui trouver des voitures d'intérêt dans le catalogue.
Ainsi, le catalogue vous permet de considérer l'assortiment des véhicules présentés et de choisir n'importe quelle copie à votre goût et à votre couleur.
Dès que l'utilisateur appuie sur la Log In , il redirige immédiatement vers la page d'autorisation.
Sur la page d'autorisation, un utilisateur non autorisé, vous devrez saisir votre e-mail (ou connexion) et votre mot de passe pour une autorisation réussie. Lorsqu'une erreur dans le remplissage du champ, un message d'erreur sera affiché lors du remplissage:
Si tous les champs sont remplis correctement, mais que l'autorisation n'est pas passée, l'utilisateur présentera un message sur l'autorisation infructueuse:
Avec une autorisation réussie, un utilisateur déjà autorisé sera redirigé vers la page de tableau de bord (compte personnel), sur lequel il y aura un message sur l'autorisation réussie, qui disparaît automatiquement 3 secondes après son apparition.
Si l'utilisateur n'a pas son propre compte, l'utilisateur doit créer son propre compte, la transition vers la page à implémenter qui est effectuée via la presse sur Sign Up sur l'élément Navbar droit.
Sur la page avec l'enregistrement d'un nouvel utilisateur, il sera nécessaire de saisir une série de données afin que le programme entre au client dans la base de données et que l'enregistrement soit réussi. La page entière est remplie de validation, et si quelque chose ne passe pas, l'utilisateur ne sera pas informé du champ dans lequel l'erreur s'est produite (le même principal qu'avec le hirsute de l'autorisation). Après une inscription réussie, l'utilisateur sera redirigé vers la page d'inscription sur laquelle il y aura un message sur l'inscription réussie.
Dès que l'utilisateur entre avec succès dans son compte nouvellement créé, il aura l'occasion non seulement de voir des informations plus détaillées sur les voitures dans le catalogue, mais aussi d'ajouter ses propres voitures, ainsi que de suivre les statistiques sur leurs actions et leurs actions par d'autres utilisateurs avec ses voitures.
Sur cette page, l'utilisateur devra fournir des informations pertinentes sur sa voiture, ainsi que le tarif auquel la voiture sera louée. La page a également une validation (similaire à la page d'autorisation et d'enregistrement). Dès que l'utilisateur partage avec succès sa voiture, il apparaîtra immédiatement dans son compte, cependant, pour sa publication, l'administrateur doit approuver la demande, après quoi l'utilisateur pourra publier la voiture via son compte personnel, ainsi que modifier les informations et interagir avec cette voiture de toutes les manières possibles. (Étant donné que l'utilisateur a ajouté sa voiture, il est logique qu'il ne soit pas entièrement logique et correct de le montrer dans le catalogue au même utilisateur. Cependant, ils s'affichent toujours dans le catalogue, mais en allant sur la page avec des informations sur cette voiture, le propriétaire ne sera pas en mesure de le louer, mais il pourra se familiariser avec sa description et sa représentation pour d'autres utilisateurs).
Sur la page de tableau de bord à un utilisateur autorisé, il est proposé de mener à sécher les statistiques de son compte. Sur cette page, l'utilisateur peut afficher les informations telles que:
À partir de la page de tableau de bord, l'utilisateur a la possibilité de se rendre aux pages avec des informations d'édition sur la voiture ou sur la page des informations de compte d'édition.
La page de tête permet à l'utilisateur de modifier certains champs associés à son compte (comme le nom, le nom de famille, le surnom, le courrier, etc.)
Le menu Head a plusieurs boutons à gauche, après avoir appuyé sur 2, dont il y a des mini-ventres, qui servent également à modifier certaines informations du compte.
En cliquant sur le bouton correspondant sur la page de tête, l'utilisateur est invité à choisir l'un des avatars qui représentera son profil. Dès que l'utilisateur sélectionne l'un des avatars, après quoi il cliquera sur Apply et Save changes , l'avatar sera mis à jour et l'utilisateur pourra observer une autre image dans son compte.
Lorsque le bouton suivant sera enfoncé, l'utilisateur aura la possibilité de saisir un nouveau mot de passe à partir de son compte, après quoi le mot de passe de son compte sera complètement mis à jour et l'ancien mot de passe sera invalide lors de la rééducation du compte.
Une fois que l'utilisateur a ajouté une nouvelle voiture au compte et qu'il sera confirmé avec succès par l'administrateur, l'utilisateur sera en mesure de publier sa voiture (il deviendra piquant à louer à d'autres utilisateurs) ou le masquer. Si la voiture est masquée, lorsque vous cliquez sur le menu correspondant, l'utilisateur pourra cliquer sur le bouton Modify correspondant, puis accéder à la page avec des informations d'édition sur la voiture.
Sur cette page, il pourra modifier les informations globales sur la voiture (cependant, il ne pourra pas modifier l'image de la voiture et sa catégorie à des fins que s'il avait une telle opportunité, après avoir confirmé la voiture par l'administrateur, il pourrait charger n'importe quelle image, après quoi d'autres utilisateurs auraient vu des informations incorrectes et universelles dans son catalogue).
TODO: changez tout ce qui se passe ci-dessous.
Dès que l'utilisateur autorisé appuie sur le bouton Information du véhicule depuis le catalogue, il ouvre la page correspondante avec la voiture sélectionnée et des informations plus détaillées sur la copie. À partir de cette page, bientôt, il sera possible de passer des commandes qui seront enregistrées dans le compte personnel de l'utilisateur.
J'ai ajouté un bouton pour la transition vers le compte personnel de l'utilisateur après l'autorisation, qui permet à l'utilisateur de suivre leurs commandes et les voitures ajoutées par lui (jusqu'à présent, seuls les boutons Publish et Hide sont actifs pour interagir avec les voitures).
Sur cette page, l'utilisateur pourra non seulement voir et modifier ses informations, mais aussi pour contrôler ses voitures et ses ordres. Après les données de l'utilisateur, vous pouvez voir le compteur suivant:
De plus, sur cette page, vous pouvez afficher des informations telles que:
Lorsque vous travaillez avec une table de voiture, vous pouvez observer 3 couleurs:
Selon l'état et la couleur de la voiture, les nouvelles / anciennes fonctions sont ouvertes / bloquées à l'utilisateur
Comme mentionné ci-dessus, pour un système utilisateur autorisé, il devient possible d'entrer son compte personnel et de suivre toutes les informations liées à ses commandes, ainsi que les voitures que cet utilisateur a fournies pour les autres utilisateurs de notre service. Mais que se passe-t-il si certaines informations n'ont pas été saisies, si les données de l'utilisateur ont changé ... ou peut-être que l'utilisateur qui a publié une voiture décide de выделться d'une manière ou d'une autre dans le contexte d'autres ??? Pour résoudre ces problèmes, j'ai développé des pages avec l'édition d'informations sur l'utilisateur actuel et sur ses voitures:
À partir de votre compte personnel, accédez à la page avec des informations d'édition sur vous-même, l'utilisateur peut en cliquant sur le bouton Edit Profile correspondant
Lorsque vous appuyez sur, l'utilisateur ouvre une page sur laquelle il peut modifier toutes les informations affichées sur la page
En particulier: l'avatar de son profil (à choisir parmi 7 images parmi les proposés (1 par défaut, qui est affecté à chaque nouvel utilisateur, et 6 autres à choisir)))
Vous pouvez également modifier votre mot de passe. J'ai fait l'établissement d'un nouveau mot de passe de telle manière que le précédent n'est pas nécessaire (en réalité, il serait nécessaire de demander un vrai mot de passe avant d'installer un nouveau)
D'une simple, l'utilisateur peut modifier n'importe lequel des champs de cette page (par exemple, la description du profil, son numéro de téléphone, son e-mail, etc.). Une fois que tous les utilisateurs de champ sont modifiés, vous devez cliquer sur le bouton Save Changes correspondant (le nouveau mot de passe est installé automatiquement lorsque le bouton Save est appuyé sur la page avec l'installation d'un nouveau mot de passe). Si une sorte d'erreur a été commise lors du remplissage des champs, l'utilisateur peut cliquer sur le bouton Cancel Chnages , qui renverra la page à son formulaire d'origine (vers les anciens données), ou appuyez sur le bouton Get Back , qui le transférera vers son compte personnel.
En fait, en ce qui concerne les voitures, l'utilisateur peut également modifier cette information ou celle qui était précédente sur la page:
Cependant, le nombre de champs disponibles pour un changement est plusieurs fois inférieur à celui de l'utilisateur. Pourquoi alors? Le fait est que lors du développement, l'idée m'est venue à l'esprit: chaque voiture est surveillée par le nombre de commandes. Mais que se passe-t-il si l'utilisateur pouvait changer complètement la voiture, disons, changer son image et son nom? La note de cette voiture resterait la même, mais la description détaillée aurait complètement changé. Quant à moi, une telle approche pourrait jouer un rôle clé dans la détermination des autres utilisateurs, quelle voiture choisir: par exemple, un utilisateur qui a placé sa voiture il y a un an perdrait clairement auprès d'un utilisateur qui changerait la description de son ancienne voiture en une description d'une nouvelle. Ainsi, j'ai conclu que les informations doivent être cachées à l'édition, et seuls les champs les plus nécessaires sont disponibles: champs avec un tarif, une description, ainsi qu'un emplacement.
Dubo des utilisateurs autorisés peut afficher des informations détaillées sur les voitures d'autres utilisateurs du catalogue. À partir de la page de chaque voiture, l'utilisateur peut aller sur la page avec le placement de la commande pour l'utilisation de cette voiture:
Sur cette page, il est invité à choisir une période de temps dans laquelle il peut utiliser la voiture.
La sélection de l'intervalle de temps est réalisée à l'aide de l'élément daterangepicker , dans lequel j'ai installé: l'heure de début - en arrondissant vers l'heure suivante. L'heure de fin (par défaut) est l'heure de début + 1 heure. Ainsi, le temps minimum pour l'utilisation de la voiture est de 1 heure. Le temps macismal que j'ai établi est de 7 jours depuis le début. Le calcul du montant du paiement se produit selon la formule: le nombre de jours multiplié par le tarif / jour + le nombre d'heures * tarif / heure. Dès que l'utilisateur fait toutes les préparations nécessaires et confirme la commande - il sera redirigé vers la page de paiement:
Sur la page de paiement, toutes les informations nécessaires à l'utilisateur sont données afin de redevenir sa commande. Dès que le paiement sera effectué, les utilisateurs pourront trouver des voitures dans leur compte personnel: l'utilisateur qui possède la voiture verra que la voiture a été louée, et l'utilisateur, qui a loué la voiture, verra des informations complètes sur le temps payé ainsi que toutes les informations concernant le temps et l'heure restants de la fin du bail pour cette voiture. Il semble comme suit:
Lorsque l'utilisateur décide de terminer sa commande avant la date prévue (la commande ne se termine pas avec le système responsable des commandes expirées, mais l'utilisateur qui a passé la commande), il a la possibilité de définir la cote de voiture qu'il a utilisée au cours de la première période du temps:
Encore une fois, l'utilisateur a le choix: mettez une note de la voiture, puis appuyez sur le bouton Submit and Finish correspondant et terminer la commande avec la note, ou sauter une étape avec la note en cliquant sur Finish and not submit , et complétez la commande sans envoyer la note.
La note elle-même peut être vue sur la page avec des informations sur la voiture. Selon les évaluations définies par les utilisateurs, les statistiques générales seront affichées sur la page. Une voiture avec 0 étoiles pouvait être vue ci-dessus, et une page avec une voiture avec une note de put d'un utilisateur est présentée ci-dessous:
Dans cette section, je vais essayer de décrire, mais comment le projet est organisé de l'intérieur, ce qui se passe à l'intérieur de la "boîte noire". Cela aidera à mieux comprendre le projet pour ceux qui ont au moins une petite idée du langage de programmation C # et des aspects de programmation.
Bien sûr, pour travailler avec des données, pour commencer, vous devez décider, mais comment les stocker? Of course, super large projects are used for storage such a database as Oracle, PostgreSQL, MySQL, MSSQL and others. However, the problem of this approach is that access to applications tied to databases can only be obtained if the connection to the same database can be obtained on the user's device (for such a function you have to pay large amounts of money to gigants). Since I do not have large amounts of money, in order to start the project to any user and not experience problems with its testing and use, I put forward the idea of using serialization and decering in the contexts of relative paths. Thus, the problems with obtaining access from users who downloaded the application from the repository should not arise.
Каким же образом происходит получение данных из JSON-файлов и как вообще устроено получение данных? (Для всех локальных хранилищ)
Для того, чтобы не привязываться к какому-то определённому типу хранилищ, мной был применён подход Dependency Injection, а именно внедрение Singleton зависимостей между хранилищами и локальным репозиторием программы. То есть: в моей программе есть интерфейс:
public interface IVehiclesRepositoryЭтот интерфейс будет являться связующим звеном для получения данных. В данном интерфейсе есть набор методов, которые должны быть реализованы для того или иного сервиса, чтоб им можно было пользоваться независимо от реализации методов. Главное, чтоб эти методы были реализованы в том классе, который решит реализовать этот интерфейс. Для реализации локального интерфейса, так как я исользую локальное хранилище данных в файлах, а не в БД, я решил использовать Singleton подход, что будет означать, что объект сервиса будет создаваться только при первом обрпщении к нему, после чего все последующие запросы будут проходить через тот самый сервис. Ниже, мы явно указываем, что если кто-то захочет получить объект этого сервиса через интерфейс, мы дадим ему конкретную реализацию (В данном случае реализацию локального репозитория):
builder . Services . AddSingleton < IVehiclesRepository , VehiclesLocalRepository > ( ) ; // Где требуется IVehiclesRepository - дай реализацию VehiclesLocalRepositoryСами же локальные репозитории реализованы таким образом, чтоб уменьшить количество загрузок из файлов в само приложение. Как только происходит первое обращение к сервису - производится работа метода SetUpLocalRepository. Этот метод запишет в путой объект List<> модели, считанные из JSON - файла, после чего все манипуляции будут проходить непосредственно через сам этот List<>, а если данные будут меняться - будет вызываться асинхронный метод SaveChanges(), который призван асинхронно записать изменения в файл (Повторное считывание файла не происходит, так как мы работаем с объектом List<>, который мы также изменили перед тем, как запрашивать обновление JSON-файла). Таким образом, применённый мной подход не только позволит пользователю получать доступ в кратчайшие сроки, но и позволит избежать излишних нагрузок системы для загрузки данных из файлов каждый раз при обращении к сервису.
In design, I identified the following problem - should the user who added the car to the catalog be able to interact with the same car from the catalog? Bien sûr que non. This approach will allow the user who added the car to the directory to rent his own car (what's the point ???). To avoid this problem, I chose the following approach:
Imagine that at the moment, there are no users or added cars. Here we are launching our application. On the main page we see a map with 0 markers, and in the catalog there are also 0 cars. We create a new account, enter it, share our car. MAIS! The car does not appear in the catalog. Quel est le problème? The fact is that before displaying the car in the catalog, the user who added it should clearly publish a car from his personal account by clicking the Publish button opposite the selected car. As soon as he has been published, nothing will change for this user in the catalog, he will also see 0 cars. CEPENDANT! If we leave the account or create a new one, the catalog will be seen in the catalog that the same car that he shared and which was published by the previous user. Thus, the user who added the car and placed it in the catalog cannot see his own cars (the user can see all his added cars in his personal account). MAIS! After the user shares his car and places it in a catalog from his personal account, although he does not see this car in the catalog, he can go to the main page and pay attention to the fact that his car appeared on the marker’s form (however, he still does not have in the catalog). The fact is that the system shows any user all cars on the map in the form of a marker, which were published in your personal account, regardless of which user is now in the system. However, in the catalog, the system shows the same cars that are shown on the map on the main page in the form of markers, but the condition is also checked that the ID of the owner of the car is not equal to the ID of the current user entering the account. For an unauthorized user, the ID is not checked. He is shown the same cars in the catalog as on the map on the main page.
Таким образом, подводя итог:
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 )
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
