Car sharing center
1.0.0
Gagasan utama Proses: Untuk mengembangkan layanan aplikasi layanan berbagi mobil dengan menampilkan mobil yang tersedia di peta. Dalam konten - segala sesuatu yang dapat dibandingkan dengan esensi Vehicles : mobil, sepeda motor, kendaraan apa pun, dll. Aplikasi harus multifungsi: perlu memiliki sejumlah besar halaman dengan kemampuan untuk menerima, menambah, mengubah, dan menghapus entitas.
pager -a ke halaman.httpContextAccessor .UserStatusProvider . Menambahkan pesan JS menggunakan layanan SweetAlert2 .ReadMe .Stripe ke proyek. Menambahkan fungsionalitas pemilihan waktu dan tanggal ke halaman dengan penempatan pesanan.JS (dihancurkan oleh file).Brief Description yang disebut akun yang menempatkan mobil pengguna. Dia mulai membuat bagian dengan peringkat untuk mobil..NET 7 . Kerjakan mesin pencari halaman katalog.RepositoryProvider dan mengurangi semua fungsionalitas untuk itu.JWToken Authentication ke pengontrol aplikasi Web .JWToken dan mengatur tampilan halaman kesalahan di sisi klien.JSON ke penyimpanan di MongoDB Local .MongoDB Atlas untuk bekerja lebih lanjut dengan layanan cloud.UI . Mengubah penanda Google Maps API dari merah ke mobil dengan nama dan gambar.Awal resmi magang
Web ke Clean Architecture yang dipenuhi penuh.Domain Layer dan menyiapkan model pertama. Model dibuat dengan gaya Rich Domain Models . Anemic Domain Models .Application dan Infrastructure Layers , serta menyiapkan interaksi pertama dengan layanan dan pengaturan DI .PublicAPI .endpoints pertama dan pengujian manual mereka.Errors Handling dan pemrosesannya.Errors Handling ke bagian dari model Vehicle .endpoints .Azure Key Vault untuk mendapatkan data rahasia dengan Azure . Implementasi bendera menggigit sebagai salah satu opsi untuk menyimpan informasi tentang mobil.endpoints baru ke CustomerController dan pengujian manual mereka.endpoints baru ke VehicleController dan pengujian manual mereka.IHttpClientFactory untuk membuat pelanggan untuk mengirim permintaan ke PublicAPI . Konfigurasi Polly untuk pesan pengiriman non -metnamik dengan kemungkinan menunggu dan memasukkannya kembali jika terjadi situasi kritis.PublicApi bersama dengan bagian Web dan memeriksa titik akhir dan serialisasi dan deserisasi antar -program.JWToken yang diterima dari server di sisi klien dengan pintu masuk yang sukses ke akun.UI pendaftaran, otorisasi dan menambahkan mobil baru.errors handling pada bagian klien saat menambahkan mobil baru.html dan beberapa endpoints .Bootstrap 5+ yang lebih baru dan menghapus logika halaman pendaftaran dan otorisasi.GoogleMaps Api dan koreksi kesalahan.Appsettings.json . Pengaturan dan interaksi pertama dengan Duende Identity Server .Identity Server dan membersihkan proyek dari file yang tidak perlu.Duende Identity Server ke Web Application (Bagian Klien).Duende Identity Server ke penggunaan JWT-Authorization dan membuat halaman Dashboard (akun pribadi pengguna).Duende Identity Server untuk bekerja dengan MongoDB Entities .Duende Identity Server . Mengatur AzureAD sebagai salah satu cara otorisasi. Menambahkan entitas baru ke MSSQL Server .Identity Server .JwtBearer . Mengatur AzureAD . Koneksi Azure Blob Storage sebagai salah satu mekanisme untuk menyimpan gambar mobil.Pipeline yang diatur antara aplikasi server dan kedua database. Tambahkan ActionNotes Repository sebagai salah satu layanan ke aplikasi.Dashboard . Memperbarui struktur database, di mana kolom baru ditambahkan. Pipeline dikonfigurasi untuk menerima data untuk mengirimkan informasi tentang akun klien.Dashboard .Dashboard . Fungsi ajax ditambahkan untuk mengunduh halaman tanpa pembaruan. Menambahkan fungsi pencarian berdasarkan kriteria.pipeline untuk menampilkan data pada mobil di katalog.GoogleMaps Api .Stripe .VehicleInformation .Azure VM . Menetapkan Seq dan Hosting Layanan Pengecualian di Azurevm. Menyiapkan akses aplikasi angkatan laut ke database MSSQL Anda.GitHub Actions dan Publish otomatis di Merge dengan Main branch .Http ke Https dan menambahkan fungsi baru.Rental dan Payment baru dan suasana hati Azure VM .Stripe Payment Service di sisi server.Stripe . Kerjakan penciptaan Stripe Checkout Sessions .Requests dan Responses server saat memanipulasi pesanan pada klien.Runtime dan mendapatkan formulir saat mengubah status pesanan.DateTime , permintaan dalam database dan bekerja pada fungsionalitas aplikasi.Routing-ом dan mengatur tampilan halaman dengan informasi kesalahan..tagets Taget untuk menyelesaikan masalah versi paket yang sama dalam proyek yang berbeda.Endpoints untuk mengedit data mobil.pipeline antara semua pengontrol klien dan server setelah menambahkan atribut ke parameter pengontrol.server response di sisi klien dan menyiapkan handler universal dari responses ini.DateTime.Now (waktu setempat) ke objek DateTime.UtcNow (waktu UTC).Routing pada bagian server dalam gaya REST .pipeline untuk mengedit informasi. Proyek ini adalah aplikasi Web penuh yang bekerja pada tingkat yang sama dengan PublicAPI , ditulis dengan gaya Clean Architecture , yang memungkinkan siapa pun yang memiliki kartu sewa yang valid dan SIM untuk mendapatkan mobil pengguna lain untuk sementara waktu, yang juga terdaftar, tetapi tidak dengan tujuan menyewa mobil orang lain, tetapi untuk menyediakan mobil mereka untuk mobil mereka menggunakan pengguna lain. Dengan demikian, keuntungan dapat diperoleh baik oleh pengembang aplikasi, menerima persentase transaksi yang dilakukan oleh pengguna, dan secara langsung pengguna sendiri menyewa atau menyewakan mobil mereka.
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 dan MongoDB )GitHub Actions dan Action Runners )Azure VM )dan lainnya ...
Seluruh proyek ditulis dari awal, menggunakan bootstrap 5+ untuk menghiasi komponen visual, serta menggunakan fungsionalitas Razor Pages , well, C# .NET Core untuk menulis komponen backend . Sebagai model interaksi, saya membuat pilihan menuju MVC . Di pintu keluar kami berurusan dengan Client-Server MVC Wep App .
Segera setelah pengguna yang tidak berwenang meluncurkan aplikasi, ia segera melihat layar utama dengan informasi tentang layanan tersebut. Halaman ini berisi semua informasi yang diperlukan untuk membiasakan diri dengan pengguna baru dengan semua kemampuan layanan. Di atas Anda dapat melihat elemen navbar , yang setiap saat di salah satu halaman dan tidak menghilang dari bidang penglihatan yang dirancang untuk melaksanakan navigasi pengguna di Lampiran. Navbar memberikan peluang berikut:
Juga, pada halaman ada peta dari Google, yang menunjukkan lokasi semua yang tersedia, tidak ada mobil yang disewa dari katalog (penanda muncul di peta, yang menurutnya lokasi kendaraan saat ini dapat dilacak. Ketika dipercayakan ke penanda, gambar kendaraan dengan namanya akan muncul). Sebagai pembatasan, saya memilih kota Minsk, yaitu, peta terletak sedemikian rupa untuk menutupi seluruh area kota. Jika mobil, katakanlah, akan berada di suatu tempat di jalanan Brest, maka kita tidak akan melihatnya di peta (atau akan diperlukan untuk mengubah skala kartu). Sebagai lokasi yang tersedia untuk menempatkan mobil, saya memutuskan untuk membatasi diri pada Belarus, yaitu mobil yang ditempatkan oleh pengguna yang berwenang harus berada di Republik Belarus. Namun, tidak ada yang mencegah pengguna dari membuat pesanan untuk mobil di kota lain atau bahkan negara.
Mengenai kartu itu sendiri, itu terhubung ke aplikasi menggunakan kunci khusus, yang berfungsi tanpa batasan untuk menemukan lokasi sesuai dengan garis lintang dan bujur yang terkenal.
Terlepas dari halaman, di bagian paling bawah, akan ada informasi tentang pengembang aplikasi dan tautan ke sosial yang sesuai. Jaringan dan Sumber Daya Solusi SAM.
Pada halaman dengan katalog, pengguna akan diberi kesempatan untuk melihat semua informasi singkat yang terjangkau tentang mobil, serta mencari kriteria di antara mobil yang diberikan dalam katalog. Di halaman ada peluang:
Mengenai informasi tentang mobil, katalog disajikan:
Halaman ini juga memiliki kesempatan untuk menyebabkan formulir yang diperlukan untuk implementasi titik pencarian kendaraan. Di sini, banyak filter berbeda diberikan kepada pengguna, yang dengannya ia dapat menemukan mobil yang menarik baginya dalam katalog.
Dengan demikian, katalog memungkinkan Anda untuk mempertimbangkan bermacam -macam kendaraan yang disajikan dan memilih salinan apa pun untuk selera dan warna Anda.
Segera setelah pengguna menekan Log In , ia segera mengarahkan kembali ke halaman otorisasi.
Di halaman otorisasi, pengguna yang tidak sah, Anda harus memasukkan email (atau login) dan kata sandi Anda untuk otorisasi yang berhasil. Ketika kesalahan dalam mengisi bidang, pesan kesalahan akan ditampilkan saat mengisi:
Jika semua bidang diisi dengan benar, tetapi otorisasi belum berlalu, pengguna akan menyajikan pesan tentang otorisasi yang tidak berhasil:
Dengan otorisasi yang berhasil, pengguna yang sudah berwenang akan diarahkan ke halaman dasbor (akun pribadi), di mana akan ada pesan tentang otorisasi yang sukses, yang secara otomatis menghilang 3 detik setelah penampilannya.
Jika pengguna tidak memiliki akunnya sendiri, pengguna perlu membuat akunnya sendiri, transisi ke halaman untuk mengimplementasikan yang dilakukan melalui menekan tombol Sign Up pada elemen navbar kanan.
Pada halaman dengan pendaftaran pengguna baru, akan diperlukan untuk memasukkan serangkaian data sehingga program memasukkan klien ke dalam database dan pendaftaran berhasil. Seluruh halaman diisi dengan validasi, dan jika sesuatu tidak lewat, pengguna tidak akan diberitahu tentang bidang di mana kesalahan terjadi (prinsip yang sama seperti dengan shaggy otorisasi). Setelah pendaftaran yang berhasil, pengguna akan diarahkan ke halaman pendaftaran di mana akan ada pesan tentang pendaftaran yang berhasil.
Segera setelah pengguna berhasil memasuki akunnya yang baru dibuat, ia akan mendapatkan kesempatan tidak hanya untuk melihat informasi yang lebih rinci tentang mobil dalam katalog, tetapi juga untuk menambahkan mobilnya sendiri, serta melacak statistik tentang tindakan dan tindakan mereka oleh pengguna lain dengan mobilnya.
Pada halaman ini, pengguna harus memberikan informasi yang relevan tentang mobilnya, serta menetapkan tarif di mana mobil akan disewa. Halaman ini juga memiliki validasi (mirip dengan halaman otorisasi dan pendaftaran). Segera setelah pengguna berhasil membagikan mobilnya, ia akan segera muncul di akunnya, untuk publikasi, administrator harus menyetujui aplikasi, setelah itu pengguna akan dapat mempublikasikan mobil melalui akun pribadinya, serta mengedit informasi dan berinteraksi dengan mobil ini dengan segala cara yang memungkinkan. ;
Di halaman dasbor ke pengguna yang berwenang, diusulkan untuk memohon untuk mengeringkan statistik akunnya. Di halaman ini, pengguna dapat melihat informasi seperti:
Dari halaman dasbor, pengguna memiliki kesempatan untuk sampai ke halaman dengan mengedit informasi tentang mobil, atau di halaman pengeditan informasi akun.
Halaman kepala memungkinkan pengguna untuk mengubah beberapa bidang yang terkait dengan akunnya (seperti nama, nama keluarga, nama panggilan, surat, dll.)
Menu kepala memiliki beberapa tombol di sebelah kiri, setelah menekan 2 di antaranya ada angin mini, yang juga berfungsi untuk mengubah beberapa informasi akun.
Saat mengklik tombol yang sesuai di halaman kepala, pengguna diundang untuk memilih salah satu avatar yang akan mewakili profilnya. Segera setelah pengguna memilih salah satu avatar, setelah itu ia akan mengklik tombol Apply dan Save changes , avatar akan diperbarui dan pengguna akan dapat mengamati gambar lain di akunnya.
Ketika tombol berikutnya ditekan, pengguna akan memiliki kesempatan untuk memasukkan kata sandi baru dari akunnya, setelah itu kata sandi dari akunnya akan sepenuhnya diperbarui dan kata sandi lama akan tidak valid ketika masuk kembali akun.
Setelah pengguna menambahkan mobil baru ke akun dan dia akan berhasil dikonfirmasi oleh administrator, pengguna akan dapat mempublikasikan mobilnya (dia akan menjadi orang yang menyewakan untuk pengguna lain), atau menyembunyikannya. Jika mobil disembunyikan, saat mengklik pada menu yang sesuai, pengguna akan dapat mengklik tombol Modify yang sesuai, dan kemudian pergi ke halaman dengan mengedit informasi tentang mobil.
Pada halaman ini, ia akan dapat mengubah informasi keseluruhan tentang mobil (namun, ia tidak akan dapat mengubah citra mobil dan kategorinya untuk tujuan bahwa jika ia memiliki peluang seperti itu, setelah mengkonfirmasi mobil oleh administrator, ia dapat memuat gambar apa pun, setelah itu pengguna lain akan melihat informasi yang salah dan universal dalam katalognya).
TODO: Ubah semua yang terjadi di bawah.
Segera setelah pengguna yang berwenang menekan tombol Information pada kendaraan dari katalog, ia membuka halaman yang sesuai dengan mobil yang dipilih dan informasi lebih rinci tentang salinannya. Dari halaman ini, segera, akan dimungkinkan untuk membuat pesanan yang akan dicatat di akun pribadi pengguna.
Saya menambahkan tombol untuk transisi ke akun pribadi pengguna setelah otorisasi, yang memungkinkan pengguna untuk melacak pesanan mereka dan mobil yang ditambahkan olehnya (sejauh ini hanya Publish dan Hide tombol aktif untuk berinteraksi dengan mobil).
Pada halaman ini, pengguna akan dapat tidak hanya melihat dan mengubah informasinya, tetapi juga untuk mengendalikan mobil dan perintahnya. Setelah data pengguna, Anda dapat melihat penghitung berikut:
Juga, di halaman ini Anda dapat melihat informasi seperti:
Saat bekerja dengan meja mobil, Anda dapat mengamati 3 warna:
Tergantung pada status dan warna mobil, fungsi baru/lama terbuka/diblokir untuk pengguna
Seperti disebutkan di atas, untuk sistem pengguna yang berwenang, menjadi mungkin untuk memasukkan akun pribadinya dan melacak semua informasi yang terkait dengan pesanannya, serta mobil yang disediakan pengguna ini untuk pengguna lain dari layanan kami. Tetapi bagaimana jika beberapa informasi tidak dimasukkan, jika data pengguna telah berubah ... atau mungkin pengguna yang menerbitkan mobil memutuskan untuk entah bagaimana выделться dengan latar belakang orang lain ??? Untuk menyelesaikan masalah ini, saya mengembangkan halaman dengan mengedit informasi tentang pengguna saat ini dan tentang mobilnya:
Dari akun pribadi Anda, buka halaman dengan mengedit informasi tentang diri Anda, pengguna dapat dengan mengklik tombol Edit Profile yang sesuai
Saat menekan, pengguna membuka halaman di mana ia dapat mengubah informasi apa pun yang ditampilkan di halaman
Secara khusus: Avatar profilnya (untuk memilih dari 7 gambar dari yang diusulkan (1 default, yang ditugaskan untuk setiap pengguna baru, dan 6 lainnya untuk dipilih)))
Anda juga dapat mengubah kata sandi Anda. Saya membuat pembentukan kata sandi baru sedemikian rupa sehingga yang sebelumnya tidak diperlukan (pada kenyataannya, perlu meminta kata sandi nyata sebelum menginstal yang baru)
Dari yang sederhana, pengguna dapat mengubah salah satu bidang di halaman ini (misalnya, deskripsi profil, nomor teleponnya, email, dll.). Setelah semua pengguna diubah, Anda harus mengklik tombol Save Changes yang sesuai (kata sandi baru diinstal secara otomatis ketika tombol Save ditekan pada halaman dengan instalasi kata sandi baru). Jika beberapa jenis kesalahan dibuat saat mengisi bidang, pengguna dapat mengklik tombol Cancel Chnages , yang akan mengembalikan halaman ke formulir aslinya (tobish ke data lama), atau tekan tombol Get Back , yang akan mentransfernya kembali ke akun pribadinya.
Sebenarnya, mengenai mobil, pengguna juga dapat mengubah informasi ini atau yang sebelumnya ada di halaman:
Namun, jumlah bidang yang tersedia untuk perubahan beberapa kali lebih sedikit dari pengguna. Kenapa begitu? Faktanya adalah bahwa ketika berkembang, idenya terpikir oleh saya: setiap mobil dipantau dengan jumlah pesanan. Tetapi bagaimana jika pengguna dapat mengganti mobil sepenuhnya, katakan, ganti gambar dan namanya? Peringkat mobil ini akan tetap sama, tetapi deskripsi terperinci akan berubah sepenuhnya. Sedangkan bagi saya, pendekatan semacam itu dapat memainkan peran kunci dalam menentukan pengguna lain, mobil yang harus dipilih: misalnya, pengguna yang menempatkan mobilnya setahun yang lalu jelas akan kalah dari pengguna yang akan mengubah deskripsi mobil lamanya menjadi deskripsi yang lebih baru. Jadi, saya menyimpulkan bahwa informasi perlu disembunyikan dari pengeditan, dan hanya bidang yang paling penting yang tersedia: bidang dengan tarif, deskripsi, serta lokasi.
Dubo dari pengguna yang berwenang dapat melihat informasi terperinci tentang mobil pengguna lain di katalog. Dari halaman setiap mobil, pengguna dapat pergi ke halaman dengan penempatan pesanan untuk menggunakan mobil ini:
Pada halaman ini, ia diundang untuk memilih periode waktu di mana ia dapat menggunakan mobil.
Pemilihan interval waktu dilakukan dengan menggunakan elemen daterangepicker , di mana saya menginstal: Waktu mulai - membulatkan ke jam berikutnya. Waktu akhir (default) adalah waktu mulai + 1 jam. Dengan demikian, waktu minimum untuk menggunakan mobil adalah 1 jam. Waktu Macismal yang telah saya tetapkan adalah 7 hari sejak awal. Perhitungan jumlah untuk pembayaran terjadi sesuai dengan rumus: jumlah hari dikalikan dengan tarif/hari + jumlah jam * tarif/jam. Segera setelah pengguna membuat semua persiapan yang diperlukan dan mengkonfirmasi pesanan - ia akan diarahkan ke halaman pembayaran:
Pada halaman pembayaran, semua informasi yang diperlukan untuk pengguna diberikan untuk menggambar ulang pesanannya lagi. Segera setelah pembayaran dilakukan, pengguna akan dapat menemukan mobil di akun pribadi mereka: pengguna yang memiliki mobil akan melihat bahwa mobil disewa, dan pengguna, yang menyewa mobil, akan melihat informasi lengkap tentang waktu yang dibayar serta semua informasi mengenai waktu dan waktu yang tersisa dari akhir sewa untuk mobil ini. Kelihatannya sebagai berikut:
Ketika pengguna memutuskan untuk menyelesaikan pesanannya lebih cepat dari jadwal (pesanan tidak berakhir dengan sistem yang bertanggung jawab atas pesanan yang sudah kadaluwarsa, tetapi pengguna yang telah membuat pesanan), ia memiliki kesempatan untuk mengatur peringkat mobil yang ia gunakan selama waktu ke -7:
Sekali lagi, pengguna memiliki pilihan: Letakkan peringkat mobil, dan kemudian tekan tombol Submit and Finish yang sesuai dan selesaikan pesanan dengan peringkat, atau lewati langkah dengan peringkat dengan mengklik Finish and not submit tombol, dan lengkapi pesanan tanpa mengirim peringkat.
Peringkat itu sendiri dapat dilihat di halaman dengan informasi tentang mobil. Bergantung pada penilaian yang ditetapkan oleh pengguna, statistik umum akan ditampilkan pada halaman. Mobil dengan 0 bintang dapat dilihat di atas, dan halaman dengan mobil dengan peringkat put -rated dari satu pengguna ditampilkan di bawah ini:
Di bagian ini, saya akan mencoba menjelaskan, tetapi bagaimana proyek diatur dari dalam, apa yang terjadi di dalam "kotak hitam". Ini akan membantu untuk lebih memahami proyek bagi mereka yang memiliki setidaknya sedikit gagasan tentang bahasa pemrograman C# dan aspek pemrograman di dalamnya.
Tentu saja, untuk bekerja dengan data apa pun, sebagai permulaan, Anda perlu memutuskan, tetapi bagaimana cara menyimpannya? 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? Tentu saja tidak. 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. TETAPI! The car does not appear in the catalog. Apa masalahnya? 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. NAMUN! 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). TETAPI! 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 )
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
