شرمنده سایت Nuget بالا نمیاد و نمیتوانم کتابخانه های EF Core به پروژه جدید اضافه کنم پروژه قبلی را اگر تغییر نام دهم دو تا namespace به دست میاد که و اولی نام قبلی که تغییر نمیکنه و تغییر دهم خطا میده و دومی نام پروژه جدید است

سایت خالی nuget بالا می آید ولی برای دانلود کتابخانه زمان زیادی طول می‌کشه و api.nuget.org درست متصل نیست

با دردسر کتابخانه ها نصب شد هوش مصنوعی من فرق میکند و این پروژه هم فیلتر کردن محصول برای آموزش گذاشتم نکته: اگر همه آموزش تکراری هستند من را ببخشید و من هنوز کدها را خوب درک نکرده ام و تمرین کنم و به اشتراک بگذارم نکته دوم : برای تازه وارد که چگونه پروژه را اجرا کنند من یک ویدئو کوتاه درست میکنم تا بتوانند پروژه را اجرا کنند

نحوه استفاده پروژه های من اول دیتابیس FilterAppDB حذف کردم و نشان دهم که اول در ویژوال استودیو در قسمت Package Manager Console کلمه Update-Database را وارد کنید که یک دیتابیس در sqlserver ساخته شود نکته: sqlserver من Express است

کدی بکار رفته است که تاریخ در فیلتر وارد میکنید تاریخ شمسی را به میلادی تبدیل کرده است من فراموش کردم دو نوع تاریخ برای نمایش بگذارم و اگر سیستم کامپیوتری میلادی باشد ممکنه از فیلتر درست استفاده نکند من قبلاً در کدهای قبل از دو نوع تاریخ گذاشتم آیا کسانی که مشتاق به کد نویسی داره پروژه من را تکمیل کند

یک تغییر کوچک دادم و پروژه را تکمیل کردم و ربطی به سیستم تقویم کامپیوتر نداره

سوال دارم : کسی میتواند در ویرایش تقویم شمسی را ویرایش کند اگر کسی توانسته به من پیام دهد چند روز بعد کدش را می‌نویسم

این طوری تاریخ میلادی در دیتابیس ذخیره میشود و تاریخ شمسی نمایش داده می شود

در دنیای برنامه‌نویسی، مدیریت تاریخ و زمان یکی از آن چالش‌هایی است که اگر از ابتدا خشت اولش را کج بگذارید، در آینده با کوهی از مشکلات (به خصوص در محاسبات و مرتب‌سازی) روبرو می‌شوید. ‌ در ادامه بهترین رویه (Best Practice) برای مدیریت تاریخ را با هم بررسی می‌کنیم: ‌ ۱. ثبت در دیتابیس: فقط میلادی! بدون هیچ شک و تردیدی، تاریخ را در دیتابیس به صورت میلادی (ترجیحاً در فرمت UTC) ذخیره کنید. دلایل این کار بسیار حیاتی هستند: ‌ استاندارد جهانی: تمام توابع داخلی دیتابیس‌ها (مثل MySQL، PostgreSQL، SQL Server) برای کار با تاریخ میلادی بهینه شده‌اند. مرتب‌سازی (Sorting): مرتب‌سازی تاریخ‌های میلادی بسیار دقیق و سریع انجام می‌شود. محاسبات: اگر بخواهید "دو هفته بعد" یا "فاصله بین دو تاریخ" را حساب کنید، توابع دیتابیس روی تاریخ میلادی به درستی کار می‌کنند، در حالی که برای شمسی به مشکل برمی‌خورید. یکپارچگی: اگر روزی تصمیم بگیرید اپلیکیشن خود را چندزبانه کنید یا از سروری در خارج از ایران استفاده کنید، استفاده از UTC شما را نجات می‌دهد. ‌ ۲. نمایش به کاربر: شمسی فقط در لحظه نمایش (View)، تاریخ میلادی را از دیتابیس بگیرید و با استفاده از کتابخانه‌های تبدیل تاریخ، آن را به شمسی تبدیل کرده و به کاربر نشان دهید. ‌ ۳. در مورد Input Date چه باید کرد؟ برای ورودی‌ها دو راهکار رایج وجود دارد: ‌ راهکار حرفه‌ای (استفاده از DatePicker): از کتابخانه‌های "تقویم شمسی" (مثل

persian-datepicker

برای وب یا کتابخانه‌های مشابه در اندروید و iOS) استفاده کنید. کاربر تاریخ را شمسی انتخاب می‌کند، اما شما در پس‌زمینه (سمت کلاینت یا قبل از ذخیره در دیتابیس)، آن را به میلادی تبدیل می‌کنید و سپس به سمت سرور می‌فرستید. ‌ استفاده از Input معمولی: اگر از

input 

