Car sharing center
1.0.0
La idea principal del procedimiento: desarrollar un servicio de aplicación del servicio para compartir automóviles con la visualización de automóviles disponibles en el mapa. En contenido: todo lo que se puede comparar con la esencia Vehicles : automóviles, motocicletas, cualquier vehículo, etc. La aplicación debe ser multifuncional: es necesario tener una gran cantidad de páginas con la capacidad de recibir, agregar, cambiar y eliminar entidades.
pager -A a la página.httpContextAccessor .UserStatusProvider . Agregar mensajes JS usando el servicio SweetAlert2 .ReadMe .Stripe al proyecto. Agregar la funcionalidad de la selección de tiempo y fecha a la página con la ubicación del pedido.JS (aplastado por archivos).Brief Description de la cuenta que colocó el automóvil del usuario. Comenzó a formar parte con la calificación de autos..NET 7 . Trabaje en el motor de búsqueda de la página del catálogo.RepositoryProvider y reduciendo toda la funcionalidad para ello.JWToken Authentication a los controladores de aplicación Web .JWToken y configurando la visualización de la página de un error en el lado del cliente.JSON al almacenamiento en MongoDB Local .MongoDB Atlas para trabajar más con el servicio en la nube.UI . Cambiar el marcador Google Maps API de rojo a un automóvil con el nombre y la imagen.El inicio oficial de la pasantía
Web a la Clean Architecture completa.Domain Layer y la configuración de los primeros modelos. Los modelos se crean en el estilo Rich Domain Models . Anemic Domain Models .Infrastructure Layers Application e infraestructura, así como configurando las primeras interacciones con el servicio y la configuración de DI .PublicAPI .endpoints y sus pruebas manuales.Errors Handling y su procesamiento.Errors Handling a parte Vehicle .endpoints .Azure Key Vault para obtener datos secretos con Azure . Implementación de banderas de mordedura como una de las opciones para almacenar información sobre los automóviles.endpoints a CustomerController y sus pruebas manuales.endpoints al VehicleController y sus pruebas manuales.IHttpClientFactory para crear clientes para enviar requisitos a PublicAPI . Configuración Polly para mensajes de envío no metnámicos con la posibilidad de esperar y rehacerlos en caso de situaciones críticas.PublicApi junto con Web y verificación de puntos finales y serialización y deserización entre programas.JWToken recibido del servidor en el lado del cliente con una entrada exitosa a la cuenta.UI de registro, autorización y agregando un auto nuevo.errors handling en la parte del cliente al agregar un automóvil nuevo.html y algunos endpoints .Bootstrap 5+ y eliminar la lógica de la página de registro y autorización.GoogleMaps Api y la corrección de errores.Appsettings.json . Configuración y la primera interacción con Duende Identity Server .Identity Server y limpio el proyecto de archivos innecesarios.Duende Identity Server a Web Application (parte del cliente).Duende Identity Server para el uso de JWT-Authorization hecha a medida y creando la página Dashboard (cuenta personal del usuario).Duende Identity Server para trabajar con MongoDB Entities .Duende Identity Server . Establecer AzureAD como una de las formas de autorización. Agregar nuevas entidades al MSSQL Server .Identity Server .JwtBearer . Establecer AzureAD . Conexión Azure Blob Storage como uno de los mecanismos para almacenar imágenes de automóviles.Pipeline configurada entre la aplicación del servidor y ambas bases de datos. Agregue ActionNotes Repository como uno de los servicios a la aplicación.Dashboard . Actualizó la estructura de la base de datos, donde se agregó una nueva columna. Pipeline está configurado para recibir datos para enviar información sobre la cuenta del cliente.Dashboard .Dashboard . Las funciones ajax se agregan para descargar una página sin actualización. Se agregó una función de búsqueda por criterios.pipeline para mostrar datos en los automóviles en el catálogo.GoogleMaps Api .Stripe .VehicleInformation .Azure VM . Establecer Seq y alojamiento en AzUrevm. Configuración del acceso de una aplicación naval a su base de datos MSSQL .GitHub Actions y Publish automático en Merge con Main branch .Http a Https y agregue nuevas funciones.Rental y Payment y estado de ánimo Azure VM .Stripe Payment Service en el lado del servidor.Stripe . Trabaje en la creación de Stripe Checkout Sessions .Requests y Responses del servidor al manipular pedidos en el cliente.Runtime y obtener un formulario al cambiar el estado de un pedido.DateTime , solicitudes en la base de datos y trabaja sobre la funcionalidad de la aplicación.Routing-ом y la configuración de las páginas Muestra con información de error..tagets para resolver el problema de la versión de los mismos paquetes en diferentes proyectos.Endpoints para editar datos de automóviles.pipeline entre todos los controladores del cliente y el servidor después de agregar atributos a los parámetros de los controladores.server response en el lado del cliente y configurando el controlador universal de estas responses .DateTime.Now (hora local) al objeto DateTime.UtcNow (tiempo UTC).Routing en la parte del servidor en estilo REST .pipeline para editar información. Este proyecto es una aplicación Web completa que funciona al mismo nivel con PublicAPI , escrita en el estilo de Clean Architecture , que permite a cualquier persona que tenga una tarjeta de alquiler válida y una licencia de conducir para obtener un automóvil de otro usuario durante un tiempo, que también se registra, pero no con el objetivo de alquilar el automóvil de otra persona, pero proporcionar sus automóviles para sus automóviles usando otros usuarios. Por lo tanto, los desarrolladores de la aplicación pueden obtener la ventaja, recibiendo un porcentaje de transacciones realizadas por los usuarios y directamente los propios usuarios alquilando o arrendando sus automóviles.
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 y MongoDB )GitHub Actions y Action Runners de Github)Azure VM )y otros ...
Todo el proyecto fue escrito desde cero, utilizando bootstrap 5+ para decorar el componente visual, así como el uso de la funcionalidad de Razor Pages , bueno, C# .NET Core para escribir un componente backend . Como modelo de interacción, tomé una decisión hacia MVC . En la salida estamos tratando con Client-Server MVC Wep App .
Tan pronto como un usuario no autorizado inicia la aplicación, inmediatamente ve la pantalla principal con información sobre el servicio. Esta página contiene toda la información necesaria para familiarizarse con el nuevo usuario con todas las capacidades del servicio. En la parte superior puede ver el elemento navbar , que es todo el tiempo en cualquiera de las páginas y no desaparece del campo de visión diseñado para llevar a cabo la navegación del usuario en el apéndice. Navbar ofrece las siguientes oportunidades:
Además, en la página hay un mapa de Google, que muestra la ubicación de todos los autos disponibles, no alquilados del catálogo (aparecen marcadores en el mapa, según el cual se puede rastrear la ubicación actual de los vehículos. Cuando se confía al marcador, aparecerá una imagen de un vehículo con su nombre). Como restricción, elegí la ciudad de Minsk, es decir, el mapa se encuentra de tal manera que cubra toda el área de la ciudad. Si el automóvil, por ejemplo, estará en algún lugar de las calles de Brest, entonces no lo veremos en el mapa (o será necesario cambiar la escala de la tarjeta). Como ubicaciones disponibles para colocar automóviles, decidí limitarme a Bielorrusia, es decir, un automóvil colocado por un usuario autorizado debería estar en la República de Bielorrusia. Sin embargo, nada impide que el usuario cree un pedido para un automóvil en otra ciudad o incluso en un país.
Con respecto a la tarjeta en sí, estaba conectada a la aplicación utilizando una clave especial, que funciona sin restricciones para encontrar una ubicación de acuerdo con la famosa latitud y longitud.
Independientemente de la página, en la parte inferior, habrá información sobre los desarrolladores de la aplicación y los enlaces a lo social correspondiente. Sam Solutions Networks and Resources.
En la página con el catálogo, los usuarios tendrán la oportunidad de ver toda la información breve asequible sobre los automóviles, así como para buscar criterios entre los automóviles dados en el catálogo. En la página hay una oportunidad:
Con respecto a la información sobre los automóviles, se presenta el catálogo:
La página también tiene la oportunidad de causar el formulario necesario para la implementación de una búsqueda de puntos de vehículos. Aquí, se proporcionan muchos filtros diferentes al usuario, con los que puede encontrar autos de interés para él en el catálogo.
Por lo tanto, el catálogo le permite considerar la variedad de los vehículos presentados y elegir cualquier copia de su gusto y color.
Tan pronto como el usuario presiona el Log In , inmediatamente redirige a la página de autorización.
En la página de autorización, un usuario no autorizado, deberá ingresar su correo electrónico (o iniciar sesión) y contraseña para una autorización exitosa. Cuando se mostrará un error al completar el campo, se mostrará un mensaje de error al completar:
Si todos los campos se llenan correctamente, pero la autorización no ha pasado, el usuario presentará un mensaje sobre la autorización fallida:
Con una autorización exitosa, un usuario ya autorizado será redirigido a la página del tablero (cuenta personal), en el que habrá un mensaje sobre la autorización exitosa, que desaparece automáticamente 3 segundos después de su aparición.
Si el usuario no tiene su propia cuenta, el usuario necesita crear su propia cuenta, la transición a la página para implementar que se lleva a cabo a través del botón Sign Up en el elemento Navbar derecho.
En la página con el registro de un nuevo usuario, será necesario ingresar una serie de datos para que el programa ingrese al cliente en la base de datos y el registro sea exitoso. Toda la página está llena de validación, y si algo no pasa, el usuario no será notificado del campo en el que ocurrió el error (el mismo principio que con el peludo de la autorización). Después de un registro exitoso, el usuario será redirigido a la página de registro en la que habrá un mensaje sobre el registro exitoso.
Tan pronto como el usuario ingrese con éxito en su cuenta recién creada, tendrá la oportunidad no solo de ver información más detallada sobre los automóviles en el catálogo, sino también para agregar sus propios autos, así como rastrear estadísticas sobre sus acciones y acciones de otros usuarios con sus automóviles.
En esta página, el usuario tendrá que proporcionar información relevante sobre su automóvil, así como establecer la tarifa en la que se alquilará el automóvil. La página también tiene validación (similar a la página de autorización y registro). Tan pronto como el usuario comparta con éxito su automóvil, aparecerá inmediatamente en su cuenta, sin embargo, para su publicación, el administrador debe aprobar la aplicación, después de lo cual el usuario podrá publicar el automóvil a través de su cuenta personal, así como editar información e interactuar con este automóvil de todas las formas posibles. (Dado que el usuario agregó su automóvil, es lógico que no sea del todo lógico y correcto mostrarlo en el catálogo al mismo usuario. Sin embargo, aún se muestran en el catálogo, pero al ir a la página con información sobre este automóvil, el propietario no podrá alquilarlo, pero él podrá conocer su descripción y representación para otros usuarios).
En la página del tablero a un usuario autorizado, se propone rogar para secar las estadísticas de su cuenta. En esta página, el usuario puede ver la información como:
Desde la página del tablero, el usuario tiene la oportunidad de llegar a las páginas con información de edición sobre el automóvil o en la página de la información de la cuenta de edición.
La página principal permite al usuario cambiar algunos campos asociados con su cuenta (como el nombre, el apellido, el apodo, el correo, etc.)
El menú Head tiene varios botones a la izquierda, después de presionar 2 de los cuales hay mini vientos, que también sirven para cambiar alguna información de la cuenta.
Al hacer clic en el botón correspondiente en la página de la cabeza, está invitado al usuario a elegir uno de los avatares que representará su perfil. Tan pronto como el usuario seleccione uno de los avatares, después de lo cual haga clic en Apply y Save changes , el avatar se actualizará y el usuario podrá observar otra imagen en su cuenta.
Cuando se presione el siguiente botón, el usuario tendrá la oportunidad de ingresar una nueva contraseña desde su cuenta, después de lo cual la contraseña de su cuenta se actualizará por completo y la contraseña anterior no será válida al volver a ingresar la cuenta.
Después de que el usuario agrega un auto nuevo a la cuenta y el administrador lo confirmará con éxito, el usuario podrá publicar su automóvil (se convertirá en un acre para alquilar a otros usuarios) o ocultarlo. Si el automóvil está oculto, al hacer clic en el menú correspondiente, el usuario podrá hacer clic en el botón Modify correspondiente y luego ir a la página con información de edición sobre el automóvil.
En esta página, podrá cambiar la información general sobre el automóvil (sin embargo, no podrá cambiar la imagen del automóvil y su categoría para el propósito de que si tuviera tal oportunidad, después de confirmar el automóvil por el administrador, podría cargar ninguna imagen, después de lo cual otros usuarios habrían visto información incorrecta y universal en su catalógeno).
TODO: Cambia todo lo que va a continuación.
Tan pronto como el usuario autorizado presione el botón Information en el vehículo desde el catálogo, abre la página correspondiente con el automóvil seleccionado y la información más detallada sobre la copia. Desde esta página, pronto, será posible realizar pedidos que se registrarán en la cuenta personal del usuario.
Agregué un botón para la transición a la cuenta personal del usuario después de la autorización, que permite al usuario rastrear sus pedidos y los autos agregados por él (hasta ahora solo Publish y Hide los botones están activos para interactuar con los automóviles).
En esta página, el usuario podrá no solo ver y cambiar su información, sino también controlar sus autos y sus órdenes. Después de los datos del usuario, puede ver el siguiente contador:
Además, en esta página puede ver la información como:
Cuando trabaja con una mesa de automóvil, puede observar 3 colores:
Dependiendo del estado y el color del automóvil, las funciones nuevas/antiguas están abiertas/bloqueadas al usuario
Como se mencionó anteriormente, para el sistema de un usuario autorizado, es posible ingresar su cuenta personal y rastrear toda la información relacionada con sus pedidos, así como los autos que este usuario proporcionó a otros usuarios de nuestro servicio. Pero, ¿qué pasa si no se ingresó alguna información, si los datos del usuario han cambiado ... o tal vez el usuario que publicó un automóvil decide de alguna manera выделться en el contexto de otros? Para resolver estos problemas, desarrollé páginas con información de edición sobre el usuario actual y sobre sus automóviles:
Desde su cuenta personal, vaya a la página con información de edición sobre usted, el usuario puede hacer clic en el botón Edit Profile correspondiente
Al presionar, el usuario abre una página en la que puede cambiar cualquier información que se muestre en la página
En particular: el avatar de su perfil (para elegir entre 7 imágenes de la propuesta (1 predeterminada, que se asigna a cada nuevo usuario, y otros 6 para elegir)))
También puede cambiar su contraseña. Hice el establecimiento de una nueva contraseña de tal manera que la anterior no sea necesaria (en realidad, sería necesario solicitar una contraseña real antes de instalar una nueva)
Desde uno simple, el usuario puede cambiar cualquiera de los campos en esta página (por ejemplo, descripción del perfil, su número de teléfono, correo electrónico, etc.). Después de cambiar todos los usuarios del campo, debe hacer clic en el botón Save Changes correspondiente (la nueva contraseña se instala automáticamente cuando se presiona el botón Save en la página con la instalación de una nueva contraseña). Si se cometió algún tipo de error al llenar los campos, el usuario puede hacer clic en el botón Cancel Chnages , que devolverá la página a su formulario original (Tobish a los datos antiguos), o presionar el botón Get Back , que la transferirá a su cuenta personal.
En realidad, con respecto a los automóviles, el usuario también puede cambiar esta o aquella información anterior en la página:
Sin embargo, el número de campos disponibles para un cambio es varias veces menor que el del usuario. ¿Por qué eso? El hecho es que al desarrollar, la idea se me ocurrió: cada automóvil es monitoreado por el número de pedidos. Pero, ¿qué pasaría si el usuario pudiera cambiar el auto por completo, digamos, cambiar su imagen y nombre? La calificación de este automóvil seguiría siendo la misma, pero la descripción detallada habría cambiado por completo. En cuanto a mí, este enfoque podría desempeñar un papel clave en la determinación de otros usuarios, qué automóvil elegir: por ejemplo, un usuario que colocó su automóvil hace un año claramente perdería a un usuario que cambiaría la descripción de su antiguo automóvil a una descripción de uno más nuevo. Por lo tanto, concluí que la información debe estar oculta para la edición, y solo los campos más necesarios están disponibles: campos con una tarifa, descripción, así como una ubicación.
Dubo de usuarios autorizados puede ver información detallada sobre los automóviles de otros usuarios en el catálogo. Desde la página de cada automóvil, el usuario puede ir a la página con la ubicación del pedido para usar este automóvil:
En esta página, está invitado a elegir un período de tiempo en el que pueda usar el automóvil.
La selección del intervalo de tiempo se lleva a cabo utilizando el elemento daterangepicker , en el que instalé: la hora de inicio - redondeo hacia la siguiente hora. La hora de finalización (predeterminada) es la hora de inicio + 1 hora. Por lo tanto, el tiempo mínimo para usar el automóvil es de 1 hora. El tiempo macismal que he establecido son 7 días desde el principio. El cálculo del monto para el pago ocurre de acuerdo con la fórmula: el número de días multiplicado por la tarifa/día + el número de horas * Tarifa/hora. Tan pronto como el usuario realice todos los preparativos necesarios y confirme el pedido, será redirigido a la página de pago:
En la página de pago, se proporciona toda la información necesaria para el usuario para volver a dibujar su pedido nuevamente. Tan pronto como se realice el pago, los usuarios podrán encontrar automóviles en su cuenta personal: el usuario que posee el automóvil verá que el automóvil fue alquilado, y el usuario, que alquiló el automóvil, verá información completa sobre el tiempo pagado, así como toda la información sobre el tiempo restante y el tiempo del final del arrendamiento para este automóvil. Se ve como sigue:
Cuando el usuario decide completar su pedido antes de lo previsto (el pedido no termina con el sistema responsable de las órdenes vencidas, sino el usuario que ha realizado el pedido), tiene la oportunidad de establecer la calificación del automóvil que usó durante el enésimo tiempo de tiempo:
Una vez más, el usuario tiene una opción: coloque una calificación del automóvil y luego presione el botón Submit and Finish correspondiente y complete el pedido con la calificación, o omita un paso con la calificación haciendo clic en Finish and not submit , y complete el pedido sin enviar la calificación.
La calificación en sí se puede ver en la página con información sobre el automóvil. Dependiendo de las evaluaciones establecidas por los usuarios, las estadísticas generales se mostrarán en la página. Se puede ver un automóvil con 0 estrellas arriba, y una página con un automóvil con una calificación calificada de un usuario se muestra a continuación:
En esta sección, intentaré describir, pero cómo se organiza el proyecto desde el interior, lo que está sucediendo dentro de la "caja negra". Esto ayudará a comprender mejor el proyecto para aquellos que tienen al menos una pequeña idea del lenguaje de programación C# y los aspectos de programación.
Por supuesto, para trabajar con cualquier dato, para empezar, debe decidir, pero ¿cómo almacenarlos? 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? Por supuesto que no. 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. ¡PERO! The car does not appear in the catalog. ¿Cuál es el problema? 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. ¡SIN EMBARGO! 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). ¡PERO! 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 )
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
