Car sharing center
1.0.0
절차의 주요 아이디어 :지도에 사용 가능한 자동차를 표시하여 자동차 공유 서비스의 애플리케이션 서비스를 개발합니다. 내용 - Vehicles 본질과 비교할 수있는 모든 것 : 자동차, 오토바이, 차량 등. 응용 프로그램은 다기능이어야합니다. 엔티티를 수신, 추가, 변경 및 삭제할 수있는 많은 페이지가 있어야합니다.
pager 추가.httpContextAccessor 기반으로 사용자와 협력합니다.UserStatusProvider 상태의 스토리지 시설로의 전환. SweetAlert2 서비스를 사용하여 JS 메시지 추가.ReadMe 와 협력하십시오.Stripe 결제 서비스의 테스트 모드에서 연결. 순서 배치를 통해 페이지에 시간과 날짜 선택의 기능을 추가합니다.JS 코드의 위치를 변경했습니다 (파일로 분쇄).Brief Description 카탈로그의 자동차에 대한 정보와 함께 페이지에 기회를 추가했습니다. 그는 자동차 등급에 참여하기 시작했습니다..NET 7 . 카탈로그 페이지의 검색 엔진에서 작업하십시오.RepositoryProvider 비더로 다양한 리포지토리를 교체하고 모든 기능을 줄입니다.Web -Application 컨트롤러에 JWToken Authentication 추가.JWToken 사용하여 클라이언트 측에서 오류의 페이지 표시를 설정합니다.MongoDB Local 의 정보 저장에서 JSON 파일로의 스토리지로 전환하기 위해 리팩토링.MongoDB Atlas 클러스터 설정.UI 에서 작업하십시오. Google Maps API 마커를 빨간색에서 이름과 이미지가있는 자동차로 변경합니다.인턴쉽의 공식 시작
Web 응용 프로그램에서 전체 실과 된 Clean Architecture 로 전환.Domain Layer 으로 작업하고 첫 번째 모델을 설정하십시오. 모델은 Rich Domain Models 스타일로 만들어집니다. Anemic Domain Models .Application 및 Infrastructure Layers 과 협력 할뿐만 아니라 서비스와의 첫 상호 작용을 설정하고 DI 설정하십시오.PublicAPI 와 함께 이전에 생성 된 층의 바인딩.endpoints 및 수동 테스트 설정.Errors Handling 및 처리에 대한 작업 시작.Vehicle 모델의 일부에 Errors Handling 추가.endpoints 테스트.Azure 로 비밀 데이터를 얻기 위해 Azure Key Vault 기능 추가. 자동차에 대한 정보를 저장하기위한 옵션 중 하나로 물고 깃발을 구현합니다.CustomerController 및 수동 테스트에 새로운 endpoints 추가.VehicleController 및 수동 테스트에 새로운 endpoints 추가.IHttpClientFactory 추가하여 PublicAPI 로 Requets를 보내기위한 고객을 만듭니다. 비정형 비트 송신 메시지에 대한 Polly 구성은 중요한 상황의 경우 대기 및 재 징수 가능성이있는 메시지를받을 가능성이 있습니다.Web 부분과 함께 PublicApi 의 바인딩 및 엔드 포인트 및 프로그램 간 직렬화 및 사막화 확인.JWToken 보존합니다.UI 페이지에 대한 작업.errors handling 추가됩니다.html 페이지 및 일부 endpoints 의 취소.Bootstrap 5+ 로 전환하고 등록 및 승인 페이지의 논리를 제거합니다.GoogleMaps Api 및 오류 수정으로 작업하십시오.Appsettings.json 파일 작업. 설정 및 Duende Identity Server 와의 첫 번째 상호 작용.Identity Server 에 대한 규칙을 설정하고 불필요한 파일에서 프로젝트를 정리합니다.Duende Identity Server 바인딩 Web Application (클라이언트 부품).Duende Identity Server 사용하여 Custom -Made JWT-Authorization 사용하고 Dashboard 페이지 생성 (사용자 개인 계정)으로 전환합니다.MongoDB Entities 와 협력하기위한 Duende Identity Server 구축하려는 시도.Duende Identity Server 삭제. AzureAD 승인 방법 중 하나로 설정하십시오. MSSQL Server 에 새 엔티티 추가.Identity Server 설정과 관련된 파일에서 프로젝트 청소.JwtBearer 통한 승인 조정. AzureAD 설정. 자동차 이미지를 저장하기위한 메커니즘 중 하나로 연결 Azure Blob Storage 연결하십시오.Pipeline 설정되었습니다. ActionNotes Repository 애플리케이션에 서비스 중 하나로 추가하십시오.Dashboard 페이지에 고객에 대한 일부 데이터 표시와 관련된 새로운 기회가 추가됩니다. 새 열이 추가 된 데이터베이스의 구조를 업데이트했습니다. Pipeline 고객의 계정에 대한 정보를 제출하기 위해 데이터를 수신하도록 구성됩니다.Dashboard 페이지에서 작업하십시오.Dashboard 페이지에서 차량과 관련된 조치 설정. ajax 함수는 업데이트없이 페이지를 다운로드하도록 추가됩니다. 기준별로 검색 기능을 추가했습니다.pipeline 공급.GoogleMaps Api 와 협력하기위한 새 페이지를 추가합니다.Stripe Payment Service와의 통합 추가.VehicleInformation 페이지로 작업 할 때 소프트웨어 방법 작업.Azure VM 과 함께 작업하십시오. AzureVM에서 Seq 설정 및 호스팅 예외 서비스. MSSQL 데이터베이스에 해군 응용 프로그램 액세스를 설정합니다.GitHub Actions 및 Main branch 와의 Merge Publish 작업.Http 에서 Https 로 전송하고 새로운 기능을 추가합니다.Rental 및 Payment 모델 및 Azure VM Mood 추가.Stripe Payment Service 와 상호 작용하기 위해 별도의 서비스를 작업하십시오.Stripe 와 관련된 오류를 제거하는 작업. Stripe Checkout Sessions 제작에 대한 작업.Requests 및 Responses 설정.Runtime 처리 및 주문 상태를 변경할 때 양식을 얻는 원칙을 설정합니다.DateTime 사용한 오류 수정, 데이터베이스의 요청 및 응용 프로그램 기능에 대한 작업.Routing-ом 및 페이지 설정에 대한 작업..tagets 파일을 추가합니다.Endpoints 작업.pipeline 의 최종 구성.server response 분석기에서 작업하고 이러한 responses 의 범용 처리기를 설정하십시오.DateTime.Now 에서 객체 DateTime.UtcNow (UTC Time)로 전체 사이트의 번역.REST Routing 설정.pipeline 작업을 수행하여 정보를 편집하십시오. 이 프로젝트는 Clean Architecture Style으로 작성된 PublicAPI 와 같은 수준으로 작동하는 전체 Web 애플리케이션으로, 유효한 임대 카드와 운전 면허증이있는 사람은 다른 사용자의 자동차를 한동안 얻을 수 있지만 다른 사람의 자동차를 임대하는 것이 아니라 다른 사용자를 사용하여 자동차를 제공 할 수있는 사람은 한동안 다른 사용자의 자동차를 얻을 수 있습니다. 따라서, 응용 프로그램 개발자가 이점을 얻을 수 있으며, 사용자가 만든 거래의 비율을 받고 사용자가 직접 자동차를 임대하거나 임대하는 사용자가 직접 얻을 수 있습니다.
Stripe 와 통합)SweetAlert2 )Google Maps API )Stripe )ErrorOr NuGet Package )JWT Bearer NuGet Package )Azure Key Vault )Azure Blob Storage )Azure AD )Seq Service )Polly )Lets Encrypt Service )PVS Studio )MSSQL 및 MongoDB )GitHub Actions 및 Action Runners )Azure VM )그리고 다른 것들 ...
전체 프로젝트는 bootstrap 5+ 사용하여 시각적 구성 요소를 장식하고 Razor Pages 의 기능을 사용하여 backend 구성 요소를 작성하기위한 C# .NET Core 기능을 처음부터 작성했습니다. 상호 작용 모델로서, 나는 MVC 선택했습니다. 출구에서 우리는 Client-Server MVC Wep App 다루고 있습니다.
무단 사용자가 애플리케이션을 시작하자마자 그는 즉시 서비스에 대한 정보가 포함 된 기본 화면을 보게됩니다. 이 페이지에는 서비스의 모든 기능을 사용하여 새로운 사용자와 익숙해지는 데 필요한 모든 정보가 포함되어 있습니다. 맨 위에는 navbar 요소를 볼 수 있습니다. NAVBAR 요소는 모든 페이지에서 항상 시간이 지났으며 부록에서 사용자 탐색을 수행하도록 설계된 Vision 필드에서 사라지지 않습니다. Navbar 다음과 같은 기회를 제공합니다.
또한 페이지에는 Google의 맵이 있습니다.이 카드는 카탈로그에서 임대 된 차량이 아닌 모든 사용 가능한 위치를 보여줍니다 (마커는 차량의 현재 위치를 추적 할 수있는 맵에 나타납니다. 마커에 위탁되면 이름이있는 차량의 이미지가 나타납니다). 제한적으로, 나는 민스크시를 선택했습니다. 즉,지도는 도시의 전체 지역을 커버하는 방식으로 위치하고 있습니다. 예를 들어, 차가 브레스트의 거리 어딘가에있을 경우, 우리는지도에서 그것을 보지 못할 것입니다 (또는 카드 규모를 변경해야합니다). 자동차 배치를위한 이용 가능한 장소로서, 나는 벨로루시로 제한하기로 결정했습니다. 즉, 공인 사용자가 배치 한 차는 벨로루시 공화국에 있어야합니다. 그러나 사용자가 다른 도시 나 국가에서 자동차 주문을 만들지 못하게하는 것은 없습니다.
카드 자체와 관련하여 유명한 위도와 경도에 따라 위치를 찾는 데 제한이없는 특수 키를 사용하여 응용 프로그램에 연결되었습니다.
페이지에 관계없이 바로 맨 아래에는 응용 프로그램의 개발자에 대한 정보와 해당 소셜에 대한 링크가 있습니다. SAM 솔루션 네트워크 및 리소스.
카탈로그가있는 페이지에서 사용자는 자동차에 대한 모든 저렴한 간단한 정보를보고 카탈로그에 제공된 자동차 중 기준을 검색 할 수있는 기회가 제공됩니다. 페이지에는 기회가 있습니다.
자동차에 대한 정보와 관련하여 카탈로그가 제공됩니다.
이 페이지는 또한 차량에 대한 포인트 검색을 구현하는 데 필요한 양식을 유발할 수 있습니다. 여기에서 많은 다른 필터가 사용자에게 제공되며 카탈로그에서 관심있는 자동차를 찾을 수 있습니다.
따라서 카탈로그를 사용하면 제시된 차량의 구색을 고려하고 취향과 색상에 대한 사본을 선택할 수 있습니다.
사용자가 Log In 누르 자마자 즉시 인증 페이지로 리디렉션됩니다.
승인되지 않은 사용자 인 승인 페이지에서 성공적인 승인을 위해 이메일 (또는 로그인) 및 비밀번호를 입력해야합니다. 필드를 작성하는 오류가 있으면 작성할 때 오류 메시지가 표시됩니다.
모든 필드가 올바르게 채워졌지만 승인이 통과되지 않은 경우 사용자는 실패한 승인에 대한 메시지를 제시합니다.
성공적인 승인을 통해 이미 공인 된 사용자는 대시 보드 페이지 (개인 계정)로 리디렉션되며, 이에 따라 성공적인 승인에 대한 메시지가 표시되며, 이는 외관 후 자동으로 3 초가 사라집니다.
사용자가 자신의 계정이없는 경우 사용자는 자신의 계정을 만들어야합니다. 오른쪽 Navbar 요소의 Sign Up 버튼을 통해 수행되는 페이지로의 전환을 구현해야합니다.
새 사용자를 등록한 페이지에서 일련의 데이터를 입력하여 프로그램이 클라이언트를 데이터베이스에 입력하고 등록이 성공하도록해야합니다. 전체 페이지는 유효성 검사로 채워지고 무언가가 통과되지 않으면 사용자에게 오류가 발생한 필드 (허가의 허가와 동일한 원리)를 알리지 않습니다. 성공적인 등록 후 사용자는 등록 페이지로 리디렉션되어 성공적인 등록에 대한 메시지가 있습니다.
사용자가 새로 생성 된 계정을 성공적으로 입력하자마자 카탈로그의 자동차에 대한 더 자세한 정보를 볼 수있을뿐만 아니라 자신의 자동차를 추가 할 수있을뿐만 아니라 다른 사용자의 행동 및 행동에 대한 통계를 추적 할 수 있습니다.
이 페이지에서 사용자는 자동차에 대한 관련 정보를 제공하고 자동차를 임대 할 관세를 설정해야합니다. 페이지에는 유효성 검사가 있습니다 (권한 및 등록 페이지와 유사). 사용자가 자동차를 성공적으로 공유하자마자 즉시 자신의 계정에 나타나지만, 발행을 위해 관리자는 응용 프로그램을 승인해야하며, 그 후 사용자는 개인 계정을 통해 자동차를 게시하고 가능한 모든 방법 으로이 자동차와 상호 작용할 수 있습니다. (사용자는 그의 차를 추가했기 때문에 카탈로그에 동일한 사용자에게 카탈로그를 보여주는 것이 전적으로 논리적이지 않다는 것이 논리적입니다. 그러나 그들은 여전히 카탈로그에 표시되지만이 차에 대한 정보를 가지고 페이지에 가면 소유자는 임대 할 수는 없지만 다른 사용자에 대한 설명과 대표를 알 수 있습니다).
공인 사용자에게 대시 보드 페이지에서 계정 통계를 건조시킬 것을 간청 할 것을 제안합니다. 이 페이지에서 사용자는 다음과 같은 정보를 볼 수 있습니다.
대시 보드 페이지에서 사용자는 자동차에 대한 정보 편집 또는 계정 정보 편집 페이지에서 페이지를 방문 할 수 있습니다.
헤드 페이지를 통해 사용자는 자신의 계정과 관련된 일부 필드 (예 : 이름, 성, 별명, 메일 등)를 변경할 수 있습니다.
헤드 메뉴에는 왼쪽에 몇 개의 버튼이 있으며, 그 중 2 개를 눌러 미니 와인드가 있는데, 이는 계정의 일부 정보를 변경하는 역할을합니다.
헤드 페이지의 해당 버튼을 클릭 할 때 사용자는 프로필을 나타내는 아바타 중 하나를 선택하도록 초대됩니다. 사용자가 아바타 중 하나를 선택하자마자 Apply 및 Save changes 버튼을 클릭하면 아바타가 업데이트되고 사용자는 계정에서 다른 이미지를 관찰 할 수 있습니다.
다음 버튼을 누르면 사용자는 계정에서 새 비밀번호를 입력 할 수있는 기회를 갖게되며 계정의 비밀번호가 완전히 업데이트되고 계정을 다시 입력 할 때 이전 비밀번호가 유효하지 않습니다.
사용자가 계정에 새 차를 추가하면 관리자가 성공적으로 확인하면 사용자는 자신의 자동차를 게시하거나 (다른 사용자에게 임대 할 수있는 매운자가 될 것입니다) 숨길 수 있습니다. 자동차가 숨겨져있는 경우 해당 메뉴를 클릭하면 사용자가 해당 Modify 버튼을 클릭 한 다음 자동차에 대한 정보 편집으로 페이지로 이동할 수 있습니다.
이 페이지에서 그는 자동차에 대한 전반적인 정보를 변경할 수있을 것입니다 (그러나 그는 관리자가 자동차를 확인한 후에 다른 사용자가 카탈로그에서 잘못되고 보편적 인 정보를 보았을 수있는 기회를 얻은 후에 자동차의 이미지와 카테고리를 변경할 수 없습니다).
TODO : 아래로가는 모든 것을 변경하십시오.
공인 사용자가 카탈로그에서 차량의 Information 버튼을 누르 자마자 선택한 자동차와 해당 페이지를 엽니 다. 이 페이지에서 곧 사용자의 개인 계정에 기록 될 주문을 할 수 있습니다.
권한 부여 후 사용자의 개인 계정으로의 전환 버튼을 추가하여 사용자가 주문과 자동차를 추가 할 수 있습니다 (지금까지 버튼 만 Publish 및 Hide 자동차와 상호 작용할 수 있습니다).
이 페이지에서 사용자는 자신의 정보를보고 변경할뿐만 아니라 자동차와 주문을 제어 할 수 있습니다. 사용자 데이터 후에는 다음 카운터를 볼 수 있습니다.
또한이 페이지에서는 다음과 같은 정보를 볼 수 있습니다.
자동차 테이블로 작업 할 때 3 가지 색상을 관찰 할 수 있습니다.
자동차의 상태와 색상에 따라 새로운/기존 기능이 사용자에게 열려/차단됩니다.
위에서 언급했듯이 공인 사용자의 시스템의 경우 개인 계정을 입력하고 주문과 관련된 모든 정보 와이 사용자가 서비스의 다른 사용자에게 제공 한 자동차를 추적 할 수 있습니다. 그러나 일부 정보가 입력되지 않으면 사용자의 데이터가 변경되면 ... 또는 자동차를 게시 한 사용자가 다른 사람의 배경에 대해 어떻게 выделться 로 결정했을까요 ??? 이러한 문제를 해결하기 위해 현재 사용자와 그의 자동차에 대한 편집 정보가 포함 된 페이지를 개발했습니다.
개인 계정에서 자신에 대한 정보 편집으로 페이지로 이동하면 해당 Edit Profile 버튼을 클릭하여 사용자가 할 수 있습니다.
누르면 사용자는 페이지에 표시된 정보를 변경할 수있는 페이지를 엽니 다.
특히 : 프로필의 아바타 (제안 된 7 개의 이미지 중에서 선택할 수 있도록 (각 새 사용자에게 할당 된 1 개의 기본값, 선택할 수있는 6 명))
비밀번호를 변경할 수도 있습니다. 이전 비밀번호가 필요하지 않은 방식으로 새 비밀번호를 설정했습니다 (실제로 새 비밀번호를 설치하기 전에 실제 비밀번호를 요청해야합니다).
간단한 것부터 사용자는이 페이지의 필드를 변경할 수 있습니다 (예 : 프로필 설명, 전화 번호, 이메일 등). 모든 필드 사용자가 변경되면 해당 Save Changes 버튼을 클릭해야합니다 (새 비밀번호를 설치 한 상태에서 저장 버튼이 페이지에서 Save 버튼을 누르면 새 비밀번호가 자동으로 설치됩니다). 필드를 작성할 때 어떤 종류의 오류가 발생한 경우, 사용자는 Cancel Chnages 버튼을 클릭하여 페이지를 원래 양식 (이전 데이터로 Tobish)으로 되돌리거나 Get Back 버튼을 누르면 개인 계정으로 다시 전송할 수 있습니다.
실제로, 자동차와 관련하여 사용자는이 페이지 또는 페이지에 이전 정보를 변경할 수 있습니다.
그러나 변경에 사용 가능한 필드 수는 사용자의 수보다 몇 배 적습니다. 왜 그렇게? 사실은 개발할 때 아이디어가 나에게 일어났다는 것입니다. 모든 자동차는 주문 수로 모니터링됩니다. 그러나 사용자가 차를 완전히 바꿀 수 있다면 이미지와 이름을 변경할 수 있다면 어떨까요? 이 차의 등급은 동일하게 유지되지만 자세한 설명은 완전히 변경되었을 것입니다. 나에 관해서는, 그러한 접근 방식은 다른 사용자를 선택하는 데 중요한 역할을 할 수 있습니다. 따라서 정보는 편집에서 숨겨져야하며 가장 필요한 필드 만 사용할 수 있다고 결론을 내 렸습니다. 관세, 설명 및 위치가있는 필드.
공인 사용자의 Dubo는 카탈로그에서 다른 사용자의 자동차에 대한 자세한 정보를 볼 수 있습니다. 각 자동차의 페이지에서 사용자는이 차량 사용 순서를 사용하여 페이지로 이동할 수 있습니다.
이 페이지에서 그는 자동차를 사용할 수있는 기간을 선택하도록 초대되었습니다.
시간 간격의 선택은 daterangepicker 요소를 사용하여 수행됩니다. 설치 한 시작 시간 : 다음 시간으로 반올림합니다. 종료 시간 (기본값)은 시작 시간 + 1 시간입니다. 따라서 자동차를 사용하는 최소 시간은 1 시간입니다. 내가 설정 한 Macismal Time은 처음부터 7 일입니다. 지불 금액의 계산은 공식에 따라 발생합니다 : 관세/일 + 관세/시간의 수를 곱한 일의 수에 따라 발생합니다. 사용자가 필요한 모든 준비를하고 주문을 확인하자마자 지불 페이지로 리디렉션됩니다.
결제 페이지에서 주문을 다시로드하기 위해 사용자에게 필요한 모든 정보가 제공됩니다. 지불이 이루어 지 자마자 사용자는 개인 계정에서 자동차를 찾을 수 있습니다. 자동차를 소유 한 사용자는 자동차를 임대했음을 알 수 있으며 자동차를 임대 한 사용자는 유료 시간에 대한 모든 정보 와이 차에 대한 임대 계약의 나머지 시간과 시간에 대한 모든 정보를 볼 수 있습니다. 다음과 같이 보입니다.
사용자가 일정보다 앞서 주문을 완료하기로 결정하면 (주문은 만료 된 주문에 대한 시스템으로 끝나지 않고 주문을 한 사용자)가 NS 시간 동안 사용했던 자동차 등급을 설정할 수있는 기회가 있습니다.
다시, 사용자는 선택할 수 있습니다. 차량의 등급을 넣은 다음 해당 Submit and Finish 버튼을 누르고 등급으로 주문을 완료하거나 마감을 클릭 Finish and not submit 으로 단계를 건너 뛰고 등급을 보내지 않고 주문을 완료하십시오.
등급 자체는 자동차에 대한 정보가있는 페이지에서 볼 수 있습니다. 사용자가 설정 한 평가에 따라 일반 통계가 페이지에 표시됩니다. 별이 0 개있는 자동차는 위에서 볼 수 있고, 한 사용자의 풋 등급이있는 자동차가있는 페이지는 다음과 같습니다.
이 섹션에서는 프로젝트가 내부에서 어떻게 정렬되는지, "블랙 박스"내부에서 일어나는 일을 설명하려고 노력할 것입니다. 이것은 C# 프로그래밍 언어에 대한 약간의 아이디어와 그에 대한 프로그래밍 측면에 대한 약간의 아이디어를 가진 사람들의 프로젝트를 더 잘 이해하는 데 도움이 될 것입니다.
물론, 모든 데이터를 사용하려면 스타터를 위해 데이터를 결정해야하지만 저장하는 방법은 무엇입니까? 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-файла). Таким образом, применённый мной подход не только позволит пользователю получать доступ в кратчайшие сроки, но и позволит избежать излишних нагрузок системы для загрузки данных из файлов каждый раз при обращении к сервису.
При проектировнии, мной была выявлена следующая проблема - А должен ли пользователь, добавивший автомобиль в каталог, иметь возможность взаимодействовать с тем же самым автомобилем из каталога? Конечно же нет. Такой подход позволит пользователю, добавившему автомобиль в каталог, арендовать свой же автомобиль (В чём смысл???). Для избежания этой проблемы, мной был выбран следующий подход:
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. 하지만! The car does not appear in the catalog. What is the problem? 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. 하지만! 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). 하지만! 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 )
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
