نظرات مطالب
آشنایی با NHibernate - قسمت هشتم
واقعاً خسته نباشید آقای نصیری، مجموعه مقالات آشنایی با NHibernate شما عالی است، باعث شد من شروع به یادگیری NHibernate کنم. ممنونم
نظرات مطالب
EF Code First #7
سلام
مدیریت روابط n-n در کلاسهای Poco به چه صورت است؟ من یک برنامه 2-tier دارم و برای Entity هایم state گرفتم و سمت کلاینت وضعیت entity‌ها رو مدیریت میکنم و سمت سرور اونا رو روی DBContext اعمال میکنم.
دو کلاس Role و Permission دارم که باهم رابطه n-n دارند؛ حال اگه یک Role  چند Permission داشته باشه و بخوام یکی از اونا رو حذف کنم و یا آپدیت کنم بهم پیغام خطا میده(An error occurred while saving entities that do not expose foreign key properties for their relationships. The EntityEntries property will return null because a single e ...) و داخل inner exception هم مینویسه ()Violation of PRIMARY KEY constraint 'PK_dbo.SecurityRolePermission'. Cannot insert duplicate key in object 'dbo.SecurityRolePermission'
یعنی در حالتهای آپدیت و حذف هم میخواد insert انجام بده (با ef profiler هم چک کردم)البته فکر کنم تا حدودی معلوم باشه چرا اینکار رو میکنه؛ چون مدیریتی روی state اون کلاس واسط(RolePermission) انجام نمیشه، ممکنه بگید چطوری این مشکل رفع میشه؟
مطالب
کارهایی جهت بالابردن کارآیی Entity Framework #3

در قسمت‌های قبلی (^ و ^) راهکارهایی جهت بالا بردن کارآیی، ارائه شد. در ادامه، به آخرین قسمت این سری اشاره خواهم کرد.

فراخوانی متد شناسایی تغییرات

یادآوری: قبل از هر چیز با توجه به این مقاله دانستن این نکته الزامی است که فراخوانی برخی متدها مانند DbSet.Add سبب فراخوانی DataContext.ChangeTracker.DetectChanges خواهند شد.

فرض کنید قصد افزودن 2000 موجودیت دانش آموز را دارید:

for (int i = 0; i < 2000; i++)
{
    Pupil pupil = GetNewPupil();
    db.Pupils.Add(pupil);
}
db.SaveChanges();
در کد بالا بدلیل فراخوانی متد DbSet.Add و به دنبال آن فراخوانی متد DetectChanges در هر بار اجرای حلقه (2000بار) مدت زمان اجرای کد بالا بسیار زیاد است و اگر به پروفایلر نگاهی بیاندازید، اشغال CPU توسط کوئری بالا، بیش از حد متعارف است.

اگر به تصویر بالا دقت کنید بیش از 34 ثانیه (خط 193 قسمت سوم شکل) جهت افزودن 2000 موجودیت به کانتکست سپری شده است. در حالی که درج این 2000 موجودیت کمی بیش از 1 ثانیه (خط 195 قسمت سوم شکل) که 379 میلی ثانیه (قسمت دوم شکل) آن مربوط به اجرای کوئری اختصاص یافته  طول کشیده است.
بیشترین زمان صرف شده‌ی برای درج 2000 موجودیت، در کد برنامه سپری شده است که با بررسی بیشتر در پروفایلر، متوجه زمان بر بودن فراخوانی متد ()DetectChanges که در فضای نام Data.Entity.Core وجود دارد خواهید شد. این متد 2000 بار به تعداد موجودیت هایی که قصد داریم به بانک اطلاعاتی اضافه نماییم، فراخوانی شده است.

