Car sharing center
1.0.0
الفكرة الرئيسية للمتابعة: لتطوير خدمة تطبيق لخدمة مشاركة السيارات مع عرض السيارات المتاحة على الخريطة. في المحتوى - كل ما يمكن مقارنته بجوهر Vehicles : السيارات ، الدراجات النارية ، أي مركبات ، إلخ.
pager -a إلى الصفحة.httpContextAccessor .UserStatusProvider . إضافة رسائل JS باستخدام خدمة SweetAlert2 .ReadMe .Stripe للمشروع. إضافة وظيفة اختيار الوقت والتاريخ إلى الصفحة مع وضع الطلب.JS (تحطيمه الملفات).Brief Description للحساب الذي وضع سيارة المستخدم. بدأ في القيام بدور مع تصنيف السيارات..NET 7 . العمل على محرك البحث في صفحة الكتالوج.RepositoryProvider واحد وخفض جميع الوظائف من أجل ذلك.JWToken Authentication إلى وحدات تحكم التطبيق Web .JWToken وإعداد عرض الصفحة لخطأ على جانب العميل.JSON إلى التخزين في MongoDB Local .MongoDB Atlas من أجل مزيد من العمل مع الخدمة السحابية.UI . تغيير علامة Google Maps API من الأحمر إلى السيارة مع الاسم والصورة.البداية الرسمية للتدريب
Web واحد إلى Clean Architecture الكاملة.Domain Layer وإعداد النماذج الأولى. يتم إنشاء النماذج في نمط Rich Domain Models . Anemic Domain Models .Infrastructure Layers Application والبنية التحتية ، وكذلك إعداد التفاعلات الأولى مع الخدمة وإعداد DI .PublicAPI .endpoints الأولى واختبارها اليدوي.Errors Handling ومعالجتها.Errors Handling مع جزء من طراز Vehicle .endpoints .Azure Key Vault للحصول على بيانات سرية مع Azure . تنفيذ أعلام العض كأحد خيارات تخزين المعلومات حول السيارات.endpoints جديدة إلى CustomerController واختبارها اليدوي.endpoints جديدة إلى VehicleController واختبارها اليدوي.IHttpClientFactory لإنشاء عملاء لإرسال Requets إلى PublicAPI . تكوين Polly لرسائل إرسال غير ديناميكية مع إمكانية الانتظار وإعادة إنفاقها في حالة وجود مواقف حرجة.PublicApi جنبا إلى جنب مع جزء Web والتحقق من نقاط النهاية والتسلسل بين البرمجة والخروج.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 لاستخدام JWT-Authorization وإنشاء صفحة Dashboard (حساب المستخدم الشخصي).Duende Identity Server للعمل مع MongoDB Entities .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 .VehicleInformation .Azure VM . تعيين خدمة الاستثناءات Seq واستضافة على Azurevm. إعداد وصول التطبيق البحري إلى قاعدة بيانات MSSQL الخاصة بك.GitHub Actions Publish التلقائي في Merge مع Main branch .Http إلى Https وإضافة وظائف جديدة.Rental Payment ومزاج Azure VM .Stripe Payment Service على جانب الخادم.Stripe . العمل على إنشاء Stripe Checkout Sessions .Requests الخادم Responses عند معالجة الطلبات على العميل.Runtime والحصول على نموذج عند تغيير حالة الطلب.DateTime ، والطلبات في قاعدة البيانات والعمل على وظيفة التطبيق.Routing-ом وإعداد الصفحات مع عرض معلومات الخطأ..tagets لحل مشكلة إصدار الحزم نفسها في مشاريع مختلفة.Endpoints لتحرير بيانات السيارة.pipeline بين جميع وحدات التحكم في العميل والخادم بعد إضافة سمات إلى معلمات وحدات التحكم.server response على جانب العميل وإعداد المعالج الشامل لهذه responses .DateTime.Now (بالتوقيت المحلي) إلى كائن DateTime.UtcNow (وقت UTC).Routing على جزء الخادم بأسلوب REST .pipeline لتحرير المعلومات. هذا المشروع هو تطبيق Web بالكامل يعمل على نفس المستوى مع PublicAPI ، مكتوب بأسلوب Clean Architecture ، والذي يتيح لأي شخص لديه بطاقة تأجير صالحة ورخصة قيادة للحصول على سيارة من مستخدم آخر لفترة من الوقت ، والتي تم تسجيلها أيضًا ، ولكن ليس الهدف من استئجار سيارة شخص آخر ، ولكن لتوفير سياراتهم لسياراتهم باستخدام مستخدمين آخرين. وبالتالي ، يمكن الحصول على الميزة من قبل مطوري التطبيق ، وتلقي نسبة مئوية من المعاملات التي يقوم بها المستخدمون ، والمستخدمين أنفسهم مباشرة يستأجرون سياراتهم أو تأجيرها.
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 and Action Runners )Azure VM )وآخرون ...
تمت كتابة المشروع بأكمله من نقطة الصفر ، باستخدام bootstrap 5+ لتزيين المكون المرئي ، وكذلك استخدام وظائف Razor Pages ، حسناً ، C# .NET Core لكتابة مكون backend . كنموذج للتفاعل ، قمت باختيار تجاه MVC . في المخرج ، نتعامل مع Client-Server MVC Wep App .
بمجرد تشغيل المستخدم غير المصرح به ، يرى على الفور الشاشة الرئيسية مع معلومات حول الخدمة. تحتوي هذه الصفحة على جميع المعلومات اللازمة للتعرف على المستخدم الجديد بجميع إمكانيات الخدمة. في الأعلى ، يمكنك رؤية عنصر navbar ، وهو طوال الوقت على أي من الصفحات ولا يختفي من حقل الرؤية المصمم لتنفيذ تسمية المستخدم في التذييل. يوفر Navbar الفرص التالية:
أيضًا ، على الصفحة ، توجد خريطة من Google ، والتي تعرض موقع جميع السيارات المتوفرة ، غير المستأجرة من الكتالوج (تظهر العلامات على الخريطة ، والتي يمكن بموجبها تتبع الموقع الحالي للمركبات. عند تكليفه بالعلامة ، ستظهر صورة للسيارة باسمها). كقيود ، اخترت مدينة مينسك ، أي أن الخريطة تقع بطريقة لتغطية منطقة المدينة بأكملها. إذا كانت السيارة ، على سبيل المثال ، ستكون في مكان ما في شوارع بريست ، فلن نراها على الخريطة (أو سيكون من الضروري تغيير مقياس البطاقة). كمواقع متوفرة لوضع السيارات ، قررت أن أقصر نفسي على بيلاروسيا ، أي أن السيارة التي يضعها مستخدم معتمد في جمهورية بيلاروسيا. ومع ذلك ، لا شيء يمنع المستخدم من إنشاء طلب لسيارة في مدينة أخرى أو حتى بلد.
فيما يتعلق بالبطاقة نفسها ، تم توصيله بالتطبيق باستخدام مفتاح خاص ، والذي يعمل دون أي قيود على العثور على موقع وفقًا لخط الطول الشهير.
بغض النظر عن الصفحة ، في الجزء السفلي ، ستكون هناك معلومات حول مطوري التطبيق والروابط إلى الاجتماعية المقابلة. شبكات Sam Solutions والموارد.
على الصفحة مع الكتالوج ، سيتم منح المستخدمين الفرصة لعرض جميع المعلومات الموجزة بأسعار معقولة حول السيارات ، وكذلك للبحث عن المعايير بين السيارات الواردة في الكتالوج. على الصفحة هناك فرصة:
فيما يتعلق بالمعلومات حول السيارات ، يتم تقديم الكتالوج:
تتاح للصفحة أيضًا الفرصة للتسبب في النموذج اللازم لتنفيذ البحث عن المركبات. هنا ، يتم توفير العديد من المرشحات المختلفة للمستخدم ، والتي يمكن أن يجد سيارات ذات أهمية له في الكتالوج.
وبالتالي ، يتيح لك الكتالوج النظر في مجموعة متنوعة من المركبات المقدمة واختيار أي نسخة حسب ذوقك ولونك.
بمجرد أن يضغط المستخدم على Log In ، يقوم على الفور بإعادة التوجيه إلى صفحة التفويض.
في صفحة التفويض ، وهو مستخدم غير مصرح به ، ستحتاج إلى إدخال بريدك الإلكتروني (أو تسجيل الدخول) وكلمة المرور للحصول على إذن ناجح. عندما يكون هناك خطأ في ملء الحقل ، سيتم عرض رسالة خطأ عند ملء:
إذا تم ملء جميع الحقول بشكل صحيح ، لكن التفويض لم يمر ، فسيقدم المستخدم رسالة حول التفويض غير الناجح:
من خلال الترخيص الناجح ، سيتم إعادة توجيه المستخدم المعتمد بالفعل إلى صفحة لوحة القيادة (الحساب الشخصي) ، والتي ستكون هناك رسالة حول التفويض الناجح ، والتي تختفي تلقائيًا بعد 3 ثوانٍ من مظهرها.
إذا لم يكن لدى المستخدم حسابه الخاص ، فيجب على المستخدم إنشاء حسابه الخاص ، والانتقال إلى الصفحة لتنفيذه والذي يتم تنفيذه من خلال الضغط على زر Sign Up على عنصر Navbar الأيمن.
في الصفحة مع تسجيل مستخدم جديد ، سيكون من الضروري إدخال سلسلة من البيانات بحيث يكون البرنامج إدخال العميل في قاعدة البيانات والتسجيل ناجحًا. تمتلئ الصفحة بأكملها بالتحقق من الصحة ، وإذا لم يمر شيء ما ، فلن يتم إخطار المستخدم بالحقل الذي حدث فيه الخطأ (نفس الشيء الذي حدث في التشجيع على الترخيص). بعد التسجيل الناجح ، سيتم إعادة توجيه المستخدم إلى صفحة التسجيل التي ستكون هناك رسالة حول التسجيل الناجح.
بمجرد أن يدخل المستخدم بنجاح حسابه الذي تم إنشاؤه حديثًا ، سيحصل على الفرصة ليس فقط لعرض معلومات أكثر تفصيلاً حول السيارات في الكتالوج ، ولكن أيضًا لإضافة سياراته الخاصة ، بالإضافة إلى إحصائيات تتبع أفعالهم وأفعالهم من قبل المستخدمين الآخرين مع سياراته.
في هذه الصفحة ، سيتعين على المستخدم تقديم معلومات ذات صلة حول سيارته ، وكذلك تعيين التعريفة التي سيتم استئجار السيارة فيها. تحتوي الصفحة أيضًا على التحقق من الصحة (على غرار صفحة التخويل والتسجيل). بمجرد أن يشارك المستخدم سيارته بنجاح ، سيظهر على الفور في حسابه ، ومع ذلك ، في نشره ، يجب على المسؤول الموافقة على التطبيق ، وبعد ذلك سيتمكن المستخدم من نشر السيارة من خلال حسابه الشخصي ، وكذلك تحرير المعلومات والتفاعل مع هذه السيارة بكل طريقة ممكنة. (منذ أن أضاف المستخدم سيارته ، من المنطقي أنه لن يكون منطقيًا وصحيحًا تمامًا لإظهارها في الكتالوج لنفس المستخدم. ومع ذلك ، فإنهم لا يزالون يظهرون في الكتالوج ، ولكن من خلال الذهاب إلى الصفحة مع معلومات حول هذه السيارة ، لن يكون المالك قادرًا على استئجارها ، لكنه سيتمكن من الحصول على للتحويل إلى وصفه وتمثيله لمستخدمين آخرين).
على صفحة لوحة القيادة إلى مستخدم معتمد ، يُقترح أن يجفف إحصائيات حسابه. في هذه الصفحة ، يمكن للمستخدم عرض هذه المعلومات مثل:
من صفحة لوحة القيادة ، تتاح للمستخدم الفرصة للوصول إلى الصفحات من خلال تحرير معلومات حول السيارة ، أو على صفحة معلومات حساب التحرير.
تتيح صفحة الرأس للمستخدم تغيير بعض الحقول المرتبطة بحسابه (مثل الاسم واللقب واللقب والبريد وما إلى ذلك)
تحتوي قائمة الرأس على عدة أزرار على اليسار ، بعد الضغط على 2 منها الرياح المصغرة ، والتي تعمل أيضًا على تغيير بعض المعلومات عن الحساب.
عند النقر على الزر المقابل في صفحة الرأس ، يتم دعوة المستخدم لاختيار إحدى الآلهة التي تمثل ملفه الشخصي. بمجرد أن يختار المستخدم أحد الصور الرمزية ، وبعد ذلك سوف ينقر على زر Apply Save changes ، سيتم تحديث الصورة الرمزية وسيتمكن المستخدم من مراقبة صورة أخرى في حسابه.
عند الضغط على الزر التالي ، ستتاح للمستخدم الفرصة لإدخال كلمة مرور جديدة من حسابه ، وبعد ذلك سيتم تحديث كلمة المرور من حسابه بالكامل وستكون كلمة المرور القديمة غير صالحة عند إعادة إدخال الحساب.
بعد أن يضيف المستخدم سيارة جديدة إلى الحساب وسيتم تأكيده بنجاح من قبل المسؤول ، سيتمكن المستخدم من نشر سيارته (سيصبح نفاذًا للإيجار للمستخدمين الآخرين) ، أو إخفاءها. إذا تم إخفاء السيارة ، عند النقر فوق القائمة المقابلة ، سيتمكن المستخدم من النقر على زر Modify المقابل ، ثم انتقل إلى الصفحة مع معلومات التحرير حول السيارة.
في هذه الصفحة ، سيكون قادرًا على تغيير المعلومات الإجمالية حول السيارة (ومع ذلك ، لن يكون قادرًا على تغيير صورة السيارة وفئتيه لغرض أنه إذا أتيحت له الفرصة ، بعد تأكيد السيارة من قبل المسؤول ، يمكنه تحميل أي صورة ، وبعد ذلك كان من المفترض أن يرى المستخدمون الآخرون معلومات غير صحيحة في كتالوجه).
TODO: تغيير كل ما يذهب أدناه.
بمجرد أن يضغط المستخدم المعتمد على زر Information على السيارة من الكتالوج ، يفتح الصفحة المقابلة مع السيارة المحددة ومعلومات أكثر تفصيلاً حول النسخة. من هذه الصفحة ، قريبًا ، سيكون من الممكن تقديم أوامر سيتم تسجيلها في الحساب الشخصي للمستخدم.
لقد أضفت زرًا للانتقال إلى حساب المستخدم الشخصي بعد التفويض ، والذي يسمح للمستخدم بتتبع أوامره والسيارات التي تمت إضافتها من قبله (حتى الآن Publish الأزرار Hide تنشط للتفاعل مع السيارات).
في هذه الصفحة ، سيتمكن المستخدم ليس فقط من عرض معلوماته وتغييرها ، ولكن أيضًا للتحكم في سياراته وأوامره. بعد بيانات المستخدم ، يمكنك رؤية العداد التالي:
أيضًا ، في هذه الصفحة ، يمكنك عرض معلومات مثل:
عند العمل مع طاولة سيارة ، يمكنك مراقبة 3 ألوان:
اعتمادًا على الحالة ولون السيارة ، تكون الوظائف الجديدة/القديمة مفتوحة/محظورة للمستخدم
كما ذكر أعلاه ، بالنسبة لنظام المستخدم المعتمد ، يصبح من الممكن إدخال حسابه الشخصي وتتبع جميع المعلومات المتعلقة بأوامره ، وكذلك السيارات التي قدمها هذا المستخدم للمستخدمين الآخرين لخدمتنا. ولكن ماذا لو لم يتم إدخال بعض المعلومات ، إذا تغيرت بيانات المستخدم ... أو ربما يكون المستخدم الذي نشر سيارة يقرر أن выделться بطريقة ما على خلفية الآخرين ؟؟؟ لحل هذه المشكلات ، قمت بتطوير صفحات مع تحرير معلومات حول المستخدم الحالي وعن سياراته:
من حسابك الشخصي ، انتقل إلى الصفحة مع تحرير معلومات عن نفسك ، يمكن للمستخدم بالنقر فوق زر Edit Profile المقابل
عند الضغط ، يفتح المستخدم صفحة يمكنه عليها تغيير أي معلومات يتم عرضها على الصفحة
على وجه الخصوص: الصورة الرمزية لملفه الشخصي (للاختيار من بين 7 صور من المقترح (1 افتراضي ، يتم تعيينه لكل مستخدم جديد ، و 6 آخرين للاختيار من بينها))
يمكنك أيضًا تغيير كلمة المرور الخاصة بك. لقد قمت بإنشاء كلمة مرور جديدة بطريقة لا تكون هناك حاجة إلى الكلام السابق (في الواقع ، سيكون من الضروري طلب كلمة مرور حقيقية قبل تثبيت كلمة جديدة)
من واحد بسيط ، يمكن للمستخدم تغيير أي من الحقول في هذه الصفحة (على سبيل المثال ، وصف الملف الشخصي ورقم هاتفه أو البريد الإلكتروني وما إلى ذلك). بعد تغيير جميع مستخدمي الحقل ، يجب عليك النقر فوق الزر Save Changes المقابل (يتم تثبيت كلمة المرور الجديدة تلقائيًا عند الضغط على زر Save على الصفحة مع تثبيت كلمة مرور جديدة). إذا تم إجراء نوع من الأخطاء عند ملء الحقول ، فيمكن للمستخدم النقر على زر Cancel Chnages ، والذي سيعيد الصفحة إلى نموذجه الأصلي (الخليج إلى البيانات القديمة) ، أو الضغط على زر Get Back ، الذي سيقوم بنقله إلى حسابه الشخصي.
في الواقع ، فيما يتعلق بالسيارات ، يمكن للمستخدم أيضًا تغيير هذا أو تلك المعلومات السابقة على الصفحة:
ومع ذلك ، فإن عدد الحقول المتاحة للتغيير أقل عدة مرات من عدد المستخدم. لماذا ذلك؟ والحقيقة هي أنه عند التطوير ، حدثت الفكرة لي: يتم مراقبة كل سيارة من خلال عدد الطلبات. ولكن ماذا لو استطاع المستخدم تغيير السيارة تمامًا ، على سبيل المثال ، تغيير صورته واسمه؟ سيبقى تصنيف هذه السيارة كما هو ، لكن الوصف المفصل كان سيتغير تمامًا. بالنسبة لي ، فإن مثل هذا النهج يمكن أن يلعب دورًا رئيسيًا في تحديد المستخدمين الآخرين ، والتي يختارونها: على سبيل المثال ، فإن المستخدم الذي وضع سيارته قبل عام سيخسر بوضوح للمستخدم الذي سيغير وصف سيارته القديمة إلى وصف أكثر جديدة. وهكذا ، خلصت إلى أن المعلومات تحتاج إلى إخفاءها من التحرير ، ولا تتوفر سوى الحقول الأكثر ضرورة: الحقول ذات التعريفة ، والوصف ، بالإضافة إلى موقع.
يمكن لـ DUBO من المستخدمين المعتمدين عرض معلومات مفصلة حول سيارات المستخدمين الآخرين في الكتالوج. من صفحة كل سيارة ، يمكن للمستخدم الانتقال إلى الصفحة مع وضع الطلب لاستخدام هذه السيارة:
في هذه الصفحة ، يتم دعوته لاختيار فترة زمنية يمكنه استخدامها للسيارة.
يتم اختيار الفاصل الزمني الزمني باستخدام عنصر daterangepicker ، الذي قمت بتثبيته: وقت البدء - يدور نحو الساعة التالية. وقت الانتهاء (الافتراضي) هو وقت البدء + ساعة واحدة. وبالتالي ، فإن الحد الأدنى للوقت لاستخدام السيارة هو ساعة واحدة. وقت Macismal الذي حددته هو 7 أيام منذ البداية. يحدث حساب المبلغ للدفع وفقًا للصيغة: عدد الأيام التي تضاعفها التعريفة/اليوم + عدد الساعات * التعريفة/الساعة. بمجرد قيام المستخدم بإجراء جميع الاستعدادات اللازمة ويؤكد الطلب - سيتم إعادة توجيهه إلى صفحة الدفع:
في صفحة الدفع ، يتم تقديم جميع المعلومات اللازمة للمستخدم من أجل إعادة رسم طلبه مرة أخرى. بمجرد إجراء الدفع ، سيتمكن المستخدمون من العثور على سيارات في حسابهم الشخصي: سيرى المستخدم الذي يمتلك السيارة أن السيارة قد تم استئجارها ، وسيشاهد المستخدم ، الذي استأجر السيارة ، معلومات كاملة عن الوقت المدفوع بالإضافة إلى جميع المعلومات المتعلقة بالوقت المتبقي ووقت نهاية عقد الإيجار لهذه السيارة. يبدو على النحو التالي:
عندما يقرر المستخدم إكمال طلبه قبل الموعد المحدد (لا ينتهي الأمر بالنظام المسؤول عن الطلبات المنتهية ، ولكن المستخدم الذي قدم الطلب) ، لديه الفرصة لضبط تصنيف السيارة الذي استخدمه خلال الوقت المناسب:
مرة أخرى ، لدى المستخدم خيار: ضع تصنيفًا للسيارة ، ثم اضغط على زر 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-файла). Таким образом, применённый мной подход не только позволит пользователю получать доступ в кратчайшие сроки, но и позволит избежать излишних нагрузок системы для загрузки данных из файлов каждый раз при обращении к сервису.
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? بالطبع لا. 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. لكن! 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 )
Изначально, мной была заложена идея, что пользователь может как оформить заказ на определённое время, внеся предоплату, так и просросить его, за что потребуется внести дополнительные деньги за просроченное время. Однако, при дальнейшем развитии идеи, мной были выявлены следующие проблемы, касательно как программной, так и правовой идеи такого подхода:
Поэтому, мной был выбран следующий план действий: Подразумевается, что заказ начинается, как только пользователь оформляет заказ на пользование авто и оплачивает его, а заканчивается этот же заказ ровно тогда, когда время пользования станет равно оплаченному времени. После чего, автомобиль сразу становится доступным для других пользователей в каталоге, а нынешний заказ пропадает с личного кабинета пользователя, оплатившего время на его использование. Если другой пользователь оформит заказ на тот же автомобиль и при прибытии на место обнаружит, что автомобиль отсутствует на том месте, на котором он расположен на карте, он имеет право подать в суд на человека, который просрочил своё время (собственно как и заказчик). Таким образом, каждый пользователь, который оформляет заказ, берёт на себя ответственность закончить его во время.
