Car sharing center
1.0.0
A idéia principal do processo: desenvolver um serviço de aplicativo do serviço de compartilhamento de carros com a exibição de carros disponíveis no mapa. No conteúdo - tudo o que pode ser comparado com a essência Vehicles : carros, motocicletas, veículos etc. O aplicativo deve ser multifuncional: é necessário ter um grande número de páginas com a capacidade de receber, adicionar, alterar e excluir entidades.
pager -a à página.httpContextAccessor .UserStatusProvider . Adicionando mensagens JS usando o serviço SweetAlert2 .ReadMe .Stripe para o projeto. Adicionando a funcionalidade da seleção de tempo e data à página com a colocação do pedido.JS (quebrado por arquivos).Brief Description da conta que colocou o carro do usuário. Ele começou a fazer uma parte da classificação para carros..NET 7 . Trabalhe no mecanismo de pesquisa da página do catálogo.RepositoryProvider e reduzindo toda a funcionalidade para ele.JWToken Authentication aos controladores de aplicativos Web .JWToken e configure a exibição da página de um erro no lado do cliente.JSON para o armazenamento no MongoDB Local .MongoDB Atlas para trabalhar ainda mais com o serviço em nuvem.UI . Alterar o marcador Google Maps API de vermelho para um carro com o nome e a imagem.O início oficial do estágio
Web para a Clean Architecture completa.Domain Layer e configurando os primeiros modelos. Os modelos são criados no estilo Rich Domain Models . Anemic Domain Models .Application e Infrastructure Layers , além de configurar as primeiras interações com o serviço e configurar DI .PublicAPI .endpoints e seus testes manuais.Errors Handling e seu processamento.Errors Handling a parte Vehicle .endpoints .Azure Key Vault para obter dados secretos com Azure . Implementação de sinalizadores de mordimentos como uma das opções para armazenar informações sobre carros.endpoints ao CustomerController e seus testes manuais.endpoints ao VehicleController e seus testes manuais.IHttpClientFactory para criar clientes para enviar requetes para PublicAPI . Configuração Polly para mensagens de envio não -metâmico com a possibilidade de esperar e re -dendê -las em caso de situações críticas.PublicApi , juntamente com Web Part e verificando os pontos de extremidade e a serialização e a deserção entre programas.JWToken recebido do servidor no lado do cliente com uma entrada bem -sucedida na conta.UI do usuário de registro, autorização e adição de um carro novo.errors handling na parte do cliente ao adicionar um carro novo.html e alguns endpoints .Bootstrap 5+ e removendo a lógica da página de registro e autorização.GoogleMaps Api e a correção de erros.Appsettings.json . Configurações e a primeira interação com Duende Identity Server .Identity Server e limpo o projeto de arquivos desnecessários.Duende Identity Server ao Web Application (parte do cliente).Duende Identity Server para o uso de JWT-Authorization personalizada e criação da página Dashboard (conta pessoal do usuário).Duende Identity Server para trabalhar com MongoDB Entities .Duende Identity Server . Definindo AzureAD como uma das formas de autorização. Adicionando novas entidades ao MSSQL Server .Identity Server .JwtBearer . Definindo AzureAD . Conexão Azure Blob Storage como um dos mecanismos para armazenar imagens de carro.Pipeline configurado entre o aplicativo do servidor e os dois bancos de dados. Adicione ActionNotes Repository como um dos Serviços ao aplicativo.Dashboard . Atualizou a estrutura do banco de dados, onde uma nova coluna foi adicionada. Pipeline está configurado para receber dados para enviar informações sobre a conta do cliente.Dashboard .Dashboard . As funções ajax são adicionadas para baixar uma página sem atualização. Adicionado uma função de pesquisa por critérios.pipeline para exibir dados sobre carros no catálogo.GoogleMaps Api .Stripe .VehicleInformation .Azure VM . Definir Seq e de exceções de hospedagem no AzureVM. Configurando o acesso de um aplicativo naval ao seu banco de dados MSSQL .GitHub Actions e Publish automático em Merge com Main branch .Http para Https e adicionando novas funções.Rental e Payment e humor Azure VM .Stripe Payment Service no lado do servidor.Stripe . Trabalhe sobre a criação de Stripe Checkout Sessions .Requests e Responses do servidor ao manipular pedidos no cliente.Runtime e obtendo um formulário ao alterar o status de um pedido.DateTime , solicitações no banco de dados e trabalha com a funcionalidade do aplicativo.Routing-ом e configuração de páginas exibidas com informações de erro..tagets para resolver o problema da versão dos mesmos pacotes em diferentes projetos.Endpoints para editar dados do carro.pipeline entre todos os controladores do cliente e o servidor após adicionar atributos aos parâmetros dos controladores.server response no lado do cliente e configure o manipulador universal dessas responses .DateTime.Now (horário local) para o objeto DateTime.UtcNow (tempo da UTC).Routing na parte do servidor em estilo REST .pipeline para editar informações. Este projeto é um aplicativo Web completo, trabalhando no mesmo nível com PublicAPI , escrito no estilo de Clean Architecture , que permite que qualquer pessoa que tenha um cartão de aluguel válido e uma carteira de motorista para obter um carro de outro usuário por um tempo, que também registrou, mas não com o objetivo de alugar o carro de outra pessoa, mas para fornecer carros para seus carros usando outros usuários. Assim, a vantagem pode ser obtida pelos desenvolvedores do aplicativo, recebendo uma porcentagem de transações feitas pelos usuários e diretamente os usuários alugando ou arrendando seus carros.
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 e MongoDB )GitHub Actions e Action Runners )Azure VM )e outros ...
Todo o projeto foi escrito do zero, usando bootstrap 5+ para decorar o componente visual, além de usar a funcionalidade Razor Pages , bem, C# .NET Core para escrever um componente backend . Como modelo de interação, fiz uma escolha para MVC . Na saída, estamos lidando com Client-Server MVC Wep App .
Assim que um usuário não autorizado inicia o aplicativo, ele vê imediatamente a tela principal com informações sobre o serviço. Esta página contém todas as informações necessárias para se familiarizar com o novo usuário com todos os recursos do serviço. No topo, você pode ver o elemento navbar , que é o tempo todo em qualquer uma das páginas e não desaparece do campo de visão projetado para realizar a navegação do usuário no apêndice. Navbar oferece as seguintes oportunidades:
Além disso, na página, há um mapa do Google, que mostra a localização de todos os carros disponíveis, não alugados do catálogo (os marcadores aparecem no mapa, segundo os quais o local atual dos veículos pode ser rastreado. Quando confiado ao marcador, uma imagem de um veículo com seu nome aparecerá). Como restrição, escolhi a cidade de Minsk, ou seja, o mapa está localizado de maneira a cobrir toda a área da cidade. Se o carro, digamos, estará em algum lugar nas ruas de Brest, não o veremos no mapa (ou será necessário alterar a escala do cartão). Como locais disponíveis para a colocação de carros, decidi me limitar à Bielorrússia, ou seja, um carro colocado por um usuário autorizado deveria estar na República da Bielorrússia. No entanto, nada impede o usuário de criar um pedido para um carro em outra cidade ou mesmo em um país.
Em relação ao próprio cartão, ele foi conectado ao aplicativo usando uma chave especial, que funciona sem restrições para encontrar um local de acordo com a famosa latitude e longitude.
Independentemente da página, na parte inferior, haverá informações sobre os desenvolvedores do aplicativo e links para o social correspondente. Redes e recursos da SAM Solutions.
Na página com o catálogo, os usuários terão a oportunidade de visualizar todas as breves informações acessíveis sobre os carros, bem como procurar critérios entre os carros fornecidos no catálogo. Na página, há uma oportunidade:
Em relação às informações sobre carros, o catálogo é apresentado:
A página também tem a oportunidade de causar o formulário necessário para a implementação de uma busca de pontos por veículos. Aqui, muitos filtros diferentes são fornecidos ao usuário, com os quais ele pode encontrar carros de interesse para ele no catálogo.
Assim, o catálogo permite que você considere a variedade dos veículos apresentados e escolha qualquer cópia para o seu gosto e cor.
Assim que o usuário pressiona o Log In , ele imediatamente redireciona para a página de autorização.
Na página de autorização, um usuário não autorizado, você precisará inserir seu email (ou login) e senha para autorização bem -sucedida. Quando um erro ao preencher o campo, uma mensagem de erro será exibida ao preencher:
Se todos os campos estiverem preenchidos corretamente, mas a autorização não passou, o usuário apresentará uma mensagem sobre autorização malsucedida:
Com a autorização bem -sucedida, um usuário já autorizado será redirecionado para a página do painel (conta pessoal), na qual haverá uma mensagem sobre autorização bem -sucedida, que desaparece automaticamente 3 segundos após sua aparência.
Se o usuário não tiver sua própria conta, o usuário precisará criar sua própria conta, a transição para a página para implementar, que é realizada através da pressão do botão de Sign Up no elemento Navbar direito.
Na página com o registro de um novo usuário, será necessário inserir uma série de dados para que o programa entre no cliente no banco de dados e o registro seja bem -sucedido. A página inteira é preenchida com validação e, se algo não passar, o usuário não será notificado do campo em que o erro ocorreu (o mesmo princípio que com a desfeita da autorização). Após o registro bem -sucedido, o usuário será redirecionado para a página de registro na qual haverá uma mensagem sobre o registro bem -sucedido.
Assim que o usuário inserir com sucesso sua conta recém -criada, ele terá a oportunidade não apenas de visualizar informações mais detalhadas sobre carros no catálogo, mas também para adicionar seus próprios carros, além de rastrear estatísticas sobre suas ações e ações de outros usuários com seus carros.
Nesta página, o usuário terá que fornecer informações relevantes sobre seu carro, além de definir a tarifa na qual o carro será alugado. A página também possui validação (semelhante à página de autorização e registro). Assim que o usuário compartilha com sucesso seu carro, ele aparecerá imediatamente em sua conta, no entanto, para sua publicação, o administrador deve aprovar o aplicativo, após o qual o usuário poderá publicar o carro por meio de sua conta pessoal, além de editar informações e interagir com este carro de todas as maneiras possíveis. (Como o usuário adicionou seu carro, é lógico que não seja totalmente lógico e correto mostrá -lo no catálogo ao mesmo usuário. No entanto, eles ainda aparecem no catálogo, mas, ao ir à página com informações sobre este carro, o proprietário não poderá alugá -lo, mas ele poderá se adquirir com sua descrição e representação de outros usuários).
Na página do painel para um usuário autorizado, é proposto implorar para secar as estatísticas de sua conta. Nesta página, o usuário pode visualizar as informações como:
Na página do painel, o usuário tem a oportunidade de chegar às páginas com informações de edição sobre o carro ou na página de informações da conta de edição.
A página principal permite que o usuário altere alguns campos associados à sua conta (como o nome, sobrenome, apelido, correio etc.)
O menu principal possui vários botões à esquerda, depois de pressionar 2 dos quais existem mini-ventos, que também servem para alterar algumas informações da conta.
Ao clicar no botão correspondente na página da cabeça, o usuário é convidado a escolher um dos avatares que representará seu perfil. Assim que o usuário selecionar um dos avatares, após o qual clicará no botão Apply e Save changes , o avatar será atualizado e o usuário poderá observar outra imagem em sua conta.
Quando o botão próximo for pressionado, o usuário terá a oportunidade de inserir uma nova senha em sua conta, após a qual a senha da sua conta será completamente atualizada e a senha antiga será inválida ao ser lançada na conta.
Depois que o usuário adicionar um carro novo à conta e ele será confirmado com sucesso pelo administrador, o usuário poderá publicar seu carro (ele se tornará um pungente para alugar para outros usuários) ou ocultá -lo. Se o carro estiver oculto, ao clicar no menu correspondente, o usuário poderá clicar no botão Modify correspondente e, em seguida, vá para a página com informações de edição sobre o carro.
Nesta página, ele poderá alterar as informações gerais sobre o carro (no entanto, ele não poderá alterar a imagem do carro e sua categoria com o objetivo de que, se ele tivesse essa oportunidade, depois de confirmar o carro pelo administrador, ele poderia carregar qualquer imagem, após o que outros usuários teriam visto informações incorretas e universais em seu catálogo).
TODO: mude tudo o que fica abaixo.
Assim que o usuário autorizado pressionar o botão Information no veículo do catálogo, ele abre a página correspondente com o carro selecionado e informações mais detalhadas sobre a cópia. A partir desta página, em breve, será possível fazer pedidos que serão registrados na conta pessoal do usuário.
Adicionei um botão para a transição para a conta pessoal do usuário após a autorização, que permite ao usuário rastrear seus pedidos e os carros adicionados por ele (até agora, apenas Publish e Hide botões estão ativos para interagir com carros).
Nesta página, o usuário poderá não apenas visualizar e alterar suas informações, mas também para controlar seus carros e ordens. Após os dados do usuário, você pode ver o seguinte contador:
Além disso, nesta página, você pode visualizar as informações como:
Ao trabalhar com uma mesa de carro, você pode observar 3 cores:
Dependendo do estado e da cor do carro, funções novas/antigas são abertas/bloqueadas para o usuário
Como mencionado acima, para o sistema de um usuário autorizado, torna -se possível inserir sua conta pessoal e acompanhar todas as informações relacionadas aos seus pedidos, bem como aos carros que esse usuário forneceu a outros usuários de nosso serviço. Mas e se alguma informação não fosse inserida, se os dados do usuário mudaram ... ou talvez o usuário que publicou um carro decida de alguma forma выделться no cenário de outros ??? Para resolver esses problemas, desenvolvi páginas com informações de edição sobre o usuário atual e sobre seus carros:
Na sua conta pessoal, vá para a página com informações de edição sobre si mesmo, o usuário pode clicar no botão Edit Profile correspondente
Ao pressionar, o usuário abre uma página na qual ele pode alterar qualquer informação exibida na página
Em particular: o avatar de seu perfil (para escolher entre 7 imagens do proposto (1 padrão, que é atribuído a cada novo usuário, e outros 6 para escolher))
Você também pode alterar sua senha. Fiz o estabelecimento de uma nova senha de tal maneira que a anterior não é necessária (na realidade, seria necessário solicitar uma senha real antes de instalar uma nova)
A partir de um simples, o usuário pode alterar qualquer um dos campos nesta página (por exemplo, descrição do perfil, número de telefone, e-mail etc.). Depois que todos os usuários de campo são alterados, você deve clicar no botão Save Changes correspondente (a nova senha é instalada automaticamente quando o botão Save é pressionado na página com a instalação de uma nova senha). Se algum tipo de erro foi cometido ao preencher os campos, o usuário poderá clicar no botão Cancel Chnages , que retornará a página ao seu formulário original (tobando para os dados antigos) ou pressione o botão Get Back , que o transferirá de volta para sua conta pessoal.
Na verdade, em relação aos carros, o usuário também pode alterar esta ou as informações anteriores na página:
No entanto, o número de campos disponíveis para uma alteração é várias vezes menor que o do usuário. Por que sim? O fato é que, ao se desenvolver, a idéia me ocorreu: todo carro é monitorado pelo número de pedidos. Mas e se o usuário pudesse mudar completamente o carro, digamos, mudar sua imagem e nome? A classificação deste carro permaneceria a mesma, mas a descrição detalhada teria mudado completamente. Quanto a mim, essa abordagem poderia desempenhar um papel fundamental na determinação de outros usuários, qual carro escolher: por exemplo, um usuário que colocou seu carro há um ano perderia claramente para um usuário que mudaria a descrição de seu carro antigo para uma descrição de um mais novo. Assim, concluí que as informações precisam estar ocultas da edição e apenas os campos mais necessários estão disponíveis: campos com tarifa, descrição e um local.
O DuBo de usuários autorizados pode visualizar informações detalhadas sobre carros de outros usuários no catálogo. Na página de cada carro, o usuário pode ir para a página com a colocação do pedido para usar este carro:
Nesta página, ele é convidado a escolher um período em que ele possa usar o carro.
A seleção do intervalo de tempo é realizada usando o elemento daterangepicker , no qual instalei: o horário de início - arredondando para a próxima hora. O horário final (padrão) é o horário de início + 1 hora. Assim, o tempo mínimo para usar o carro é de 1 hora. O tempo macismal que eu defini é de 7 dias desde o início. O cálculo do valor do pagamento ocorre de acordo com a fórmula: o número de dias multiplicado pela tarifa/dia + o número de horas * Tarifa/hora. Assim que o usuário fizer todos os preparativos necessários e confirmar o pedido - ele será redirecionado para a página de pagamento:
Na página de pagamento, todas as informações necessárias para o usuário são fornecidas para redesenhar seu pedido novamente. Assim que o pagamento for feito, os usuários poderão encontrar carros em sua conta pessoal: o usuário que possui o carro verá que o carro foi alugado e o usuário, que alugou o carro, verá informações completas sobre o tempo pago, bem como todas as informações sobre o restante e a hora do fim do arrendamento deste carro. Parece o seguinte:
Quando o usuário decide concluir seu pedido antes do previsto (o pedido não termina com o sistema responsável pelos pedidos expirados, mas o usuário que fez o pedido), ele tem a oportunidade de definir a classificação do carro que ele usou ao longo do tempo de tempo:
Novamente, o usuário tem uma opção: Coloque uma classificação do carro e, em seguida, pressione o botão Submit and Finish correspondente e conclua o pedido com a classificação, ou pule uma etapa com a classificação clicando no Finish and not submit o botão e preencha o pedido sem enviar a classificação.
A classificação em si pode ser vista na página com informações sobre o carro. Dependendo das avaliações definidas pelos usuários, as estatísticas gerais serão exibidas na página. Um carro com 0 estrelas pode ser visto acima, e uma página com um carro com uma classificação rastreada de um usuário é mostrada abaixo:
Nesta seção, tentarei descrever, mas como o projeto é organizado por dentro, o que está acontecendo dentro da "caixa preta". Isso ajudará a entender melhor o projeto para aqueles que têm pelo menos uma pequena idéia dos aspectos da linguagem de programação C# e programação.
Obviamente, para trabalhar com algum dado, para iniciantes, você precisa decidir, mas como armazená -los? 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? Claro que não. 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. MAS! The car does not appear in the catalog. Qual é o 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. NO ENTANTO! 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). MAS! 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 )
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