همانطور که در شکل بالا مشخص است همان 34 ثانیه جهت ردیابی تغییرات صرف شده است. EF ردیابی تغییرات را بصورت پیش فرض هر زمانی که قصد افزودن یا ویرایش موجودیتی را داشته باشید، انجام خواهد داد و هر چه موجودیت‌های بیشتری را بخواهید ویرایش یا اضافه نمایید، این زمان نیز بیشتر خواهد شد. در حقیقت زمان لازم برای الگوریتم ردیابی تغییرات بصورت نمایی با رشد موجودیت‌ها افزوده می‌شود. به عبارت دیگر اگر این تعداد موجودیت‌ها را به 4000 عدد برسانید، مدت زمان لازم بیش از 2 برابر افزوده خواهد شد.

راه حل اول:
استفاده از متد ()AddRange ارائه شده در EF6 که جهت درج دسته‌ای (Bulk Insert) ارائه شده است:
var list = new List<Pupil>();

for (int i = 0; i < 2000; i++)
{
    Pupil pupil = GetNewPupil();
    list.Add(pupil);
}

db.Pupils.AddRange(list);
db.SaveChanges();

راه حل دوم:

در سناریوهای پیچیده، مانند درج دسته‌ای چندین موجودیت، شاید مجبور به خاموش نمودن این قابلیت شوید:
db.Configuration.AutoDetectChangesEnabled = false;
توجه داشته باشید اگر قصد دارید از امکان ردیابی تغییرات مجددا بهره‌مند شوید، باید این قابلیت را نیز فعال نمایید. با خاموش نمودن ردیابی تغییرات بار دیگر کوئری ابتدایی را اجرا نمایید. مدت زمان لازم جهت افزودن 2000 موجودیت به کانتکست از بیش از 34 ثانیه به 85 میلی ثانیه کاهش یافته است؛ ولی اعمال تغییرات به بانک اطلاعاتی همانند مرتبه اول بیش از 1 ثانیه طول خواهد کشید.


ردیابی تغییرات

هنگامی که موجودیتی را از بانک اطلاعاتی دریافت نمایید، می‌توانید آن را ویرایش نمایید و مجددا به بانک اطلاعاتی اعمال نمایید. چون EF اطلاعی از قصد شما برای موجودیت نمی‌داند، مجبور است تغییرات شما را زیر نظر بگیرد که این زیر نظر گرفتن، هزینه و سربار دارد و این سربار و هزینه برای داده‌های زیاد، بیشتر خواهد شد. بنابراین اگر قصد دارید اطلاعاتی فقط خواندنی را از بانک اطلاعاتی دریافت نمایید، بهتر است صراحتا به EF بگویید این موجودیت را تحت ردیابی قرار ندهد.
string city = "New York";

List<School> schools = db.Schools
    .AsNoTracking()
    .Where(s => s.City == city)
    .Take(100)
    .ToList();

استفاده از متد AsNoTracking  در کد بالا سبب خواهد شد 100 مدرسه که در شهر نیویورک وجود دارد توسط EF، بدون تحت نظر گرفتن آن‌ها از بانک اطلاعاتی دریافت شوند و سرباری نیز تحمیل نشود.

ویوهای از قبل کامپایل شده

معمولا، هنگامی که از EF برای اولین بار استفاده می‌نمایید، ویوهایی ایجاد می‌گردد که برای ایجاد کوئری‌ها مورد استفاده قرار می‌گیرند. این ویوها در طول حیات برنامه فقط یکبار ایجاد می‌شوند. ولی همین یکبار هم زمانبر هستند. خوشبختانه راه‌هایی وجود دارد که ایجاد این ویوها را در زمان runtime انجام نداد و آن راه، استفاده از ویوهای از پیش کامپایل شده است. یکی از راههای ایجاد این ویوها استفاده از Entity Framework Power Tools است. بعد از نصب اکستنشن، بر روی فایل کانتکست راست کلیک کرده و سپس گزینه‌ی Generate Views را از منوی Entity Framework انتخاب کنید.