Date پیش‌فرض مرورگرها استفاده کنید، این ورودی معمولاً تقویم میلادی نشان می‌دهد. اگر اصرار دارید کاربر شمسی وارد کند، باید ورودی را به صورت متن (Text) بگیرید، با کدهای برنامه‌نویسی آن را اعتبار‌سنجی (Validation) کنید، به میلادی تبدیل کنید و سپس ذخیره نمایید. ‌ خلاصه استراتژی پیشنهادی: ۱. در دیتابیس فیلد را از نوع

DateTime

یا

Timestamp

و به صورت میلادی بگذارید. ۲. در فرانت‌اند از یک کتابخانه تقویم شمسی استفاده کنید. ۳. هنگام ارسال فرم، تاریخ شمسی را به میلادی تبدیل کرده و به دیتابیس بفرستید. ۴. هنگام دریافت داده از دیتابیس، آن را به شمسی تبدیل کرده و به کاربر نمایش دهید. ‌ برای زبان‌های مختلف کتابخانه‌های بسیار خوبی وجود دارد؛ مثلاً در جاوااسکریپت

moment-jalaali

یا

date-fns-jalali

و در PHP کتابخانه

verta

یا

jdate

از بهترین گزینه‌ها هستند.

در ویرایش از کتابخانه persian-datepicker استفاده شده است تقویم شمسی برای اینکه راحت تاریخ را انتخاب کنم

کتابخانه جاوا اسکریپت

در دنیای EF Core، این دو عبارت از نظر عملکرد نهایی تقریباً یکسان هستند، اما از نظر ساختار کدنویسی و انعطاف‌پذیری تفاوت‌های ظریفی دارند که در ادامه با زبانی ساده بررسی می‌کنیم. *۱. مفهوم کلی* هر دو عبارت در حال ساخت یک *Query* هستند. در این مرحله هیچ داده‌ای از دایتابیس فراخوانی نمی‌شود (تکنیک Deferred Execution). کد شما فقط دارد به EF می‌گوید: "من قرار است روی این جدول کارهایی انجام دهم، اما فعلاً صبر کن تا دستور نهایی (مثل

ToList

) را بدهم." *۲. بررسی عبارت اول:

()AsQueryable.

* csharp var query = _db.Product.AsQueryable(); زمانی که روی یک

DbSet

(مثل

Product

) متد

AsQueryable

را صدا می‌زنید، در واقع دارید به صراحت اعلام می‌کنید که می‌خواهید با این مجموعه به عنوان یک منبع داده قابل پرس‌وجو رفتار شود. * *مزیت:* اگر بخواهید این کوئری را به متدهای دیگر پاس بدهید یا از Unit Testing (با داده‌های Mock) استفاده کنید، این روش استانداردتر است. * *تغییر نوع:* اگر به اشتباه متدی را صدا بزنید که خروجی را به

IEnumerable

تبدیل کند،

AsQueryable

می‌تواند دوباره آن را به جریان IQueryable برگرداند تا فیلترها همچنان در سمت دایتابیس اجرا شوند (نه در RAM). *۳. بررسی عبارت دوم: انتساب مستقیم* csharp IQueryable<Product> query = _db.Products; در اینجا شما از ویژگی "چندریختی" (Polymorphism) استفاده کرده‌اید. چون کلاس

DbSet

خودش رابط

IQueryable

را پیاده‌سازی کرده است، می‌توانید مستقیماً آن را درون یک متغیر از این نوع بریزید. * *سادگی:* این روش کوتاه‌تر است و در ۹۰ درصد کدهای معمولی استفاده می‌شود. * *وضوح:* با نوشتن صریح نوع داده (

IQueryable<Product>

) چشمان برنامه‌نویس دیگر بلافاصله متوجه می‌شود که قرار است فیلترهای بیشتری روی این متغیر اعمال شود. *۴. تفاوت در کجاست؟* تفاوت اصلی زمانی مشخص می‌شود که بخواهید کدی بنویسید که هم با دیتابیس کار کند و هم با لیست‌های معمولی در حافظه (برای تست واحد یا Unit Test). * *متد

()AsQueryable

:* این متد مثل یک مبدل عمل می‌کند. اگر ورودی آن یک لیست معمولی (In-Memory) باشد، آن را شبیه‌سازی می‌کند تا مثل یک کوئری دیتابیس رفتار کند. این کار باعث می‌شود کدهای لایه سرویس شما بدون تغییر، هم برای دیتابیس واقعی و هم برای تست‌های شما کار کنند. * *انتساب مستقیم:* بیشتر برای زمانی است که مستقیماً با خود

DbContext

در لایه Repository یا Controller کار می‌کنید. *خلاصه کلام* اگر در حال نوشتن یک برنامه معمولی هستید، هر دو روش خروجی یکسانی (یک دستور SQL بهینه) تولید می‌کنند. اما اگر به دنبال نوشتن کدی هستید که قابلیت تست‌گرفتن بالایی داشته باشد یا می‌خواهید از متغیرهای

var

استفاده کنید و در عین حال مطمئن باشید که نوع آن

IQueryable

باقی می‌ماند، استفاده از

()AsQueryable

انتخاب حرفه‌ای‌تری است.