توجه داشته باشید که هر تغییری را بعد از ایجاد این ویوها بر روی کانتکست اعمال نمایید، باید آن‌ها را مجددا تولید کنید. برای آشنایی بیشتر با این ویوها به این لینک مراجعه کنید. هم چنین پکیج نیوگتی بنام EFInteractiveViews نیز برای این منظور تهیه و توزیع شده است.


حذف کوئری‌های ابتدایی غیر ضروری

در هنگام شروع به کار با EF، چندین کوئری آغازین بر روی دیتابیس اجرا می‌شوند. یکی از کوئری‌های آغازین جهت تشخیص نسخه‌ی دیتابیس است که همانطور در تصویر زیر مشاهده می‌کنید، در حدود چند میلی ثانیه می‌باشد.

با توجه به توضیحات، در صورتیکه اطلاعی از نسخه‌ی دیتابیس دارید، می‌توانید این کوئری ابتدایی را تحریف نمایید. برای اینکار می‌توان توسط متد ()ResolveManifestToken کلاسی که اینترفیس IManifestTokenResolver را پیاده سازی کرده است، نسخه‌ی دیتابیس را برگردانیم و از یک رفت و برگشت به دیتابیس جلوگیری نماییم.

 public class CustomManifestTokenResolver : IManifestTokenResolver
{
    public string ResolveManifestToken(DbConnection connection)
    {
        return "2014";
    }
}
و توسط کلاسی که از کلاس DbConfiguration ارث بری کرده است آن را استفاده نماییم.
 public class CustomDbConfiguration : DbConfiguration
{
    public CustomDbConfiguration()
    {
        SetManifestTokenResolver(new CustomManifestTokenResolver());
    }
}


تخریب کانتکست

تخریب و از بین بردن کانتکست هنگامی که به آن نیاز نداریم بسیار ضروری است. یکی از روشهای اصولی برای Disposing کانتکست، محصور کردن آن بوسیله دستور Using است (البته فرض بر این است که قرار نیست از الگوهای اشاره شده استفاده نماییم). در صورت عدم تخریب صحیح کانتکست باید منتظر آسیب جدی به کارایی Garbage Collector جهت آزاد سازی منابع مورد استفاده کانتکست و هم چنین باز نمودن اتصالات جدید به دیتابیس باشید.


پاسخگویی به چندین درخواست بر روی یک کانکشن

EF از قابلیتی بنام Multiple Result Sets می‌تواند بهره ببرد که این قابلیت باعث می‌شود بر روی یک کانکشن ایجاد شده، یک یا چند درخواست از دیتابیس ارسال و یا دریافت شود که سبب کاهش تعداد رفت و برگشت به دیتابیس می‌شود. کاربرد دیگر این قابلیت، زمانی است که تاخیر زیادی (latency) بین اپلیکیشن و دیتابیس وجود دارد.

برای فعالسازی کافی است مقدار زیر را در کانکشن استرینگ اضافه نمایید:

MultipleActiveResultSets=True;


استفاده از متدهای ناهمگام

در C#5 و EF6 پشتیبانی خوبی از متدهای ناهمگام فراهم شده است و اکثر متدهایی مانند ToListAsync, CountAsync, FirstAsync, SaveChangesAsync و غیره که باعث رفت و برگشت به دیتابیس می‌شوند امکان پشتیبانی ناهمگام را نیز دارند. البته این قابلیت برای برنامه‌های یک درخواست در یک زمان شاید مفید نباشد؛ ولی برای برنامه‌های وبی برعکس. در برنامه وب جهت پشتیبانی از بارگذاری همزمان (concurrent) قابلیت ناهمگام (Async) سبب خواهد شد منابع تا زمان اجرای کوئری به ThreadPool بازگردانده شود و برای سرویس دهی مهیا باشند که باعث افزایش scalability خواهد شد.

بررسی و آزمایش با داده‌های واقعی

در اکثر مواقع کارآیی با حجیم شدن داده‌ها کاهش پیدا می‌کند (البته در صورت عدم رعایت اصول استاندارد). بنابراین بررسی کارآیی در محیط هایی با حجم داده‌های بالا ضروری است. هیچ چیز بدتر از آن نیست که همه چیز در محیط توسعه خوب و بی نقص باشد ولی در محیط عملیاتی به شکست بیانجامد. به همین جهت سعی کنید از ابزارهای تولید داده (^ و ^ و ^) برای ایجاد داده‌های آزمایشی استفاده نمایید. سپس کارآیی کوئری خود را مورد بررسی و آزمایش قرار دهید.

مطالب
گوش دادن به تغییرات تم ویندوز 10 بدون نیاز به WinRT در سی شارپ
امروز میخواستم برای یکی از پروژه‌هایم، قابلیتی را پیاده سازی کنم که هماهنگ با تم ویندوز، تم برنامه را عوض کند (تیره/روشن). به این منظور که وقتی تم ویندوز Dark می‌شد، تم برنامه‌ی من هم Dark بشود و برعکس. ساده‌ترین کار این بود که از کدهای WinRT که توسط بسته‌ی نیوگت SDK Contract ارائه میشود استفاده کرد. در این صورت کافیست فقط از کلاس ThemeManager استفاده کنیم و بدون کوچکترین خونریزی، برنامه را به این ویژگی مجهز کنیم😁 اما خب، هرچیزی هزینه‌ی خودش را دارد و من به شخصه علاقه‌ای به استفاده از 25 مگابایت، فقط برای شناسایی وضعیت تم ویندوز را ندارم! پس خودم دست به کار شدم تا یک Listener برای این منظور بنویسم.
در دات نت یکسری رخ‌داد وجود دارند که مربوط به سیستم عامل میشوند و از کلاس SystemEvents قابل دسترسی هستند. در اینجا ایونتی داریم به اسم UserPreferenceChanged که شامل مواردی میشود که کاربر، تنظیمات ویندوز را تغییر می‌دهد. هر تغییری که در تنظیمات ویندوز اعمال بشود، درون یکی از Category‌ها صدا زده میشود. پس اگر ما این ایونت را رجیستر کنیم، هر موقع تغییری در تنظیمات ویندوز اعمال بشود، برنامه‌ی ما نیز متوجه میشود.
برای این منظور یک کلاس را ایجاد می‌کنیم و در متد سازنده‌ی آن، این رخ‌داد را ثبت میکنیم:
pubic class ThemeHelper
{
    public ThemeHelper()
    {
        SystemEvents.UserPreferenceChanged += SystemEvents_UserPreferenceChanged;
    }

    private void SystemEvents_UserPreferenceChanged(object sender, UserPreferenceChangedEventArgs e)
    {
        switch (e.Category)
        {
            case UserPreferenceCategory.Accessibility:
                break;
            case UserPreferenceCategory.Color:
                break;
            case UserPreferenceCategory.Desktop:
                break;
            case UserPreferenceCategory.General:
                break;
            case UserPreferenceCategory.Icon:
                break;
            case UserPreferenceCategory.Keyboard:
                break;
            case UserPreferenceCategory.Menu:
                break;
            case UserPreferenceCategory.Mouse:
                break;
            case UserPreferenceCategory.Policy:
                break;
            case UserPreferenceCategory.Power:
                break;
            case UserPreferenceCategory.Screensaver:
                break;
            case UserPreferenceCategory.Window:
                break;
            case UserPreferenceCategory.Locale:
                break;
            case UserPreferenceCategory.VisualStyle:
                break;
        }
    }
}
 همینطور که می‌بینید، این دسته بندی شامل موارد مختلفی میشود که به بخش‌های مختلف تنظیمات ویندوز مربوط است. تنظیمات مربوط به تم، درون General صدا زده میشود. پس کدهای ما قرار است وارد این قسمت بشود. متاسفانه این رخ‌داد اطلاعات کاملتری را به ما نمی‌دهد و فقط اطلاع می‌دهد که تغییری رخ داده (همینطور که قبلا گفتم، هرچیزی هزینه‌ای دارد). پس ما باید مشخصات تم فعلی را دریافت کنیم؛ اما از کجا؟ معلوم است رجیستری! همه چیز در رجیستری ثبت میشود و به‌راحتی قابل دسترسی هست. پس یک متد می‌نویسیم که کلید رجیستری مربوطه را بخواند و آن را بصورت یک مدل (Light یا Dark) برگرداند:   
    private const string RegistryKeyPathTheme = @"Software\Microsoft\Windows\CurrentVersion\Themes\Personalize";
    private const string RegSysMode = "SystemUsesLightTheme";

    public static UITheme GetWindowsTheme()
    {
        return GetThemeFromRegistry(RegSysMode);
    }

    private static UITheme GetThemeFromRegistry(string registryKey)
    {
        using var key = Registry.CurrentUser.OpenSubKey(RegistryKeyPathTheme);
        var themeValue = key?.GetValue(registryKey) as int?;
        return themeValue != 0 ? UITheme.Light : UITheme.Dark;
    }
    
    public enum UITheme
    {
        Light,
        Dark
    }
حالا ما نیاز به یک رخ‌داد داریم که کاربر بتواند در برنامه‌ی خودش آن‌را ثبت کند و نیازی به پیاده سازی این کدها نداشته باشد. پس یک EventHandler را به اسم WindowsThemeChanged ایجاد میکنیم: 
    public event EventHandler<FunctionEventArgs<UIWindowTheme>> WindowsThemeChanged;
    
    protected virtual void OnWindowsThemeChanged(UIWindowTheme theme)
    {
        EventHandler<FunctionEventArgs<UIWindowTheme>> handler = WindowsThemeChanged;
        handler?.Invoke(this, new FunctionEventArgs<UIWindowTheme>(theme));
    }
من میخواهم که کاربر، مقدار تم فعلی و رنگ Accent فعلی را نیز بتواند از طریق این رخ‌داد، دریافت کند. پس ما باید یک EventArgs را ایجاد کنیم که پراپرتی‌های دلخواهی را داشته باشد. برای همین کلاس FunctionEventArgs را ایجاد میکنیم:
public class FunctionEventArgs<T> : RoutedEventArgs
{
    public FunctionEventArgs(T theme)
    {
        Theme = theme;
    }
    public FunctionEventArgs(RoutedEvent routedEvent, object source) : base(routedEvent, source) { }
    public T Theme { get; set; }
}
این کلاس از RoutedEventArgs ارث بری کرده و بصورت جنریک پیاده سازی شده‌است. به این معنا که ما میتوانیم هر نوع دلخواهی را که خواستیم، به عنوان arg استفاده کنیم. اگر دقت کنید من یک مدل دلخواه را به عنوان arg مشخص کرده‌ام:
FunctionEventArgs<UIWindowTheme>
میتوانستیم از همان UITheme هم استفاده کنیم؛ ولی نمی‌توانستیم مقدار Accent را به کاربر برگردانیم. برای همین، مدلی را به اسم UIWindowTheme ایجاد میکنیم:
public class UIWindowTheme
{
    public Brush AccentBrush { get; set; }
    public UITheme CurrentTheme { get; set; }
}
کار تمام است. حالا باید کدهای داخل متد SystemEvents_UserPreferenceChanged را بنویسیم (دقت کنید که کد، باید داخل بخش General نوشته شود):
case UserPreferenceCategory.General:
   var changedTheme = new UIWindowTheme()
   {
         AccentBrush = SystemParameters.WindowGlassBrush,
         CurrentTheme = GetWindowsTheme()
   };
   OnWindowsThemeChanged(changedTheme);
break;
یک مدل را ایجاد کرده و مقدار AccentBrush را برابر با WindowGlassBrush قرار می‌دهیم. این پراپرتی هم مانند ایونتی که اول معرفی کردیم، مربوط به سیستم عامل بوده و رنگ فعلی Accent را بر می‌گرداند. برای مقدار CurrentTheme نیز متدی را که بالاتر برای دریافت تم فعلی از رجیستری نوشتیم، صدا می‌زنیم و در پایان این مدل را به ایونت، پاس می‌دهیم. در پایان می‌توانیم به این صورت ایونت خود را پیاده سازی کنیم:
    ThemeHelper tm = new ThemeHelper();
    tm.WindowsThemeChanged +=OnWindowsThemeChanged;

    private void OnWindowsThemeChanged(object? sender, FunctionEventArgs<RegistryThemeHelper.UIWindowTheme> e)
    {
        rec.Fill = e.Theme.AccentBrush;
        if (e.Theme.CurrentTheme == ThemeHelper.UITheme.Light)
        {
            Background = Brushes.White;
        }
        else
        {
            Background = Brushes.Black;
        }
    }

 

  
نظرات مطالب
EF Code First #14
ممنون از راهنماییتون، پروژه رو نگاه کردم، شبیه به سناریو فوق در بخش ویرایش یک پست وجود داره که در اونجا رابطه یک به چند بین Post  و DownLoadLink هست.
اما روشی که برای ویرایش در اونجا استفاده شده به این صورت هست که ابتدا در در اکشن متد   EditPost کنترلر   PostController  ناحیه ادمین، همه DownLoadLink های پستی که در حال ویرایش آن هستیم، پاک میشوند و سپس در متد EditPost مربوط به PostService، دانلودلینکهای  EditPostModel  به جای آنها مینشینند، در واقع در صورت ویرایش دانلودلینکهای یک پست، ویرایش واقعی انجام نمیشود، بلکه این کار با حذف(sql Delete) کلیه دانلودلینکهای آن پست از DB و درج مجدد دانلودلینکهای تغییر یافته و نیافته (sql Insert) ، شبیه سازی میشود. درست است که نتیجه کار با ویرایش واقعی(sql Update) تفاوت نمیکتد اما به نظر من ویرایش با این روش سه مشکل زیر را دارد:
  1. حتی اگر هنگام ویرایش یک پست هیچ تغییری در دانلودلینکها داده نشود باز هم حذف تمامی آنها و درج مجدد آنها صورت خواهد گرفت.
  2. پایین آمدن کارایی وقتی که تعداد رکوردهای طرف چندِ رابطۀ یک به چند زیاد باشد(در اینجا دانلودلینکها).
  3. در برخی موارد مثل مورد زیر که طرف چند رابطه ( OrderLine ) دارای ارتباطاتی باشد، حذف فیزیکی  و درج مجدد آن به هنگام ویرایش Order دردسرساز خواهد شد:

آیا راهی برای رفع این موارد وجود دارد؟ به عبارت دیگر آیا راهی وجود دارد که به جای حذف فیزیکی رکوردها و درج تغییرات(Delete,Insert)؛ فقط تغییرات را اعمال کنیم(Update)؟
مطالب
راه اندازی دیتابیس postgresql در برنامه‌های ASP.NET Core – قسمت 2

در قسمت قبل به معرفی postgresql پرداختیم; در این قسمت قصد ایجاد و راه اندازی یک api با استفاده از دیتابیس postgresql و استفاده از تکنولوژی‌های آن را با استفاده از docker داریم.


ابتدا با استفاده از دستور زیر یک پروژه‌ی جدید asp.net core را ایجاد کنید:

dotnet new webapi --minimal -o YourDirectoryPath:\YourFolderName

سپس فایل docker-compose.yaml را به روت پروژه اضافه کنید که شامل کانفیگ‌های زیر میباشد: 

version: '3.1'

services:

  db:
    image: postgres
    container_name: db
    restart: always
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USERNAME: postgres
      POSTGRES_DB: BloggingDb
    ports:
        - "5432:5432"
    volumes:
      - postgres_data:/data/db

  adminer:
    image: adminer
    restart: always
    ports:
      - 8080:8080
  
  pgadmin4:
    image: dpage/pgadmin4
    restart: always
    environment:
      PGADMIN_DEFAULT_EMAIL: pgadmin4@pgadmin.org
      PGADMIN_DEFAULT_PASSWORD: admin
      PGADMIN_CONFIG_SERVER_MODE: 'False'
    ports:
      - 5050:80
    volumes:
      - pgadmin:/var/lib/pgadmin
    depends_on:
      - db

volumes:
  postgres_data:
  pgadmin:

سپس با اجرای دستور زیر در روت پروژه، سرویس‌ها را راه اندازی کنید: 

docker compose up -d


معرفی سرویس‌های استفاده شده در تنظیمات فایل بالا: 

سرویس db

نمونه ایمیج اصلی، volume، تنظیمات connection string در آن استفاده شده است.

سرویس adminer :

https://hub.docker.com/_/adminer /

Adminer - Database management in a single PHP file

یک برنامه تحت وب مدیریت پایگاه داده ساده میباشد که ویژگی‌ها MySql را در کنار سرعت و امنیت ارائه میدهد و در آدرس http://localhost:8080 / اجرا خواهد شد.

سرویس pgadmin4 :

pgAdmin - PostgreSQL Tools

dpage/pgadmin4 - Docker Image | Docker Hub

در حال حاضر این برنامه محبوب‌ترین برنامه مدیریت پایگاه داده میباشد که ویژگی‌های پیشرفته‌ای را نیز پوشش میدهد و در آدرس http://localhost:5050 / اجرا خواهد شد. 


اکنون نوبت نوشتن کد‌ها میباشد. 

- تنظیم connection string در فایل appsettings.json:

"ConnectionStrings": {
    "BloggingContext": "Username=postgres;Password=postgres;Server=localhost;Database=BloggingDb”
}

- و همینطور پکیج‌های زیر را به برنامه خود رفرنس دهید: 

dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL
dotnet add package Microsoft.EntityFrameworkCore
dotnet add package Microsoft.EntityFrameworkCore.Design

- مدل‌های برنامه را در مسیر /Models ایجاد کنید: 

namespace NpgsqlAPI.Models;

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; } = null!;
    public string Content { get; set; } = null!;

    public int BlogId { get; set; }
    public Blog Blog { get; set; } = null!;
}

namespace NpgsqlAPI.Models;

public class Blog
{
    public int BlogId { get; set; }
    public string? Url { get; set; }

    public List<Post>? Posts { get; set; }
}

- سپس BloggingContext را در مسیر /Data ایجاد کنید:

using Microsoft.EntityFrameworkCore;
using NpgsqlAPI.Models;

namespace NpgsqlAPI.Data;

public class BloggingContext : DbContext
{
    public BloggingContext(DbContextOptions<BloggingContext> options)
        : base(options)
    {
    }
    public DbSet<Blog> Blogs => Set<Blog>();
    public DbSet<Post


- سپس اینترفیس IBlogServices را در مسیر  /Servicec/Blogs ایجاد کنید: 

using NpgsqlAPI.Models;

namespace NpgsqlAPI.Services.Blogs;
public interface IBlogServices
{
    Task<IEnumerable<Blog>> GetList();
    Task<Blog?> Get(uint id);
    Task<uint> Add(Blog obj);
    Task AddRange(Blog[] obj);
    Task Update(Blog obj);
    Task UpdateRange(Blog[] obj);
    Task Remove(uint id);
}


-  و سپس پیاده سازی آن را در فایل BlogEFServices و در کنار اینترفیس آن قرار دهید: 

using Microsoft.EntityFrameworkCore;
using NpgsqlAPI.Data;
using NpgsqlAPI.Models;

namespace NpgsqlAPI.Services.Blogs;
public sealed class BlogEFServices : IBlogServices
{
    private readonly BloggingContext _context;
    public BlogEFServices(BloggingContext context)
    {
        _context = context;
    }

    public async Task<uint> Add(Blog obj)
    {
        await _context.Blogs.AddAsync(obj);
        return (uint)await SaveChangesAsync();
    }

    public async Task AddRange(Blog[] obj)
    {
        await _context.Blogs.AddRangeAsync(obj);
        await SaveChangesAsync();
    }

    public async Task<Blog?> Get(uint id)
    {
        return await _context.Blogs.FirstOrDefaultAsync(x=>x.BlogId == id);
    }

    public async Task<IEnumerable<Blog>> GetList()
    {
       return await _context.Blogs.ToListAsync();
    }

    public async Task Remove(uint id)
    {
        var entity = await Get(id);
        _context.Blogs.Remove(entity!);
        await SaveChangesAsync();
    }

    public async Task Update(Blog obj)
    {
        _context.Blogs.Update(obj);
        await SaveChangesAsync();
    }

    public async Task UpdateRange(Blog[] obj)
    {
        _context.Blogs.UpdateRange(obj);
        await SaveChangesAsync();
    }

    private async Task<int> SaveChangesAsync()
    {
        return await _context.SaveChangesAsync();
    }
}


- اکنون  endpoint‌های api را در فایل program.cs ایجاد کنید:

using System.Data;
using Microsoft.EntityFrameworkCore;
using Npgsql;
using NpgsqlAPI.Services.Blogs;
using NpgsqlAPI.Data;
using NpgsqlAPI.Models;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

string connectionString = builder.Configuration.GetConnectionString("BloggingContext")!;

builder.Services.AddDbContext<BloggingContext>(options =>
        options.UseNpgsql(connectionString));

builder.Services.AddTransient<IDbConnection>(_ => new NpgsqlConnection(connectionString));

// builder.Services.AddScoped<IBlogServices, BlogDapperServices>();
// builder.Services.AddScoped<IBlogServices, BlogEFRawQueryServices>();
builder.Services.AddScoped<IBlogServices, BlogEFServices>();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.MapGet("/blogs", async (IBlogServices service) => await service.GetList())
.WithName("GetBlogs")
.WithOpenApi();

app.MapGet("/blogs/{id}", async (IBlogServices service, uint id) => await service.Get(id))
.WithName("GetBlog")
.WithOpenApi();

app.MapPost("/blogs", async (IBlogServices service, Blog blog) => await service.Add(blog))
.WithName("AddBlog")
.WithOpenApi();

app.MapDelete("/blogs/{id}", async (IBlogServices service, uint id) => await service.Remove(id))
.WithName("RemoveBlog")
.WithOpenApi();

app.MapPut("/blogs", async (IBlogServices service, Blog blog) => await service.Update(blog))
.WithName("UpdateBlog")
.WithOpenApi();

app.MapPut("/blogs/Bulk", async (IBlogServices service, Blog[] blogs) =>
 await service.UpdateRange(blogs))
.WithName("UpdateBulkBlog")
.WithOpenApi();

app.MapPost("/blogs/Bulk", async (IBlogServices service, Blog[] blogs) =>
 await service.AddRange(blogs))
.WithName("AddBulkBlog")
.WithOpenApi();

app.Run();

تمامی کد‌های برنامه تا به اینجا نوشته شده‌اند. اکنون migration را پس از اطمینان از اجرا بودن داکر اجرا کنید 

dotnet ef migrations add Init
dotnet ef database update

و برنامه را اجرا و تست کنید. 


کد‌های کامل این مطلب

نظرات مطالب
EF Code First #7
سلام؛
در SQL SERVER قسمتی داریم به نام INSERT And UPDATE Specification که دو گزینه‌ی Delete Rule و Update Rule برای ارتباط‌ها وجود دارند.
در اینجا شما WillCascadeOnDelete رو بیان کردید ولی من هر چه دنبال متدی متناظر با Update Rule میگردم وجود نداره.
یه چیزی مثل : WillCascadeOnUpdate 
آیا در EF ساپورت نمیشه؟