نظرات مطالب
خودکارسازی فرآیند نگاشت اشیاء در AutoMapper
ممنون از پاسختون؛ تنظیمات رجیستری مربوط به اتومپر من به این صورته:
همانطور که ملاحظه میکنید تنها یک وهله از کلاس MapperConfiguration به صورت Singleton تهیه و از آن برای تهیه وهله از IMapper
اگه جایی اشتباه کردم ممنون میشم راهنمایی کنید.
public class AutomapperRegistry : Registry { public AutomapperRegistry() { For<MapperConfiguration>().Use("", ctx => { var config = new MapperConfiguration(cfg => { AutomapperConfig.setup(cfg, ctx); }); config.AssertConfigurationIsValid(); return config; }).Singleton(); For<IMapper>() .HttpContextScoped() .Use(ctx => ctx.GetInstance<MapperConfiguration>().CreateMapper(ctx.GetInstance)); } }
استفاده میشه و برای تنظیمات مپ از متدهای استاتیک آن استفاده نمیکنم و به این صورته:
public static class AutomapperConfig { public static void setup(IMapperConfigurationExpression mappconfig, IContext ctx) { configureAutoMapper(mappconfig, ctx); } private static void configureAutoMapper(IMapperConfigurationExpression mappconfig, IContext ctx) { var profiles = ctx.GetAllInstances<AutoMapper.Profile>().ToList(); foreach (var profile in profiles) { mappconfig.AddProfile(profile); } var types = Assembly.GetExecutingAssembly().GetExportedTypes(); LoadStandardMappings(types, mappconfig); LoadCustomMappings(types, mappconfig); } private static void LoadStandardMappings(IEnumerable<Type> types, IMapperConfigurationExpression mapper) { var maps = (from t in types from i in t.GetInterfaces() where i.IsGenericType && i.GetGenericTypeDefinition() == typeof(IMapFrom<>) && !t.IsAbstract && !t.IsInterface select new { Source = i.GetGenericArguments()[0], Destination = t }).ToArray(); foreach (var map in maps) { mapper.CreateMap(map.Source, map.Destination); } } private static void LoadCustomMappings(IEnumerable<Type> types, IMapperConfigurationExpression mapper) { var maps = (from t in types from i in t.GetInterfaces() where typeof(IHaveCustomMappings).IsAssignableFrom(t) && !t.IsAbstract && !t.IsInterface select (IHaveCustomMappings)Activator.CreateInstance(t)).ToArray(); foreach (var map in maps) { map.CreateMappings(mapper); } } }
آشنایی
این قسمت از مقاله به ایده اصلی برنامه نویسی تابعی و دلیل وجودی آن خواهد پرداخت. هیچ شکی نیست که بزرگترین چالش در توسعه نرم افزارهای بزرگ، پیچیدگی آن است. تغییرات همیش اجتناب ناپذیر هستند. به خصوص زمانی که صحبت از پیاده سازی امکان جدیدی باشد، پیچیدگی اضافه خواهد شد. در نتیجه منجر به سخت شدن فهمیدن کد میشود، زمان توسعه را بالاتر میبرد و باگهای ناخواسته را به وجود خواهد آورد. همچنین تغییر هر چیزی در دنیای نرم افزار بدون به وجود آوردن رفتارهای ناخواسته و یا اثرات جانبی، تقریبا غیر ممکن است. در نهایت همه این موارد میتوانند سرعت توسعه را پایین برده و حتی باعث شکست پروژههای نرم افزاری شوند. سبکهای کد نویسی دستوری (Imperative) مانند برنامه نویسی شیء گرا، میتوانند به کاهش این پیچیدگیها تا حد خوبی کمک کنند. البته در صورتیکه به طور صحیحی پیاده شوند. در واقع با ایجاد Abstraction در این مدل برنامه نویسی، پیچیدگیها را مخفی میکنیم.
سیر تکاملی الگوهای برنامه نویسی
برنامه نویسی شیء گرا در خون برنامه نویسهای سی شارپ جاری است؛ ما معمولا ساعتها درباره اینکه چگونه میتوانیم با استفاده از ارث بری و ترتیب پیاده کلاسها، یک هدف خاص برسیم، بر روی کپسوله سازی تمرکز میکنیم و انتزاع (Abstraction) و چند ریختی ( Polymorphism ) را برای تغییر وضعیت برنامه استفاده میکنیم. در این مدل همیشه احتمال این وجود دارد که چند ترد به صورت همزمان به یک ناحیه از حافظه دسترسی داشته باشند و تغییری در آن به وجود بیاورند و باعث به وجود آمدن شرایط Race Condition شوند. البته همگی به خوبی میدانیم که میتوانیم یک برنامهی کاملا Thread-Safe هم داشته باشیم که به خوبی مباحث همزمانی و همروندی را مدیریت کند؛ اما یک مساله اساسی در مورد کارآیی باقی میماند. گرچه Parallelism به ما کمک میکند که کارآیی برنامه خود را افزایش دهیم، اما refactor کردن کدهای موجود، به حالت موازی، کاری سخت و پردردسر خواهد بود.
برنامه نویسی تابعی، یک الگوی برنامه نویسی است که از یک ایده قدیمی (قبل از اولین کامپیوترها !) برگرفته شدهاست؛ زمانیکه دو ریاضیدان، یک تئوری به نام lambda calculus را معرفی کردند، که یک چارچوب محاسباتی میباشد؛ عملیاتی ریاضی را انجام میدهد و نتیجه را محاسبه میکند، بدون اینکه تغییری را در وضعیت دادهها و وضعیت، به وجود بیاورد. با این کار، فهمیدن کدها آسانتر خواهد بود و اثرات جانبی را کمتر خواهد کرد، همچین نوشتن تستها سادهتر خواهند شد.
جالب است اگر زبانهای برنامه نویسی را که از برنامه نویسی تابعی پشتیبانی میکنند، بررسی کنیم، مانند Lisp , Clojure, Erlang, Haskel، هر کدام از این زبانها جنبههای مختلفی از برنامه نویسی تابعی را پوشش میدهند. #F یک عضو از خانواده ML میباشد که بر روی دات نت فریمورک در سال 2002 پیاده سازی شده. ولی جالب است بدانید بیشتر زبانهای همه کاره مانند #C به اندازه کافی انعطاف پذیر هستند تا بتوان الگوهای مختلفی را توسط آنها پیاده کرد. از آنجایی که اکثرا ما از #C برای توسعه نرم افزارهایمان استفاده میکنیم، ترکیب ایدههای برنامه نویسی تابعی میتواند راهکار جالبی برای حل مشکلات ما باشد.
قبلا درباره توابع ریاضی صحت کردیم. در زبانهای برنامه نویسی هم ایده همان است؛ ورودیهای مشخص و خروجی مورد انتظار، بدون تغییری در حالت برنامه. به این مفاهیم شفافیت و صداقت توابع میگوییم که در ادامه با آن بیشتر آشنا میشویم. به این نکته توجه داشته باشید که منظور از تابع در #C فقط Method نیست؛ Func , Action , Delegate هم نوعی تابع هستند.
به طور ساده با نگاه کردن به ورودیهای تابع و نام آنها باید بتوانیم کاری را که انجام میدهد، حدس بزنیم. یعنی یک تابع باید بر اساس ورودیهای آن کاری را انجام دهد و نباید یک پارامتر Global آن را تحت تاثیر قرار دهد. پارامترهای Global میتوانند یک Property در سطح یک کلاس باشند، یا یک شیء که وضعیت آن تحت کنترل تابع نیست؛ مانند شی DateTime. به مثال زیر توجه کنید:
این تابع شفاف نیست. چرا؟ چون امروز، یک خروجی را میدهد و فردا یک خروجی دیگر را! به بیان دیگر وابسته به یک شیء سراسری DateTime.Now است.
آیا میتوانید این تابع را شفاف کنیم؟ بله!
چطور؟ به سادگی! با تغییر پارامترهای ورودی:
در مثال بالا، ما وابستگی به یک شیء سراسری را از بین بردیم.
صداقت یک تابع یعنی یک تابع باید همه اطلاعات مربوط به ورودیها و خروجیها را پوشش دهد. به این مثال دقت کنید:
آیا این تابع شفاف است؟ بله.
آیا این همه مواردی را که از آن انتظار داریم پوشش میدهد؟ احتمالا خیر!
اگر دو عدد صحیح را به این تابع بفرستیم، احتمالا مشکلی پیش نخواهد آمد. اما همانطور که حدس میزنید اگر پارامتر دوم 0 باشد چه اتفاقی خواهد افتاد؟
قطعا خطای Divide By Zero را خواهیم گرفت. امضای این تابع به ما اطلاعاتی درباره خطاهای احتمالی نمیدهد.
چگونه مشکل را حل کنیم؟ تایپ ورودی را به شکل زیر تغییر دهیم:
NonZeroInt یک نوع ورودی اختصاصی است که خودمان طراحی کردهایم که تمام مقادیر را به جز صفر، قبول میکند.
Functions as first-class values
ترجمه فارسی این کلمه ما را از معنی اصلی آن خیلی دور میکند؛ احتمالا یک ترجمه سادهی آم میتواند «تابع، ارزش اولیه کلاس» باشد!
وقتی توابع first-class values باشند، یعنی میتوانند به عنوان ورودی سایر توابع استفاده شوند، میتوانند به یک متغیر انتساب داده شوند، دقیقا مثل یک مقدار. برای مثال:
در این مثال، تابع، First-class value میباشد؛ چون شما میتوانید آن را به یک متغیر نسبت دهید و به عنوان ورودی به تابع بعدی بدهید. در مدل برنامه نویسی تابعی، تلقی شدن توابع به عنوان مقدار، ضروری است. چون به ما امکان تعریف توابع High-Order را میدهد.
توابع مرتبه بالا! یک یا چند تابع را به عنوان ورودی میگیرند و یک تابع را به عنوان نتیجه بر میگرداند. در مثال بالا Extension Method ، Where یک تابع High-Order میباشد.
پیاده سازی Where احتمالا به شکل زیر میباشد:
1. وظیفه چرخیدن روی آیتمهای لیست، مربوط به Where میباشد.
2. ملاک تشخیص اینکه چه آیتمهایی در لیست باید وجود داشته باشند، به عهده متدی میباشد که آن را فراخوانی میکند.
در این مثال، تابع Where، تابع ورودی را به ازای هر المان، در لیست فراخوانی میکند. این تابع میتواند طوری طراحی شود که تابع ورودی را به صورت شرطی اعمال کند. آزمایش این حالت به عهده شما میباشد. اما به صورت کلی انتظار میرود که قدرت توابع High-Order را درک کرده باشید.
در ادامه این سری مقالات، به پیاده سازیها و الگوهای رایج برنامه نویسی تابعی با #C بیشتر خواهیم پرداخت.
این قسمت از مقاله به ایده اصلی برنامه نویسی تابعی و دلیل وجودی آن خواهد پرداخت. هیچ شکی نیست که بزرگترین چالش در توسعه نرم افزارهای بزرگ، پیچیدگی آن است. تغییرات همیش اجتناب ناپذیر هستند. به خصوص زمانی که صحبت از پیاده سازی امکان جدیدی باشد، پیچیدگی اضافه خواهد شد. در نتیجه منجر به سخت شدن فهمیدن کد میشود، زمان توسعه را بالاتر میبرد و باگهای ناخواسته را به وجود خواهد آورد. همچنین تغییر هر چیزی در دنیای نرم افزار بدون به وجود آوردن رفتارهای ناخواسته و یا اثرات جانبی، تقریبا غیر ممکن است. در نهایت همه این موارد میتوانند سرعت توسعه را پایین برده و حتی باعث شکست پروژههای نرم افزاری شوند. سبکهای کد نویسی دستوری (Imperative) مانند برنامه نویسی شیء گرا، میتوانند به کاهش این پیچیدگیها تا حد خوبی کمک کنند. البته در صورتیکه به طور صحیحی پیاده شوند. در واقع با ایجاد Abstraction در این مدل برنامه نویسی، پیچیدگیها را مخفی میکنیم.
سیر تکاملی الگوهای برنامه نویسی
برنامه نویسی شیء گرا در خون برنامه نویسهای سی شارپ جاری است؛ ما معمولا ساعتها درباره اینکه چگونه میتوانیم با استفاده از ارث بری و ترتیب پیاده کلاسها، یک هدف خاص برسیم، بر روی کپسوله سازی تمرکز میکنیم و انتزاع (Abstraction) و چند ریختی ( Polymorphism ) را برای تغییر وضعیت برنامه استفاده میکنیم. در این مدل همیشه احتمال این وجود دارد که چند ترد به صورت همزمان به یک ناحیه از حافظه دسترسی داشته باشند و تغییری در آن به وجود بیاورند و باعث به وجود آمدن شرایط Race Condition شوند. البته همگی به خوبی میدانیم که میتوانیم یک برنامهی کاملا Thread-Safe هم داشته باشیم که به خوبی مباحث همزمانی و همروندی را مدیریت کند؛ اما یک مساله اساسی در مورد کارآیی باقی میماند. گرچه Parallelism به ما کمک میکند که کارآیی برنامه خود را افزایش دهیم، اما refactor کردن کدهای موجود، به حالت موازی، کاری سخت و پردردسر خواهد بود.
راهکار چیست؟
برنامه نویسی تابعی، یک الگوی برنامه نویسی است که از یک ایده قدیمی (قبل از اولین کامپیوترها !) برگرفته شدهاست؛ زمانیکه دو ریاضیدان، یک تئوری به نام lambda calculus را معرفی کردند، که یک چارچوب محاسباتی میباشد؛ عملیاتی ریاضی را انجام میدهد و نتیجه را محاسبه میکند، بدون اینکه تغییری را در وضعیت دادهها و وضعیت، به وجود بیاورد. با این کار، فهمیدن کدها آسانتر خواهد بود و اثرات جانبی را کمتر خواهد کرد، همچین نوشتن تستها سادهتر خواهند شد.
زبانهای تابعی
جالب است اگر زبانهای برنامه نویسی را که از برنامه نویسی تابعی پشتیبانی میکنند، بررسی کنیم، مانند Lisp , Clojure, Erlang, Haskel، هر کدام از این زبانها جنبههای مختلفی از برنامه نویسی تابعی را پوشش میدهند. #F یک عضو از خانواده ML میباشد که بر روی دات نت فریمورک در سال 2002 پیاده سازی شده. ولی جالب است بدانید بیشتر زبانهای همه کاره مانند #C به اندازه کافی انعطاف پذیر هستند تا بتوان الگوهای مختلفی را توسط آنها پیاده کرد. از آنجایی که اکثرا ما از #C برای توسعه نرم افزارهایمان استفاده میکنیم، ترکیب ایدههای برنامه نویسی تابعی میتواند راهکار جالبی برای حل مشکلات ما باشد.
مفاهیم پایه ای
قبلا درباره توابع ریاضی صحت کردیم. در زبانهای برنامه نویسی هم ایده همان است؛ ورودیهای مشخص و خروجی مورد انتظار، بدون تغییری در حالت برنامه. به این مفاهیم شفافیت و صداقت توابع میگوییم که در ادامه با آن بیشتر آشنا میشویم. به این نکته توجه داشته باشید که منظور از تابع در #C فقط Method نیست؛ Func , Action , Delegate هم نوعی تابع هستند.
شفافیت توابع (Referential Transparency)
به طور ساده با نگاه کردن به ورودیهای تابع و نام آنها باید بتوانیم کاری را که انجام میدهد، حدس بزنیم. یعنی یک تابع باید بر اساس ورودیهای آن کاری را انجام دهد و نباید یک پارامتر Global آن را تحت تاثیر قرار دهد. پارامترهای Global میتوانند یک Property در سطح یک کلاس باشند، یا یک شیء که وضعیت آن تحت کنترل تابع نیست؛ مانند شی DateTime. به مثال زیر توجه کنید:
public int CalculateElapsedDays(DateTime from) { DateTime now = DateTime.Now; return (now - from).Days; }
آیا میتوانید این تابع را شفاف کنیم؟ بله!
چطور؟ به سادگی! با تغییر پارامترهای ورودی:
public static int CalculateElapsedDays(DateTime from, DateTime now) => (now - from).Days;
صداقت توابع (Function Honesty)
صداقت یک تابع یعنی یک تابع باید همه اطلاعات مربوط به ورودیها و خروجیها را پوشش دهد. به این مثال دقت کنید:
public int Divide(int numerator, int denominator) { return numerator / denominator; }
آیا این همه مواردی را که از آن انتظار داریم پوشش میدهد؟ احتمالا خیر!
اگر دو عدد صحیح را به این تابع بفرستیم، احتمالا مشکلی پیش نخواهد آمد. اما همانطور که حدس میزنید اگر پارامتر دوم 0 باشد چه اتفاقی خواهد افتاد؟
var result = Divide(1,0);
چگونه مشکل را حل کنیم؟ تایپ ورودی را به شکل زیر تغییر دهیم:
public static int Divide(int numerator, NonZeroInt denominator) { return numerator / denominator.Value; }
به طور کلی تمرین زیادی لازم داریم تا بتوانیم با این مفاهیم به طور عمیق آشنا شویم. در این مقاله قصد دارم جنبههای ابتدایی برنامه نویسی تابعی مانند Functions as first class values ، High Order Functions و Pure Functions را مورد بررسی قرار دهم.
Functions as first-class values
ترجمه فارسی این کلمه ما را از معنی اصلی آن خیلی دور میکند؛ احتمالا یک ترجمه سادهی آم میتواند «تابع، ارزش اولیه کلاس» باشد!
وقتی توابع first-class values باشند، یعنی میتوانند به عنوان ورودی سایر توابع استفاده شوند، میتوانند به یک متغیر انتساب داده شوند، دقیقا مثل یک مقدار. برای مثال:
Func<int, bool> isMod2 = x => x % 2 == 0; var list = Enumerable.Range(1, 10); var evenNumbers = list.Where(isMod2);
High-Order Functions (HOF)
توابع مرتبه بالا! یک یا چند تابع را به عنوان ورودی میگیرند و یک تابع را به عنوان نتیجه بر میگرداند. در مثال بالا Extension Method ، Where یک تابع High-Order میباشد.
پیاده سازی Where احتمالا به شکل زیر میباشد:
public static IEnumerable<T> Where<T>(this IEnumerable<T> ts, Func<T, bool> predicate) { foreach (T t in ts) if (predicate(t)) yield return t; }
2. ملاک تشخیص اینکه چه آیتمهایی در لیست باید وجود داشته باشند، به عهده متدی میباشد که آن را فراخوانی میکند.
در این مثال، تابع Where، تابع ورودی را به ازای هر المان، در لیست فراخوانی میکند. این تابع میتواند طوری طراحی شود که تابع ورودی را به صورت شرطی اعمال کند. آزمایش این حالت به عهده شما میباشد. اما به صورت کلی انتظار میرود که قدرت توابع High-Order را درک کرده باشید.
Pure Functions
توابع خالص در واقع توابع ریاضی هستند که دو مفهوم ابتدایی که قبلا درباره آنها صحبت کردیم را دنبال میکنند؛ شفافیت و صداقت توابع. توابع خالص نباید هیچوقت اثر جانبی (side effect) ای داشته باشند. این یعنی نباید یک global state را تغییر دهند و یا از آنها به عنوان پارامتر ورودی استفاده کنند. توابع خالص به راحتی قابل تست شدن هستند. چون به ازای یک ورودی، یک خروجی ثابت را بر میگردانند. ترتیب محاسبات اهمیتی ندارد! اینها بازیگران اصلی یک برنامه تابعی میباشد که میتوانند برای اجرای موازی، محاسبه متاخر ( Lazy Evaluation ) و کش کردن ( memoization ) استفاده شوند.
یه سری دستورات هستند که EF معادلی براشون توی SQL نداره به طور مثال EF نمیدونه که متد Parse رو در SQL به چی تبدیل کنه،به طور مثال کد زیر :
var query = (from list in dbContext.Packages where list.Id == Int32.Parse(Request["Id"].ToString()) select list).FirstOrDefault();
باید به صورت زیر تغییر بدیم :
Int32 ID = Int32.Parse(Request["Id"].ToString()); var query = (from list in dbContext.Packages where list.Id == ID select list).FirstOrDefault();
به نظرتون توی نسخههای بعد این مشکلات رو برطرف میکنن؟
نظرات مطالب
EF Code First #5
آقای نصیری با سلام. من هر وقت برای بروزرسانی دیتابیس دستور Add-migration را در Package manager console وارد میکنیم ، همیشه در اسکریپت ایجاد شده من جدول reportparameter هم وجود دارد ، در حالیکه اصلاً تغییری در آن ایجاد نکردم.
در بالا فقط یک ستون به جدول classes ایجاد کردم ولی همیشه برای جدول reportParameter که در جدول نیز وجود دارد هم اسکریپت ایجاد میکند.
namespace Dal.Ef.Migrations { using System; using System.Data.Entity.Migrations; public partial class AddActiveColumnToClassesTable : DbMigration { public override void Up() { CreateTable( "dbo.ReportParameters", c => new { Id = c.Int(nullable: false, identity: true), CenterCode = c.String(maxLength: 10), CenterTitle = c.String(maxLength: 100), TermCode = c.String(maxLength: 10), TermTitle = c.String(maxLength: 100), MasulBarnamerizi = c.String(maxLength: 100), ModirAmuzesh = c.String(maxLength: 100), Term_Id = c.Int(nullable: false), Center_Id = c.Int(nullable: false), }) .PrimaryKey(t => t.Id) .ForeignKey("dbo.Terms", t => t.Term_Id, cascadeDelete: true) .ForeignKey("dbo.Centers", t => t.Center_Id, cascadeDelete: true) .Index(t => t.Term_Id) .Index(t => t.Center_Id); AddColumn("dbo.Classes", "IsActive", c => c.Boolean(nullable: false)); } public override void Down() { DropIndex("dbo.ReportParameters", new[] { "Center_Id" }); DropIndex("dbo.ReportParameters", new[] { "Term_Id" }); DropForeignKey("dbo.ReportParameters", "Center_Id", "dbo.Centers"); DropForeignKey("dbo.ReportParameters", "Term_Id", "dbo.Terms"); DropColumn("dbo.Classes", "IsActive"); DropTable("dbo.ReportParameters"); } } }
البته من یکبار بعد از آنکه جدول reportParameter را ایجاد کرده بودم ، دستی آن را از دیتابیس حذف کرده بودم.
متشکرم.
Graph extensions in SQL Server 2017 will facilitate users in linking different pieces of connected data to help gather powerful insights and increase operational agility. Graphs are well suited for applications where relationships are important, such as fraud detection, risk management, social networks, recommendation engines, predictive analysis, dependence analysis, and IoT applications. In this session we will demonstrate how you can use SQL Graph extensions to build your application using graph data.
همیشه فرض بر این است که مدیر سیستم، فردی است امین و درستکار. این شخص/اشخاص کارهای شبکه، پشتیبانگیری، نگهداری و امثال آنرا انجام داده و از سیستمها محافظت میکنند. اکنون این سناریوهای واقعی را درنظر بگیرید:
- پس از خداحافظی با شرکتی که در آن کار میکردی، شخصی با پوزخند به شما میگوید که «میدونستی در برنامهی حق و دستمزد شما، بچههای ادمین شبکه، دیتابیس برنامه رو مستقیما دستکاری میکردند و تعداد ساعات کاری بیشتری رو وارد میکردند»؟!
- مسئول فروشی/مسئول پذیرشی که یاد گرفته چطور به صورت مستقیم به بانک اطلاعاتی دسترسی پیدا کند و آمار فروش/پذیرش روز خودش را در بانک اطلاعاتی، با دستکاری مستقیم و خارج از برنامه، کمتر از مقدار واقعی نمایش دهد.
- باز هم مدیر سیستمی/شبکهای که دسترسی مستقیم به بانک اطلاعاتی دارد، در ساعاتی مشخص، کلمهی عبور هش شدهی خودش را مستقیما، بجای کلمهی عبور ادمین برنامه در بانک اطلاعاتی وارد کرده و پس از آن ...
این موارد متاسفانه واقعی هستند! اکنون سؤال اینجا است که آیا برنامهی شما قادر است تشخیص دهد رکوردهایی که هم اکنون در بانک اطلاعاتی ثبت شدهاند، واقعا توسط برنامه و تمام سطوح دسترسی که برای آن طراحی کردهاید، به این شکل درآمدهاند، یا اینکه توسط اشخاصی به صورت مستقیم و با دور زدن کامل برنامه، از طریق management studioهای مختلف، در سیستم وارد و دستکاری شدهاند؟! در ادامه راه حلی را برای بررسی این مشکل مهم، مرور خواهیم کرد.
چگونه تغییرات رکوردها را در بانکهای اطلاعاتی ردیابی کنیم؟
روش متداولی که برای بررسی تغییرات رکوردها مورد استفاده قرار میگیرد، هش کردن تمام اطلاعات یک ردیف از جدول است و سپس مقایسهی این هشها با هم. علت استفادهی از الگوریتمهای هش نیز، حداقل به دو علت است:
- با تغییر حتی یک بیت از اطلاعات، مقدار هش تولید شده تغییر میکند.
- طول نهایی مقدار هش شدهی اطلاعاتی حجیم، بسیار کم است و به راحتی توسط بانکهای اطلاعاتی، قابل مدیریت و جستجو است.
اگر از SQL Server استفاده میکنید، یک چنین قابلیتی را به صورت توکار به همراه دارد:
با این خروجی
کاری که این کوئری انجام میدهد شامل دو مرحله است:
الف) کوئری "SELECT top 1 * FROM [AppUsers] FOR XML auto" کاری شبیه به serialization را انجام میدهد. همانطور که مشاهده میکنید، نام و مقادیر تمام فیلدهای یک ردیف را به صورت یک خروجی XML در میآورد. بنابراین دیگر نیازی نیست تا کار تبدیل مقادیر تمام ستونهای یک ردیف را به عبارتی قابل هش، به صورت دستی انجام دهیم؛ رشتهی XML ای آن هم اکنون آمادهاست.
ب) متد HASHBYTES، این خروجی serialized را با الگوریتم SHA2_256، هش میکند. الگوریتمهای SHA2_256 و همچنین SHA2_512، از سال 2012 به بعد به SQL Server اضافه شدهاند.
اکنون اگر این هش را به نحوی ذخیره کنیم (برنامه باید این هش را ذخیره و یا به روز رسانی کند) و سپس شخصی به صورت مستقیم ردیف فوق را در بانک اطلاعاتی تغییر دهد، هش جدید این ردیف، با هش قبلی ذخیره شدهی توسط برنامه، یکی نخواهد بود که بیانگر دستکاری مستقیم این ردیف، خارج از برنامه و با دور زدن کامل تمام سطوح دسترسی آن است.
چگونه تغییرات رکوردها را در بانکهای اطلاعاتی، توسط EF Core ردیابی کنیم؟
مزیت روش فوق، توکار بودن آن است که کارآیی فوق العادهای را نیز به همراه دارد. اما چون در ادامه قصد داریم از یک ORM استفاده کنیم و ORMها نیز قرار است توانایی کار کردن با انواع و اقسام بانکهای اطلاعاتی را داشته باشند، دو مرحلهی serialization و هش کردن را در کدهای برنامه و با مدیریت EF Core، مستقل از بانک اطلاعاتی خاصی، انجام خواهیم داد.
معرفی موجودیتهای برنامه
در مثالی که بررسی خواهیم کرد، دو موجودیت Blog و Post تعریف شدهاند:
- در اینجا اینترفیس IAuditableEntity را نیز مشاهده میکنید که دارای یک خاصیت Hash است. تمام موجودیتهایی که قرار است دارای فیلد هش باشند، نیاز است این اینترفیس را پیاده سازی کنند؛ مانند دو موجودیت Blog و Post. در ادامه مقدار خاصیت هش را به صورت خودکار توسط سیستم Tracking، محاسبه و به روز رسانی میکنیم.
- به علاوه جهت تکمیل بحث، دو خاصیت سایهای نیز تعریف شدهاند تا بررسی کنیم که آیا هش اینها نیز درست محاسبه میشود یا خیر.
- علت اینکه خاصیت Hash، سایهای تعریف نشد، سهولت دسترسی و بالا بردن کارآیی آن بود.
معرفی ظرفی برای نگهداری نام خواص و مقادیر متناظر با یک موجودیت
در ادامه دو کلاس AuditEntry و AuditProperty را مشاهده میکنید:
زمانیکه توسط سیستم Tracking، موجودیتهای اضافه شده و یا ویرایش شده را استخراج میکنیم، AuditEntry همان موجودیت در حال بررسی است که دارای تعدادی خاصیت یا AuditProperty میباشد. اینها را توسط دو کلاس فوق برای عملیات بعدی، ذخیره و نگهداری میکنیم.
معرفی روشی برای هش کردن مقادیر یک شیء
زمانیکه توسط سیستم Tracking، در حال کاربر بر روی موجودیتهای اضافه شده و یا ویرایش شده هستیم، میخواهیم فیلد هش آنها را نیز به صورت خودکار ویرایش و مقدار دهی کنیم. کلاس زیر، منطق ارائه دهندهی این مقدار هش را بیان میکند:
- در اینجا توسط متد JsonConvert.SerializeObject کتابخانهی Newtonsoft.Json، شیء موجودیت را تبدیل به یک رشتهی JSON کرده و توسط الگوریتم SHA256 هش میکنیم. در آخر هم این مقدار را به صورت Base64 ارائه میدهیم.
- نکتهی مهم: ما نمیخواهیم تمام خواص یک موجودیت را هش کنیم. برای مثال اگر موجودیتی دارای چندین رابطه با جداول دیگری بود، ما مقادیر اینها را هش نمیکنیم (چون رکوردهای متناظر با آنها در جداول خودشان میتوانند دارای فیلد هش مخصوصی باشند). بنابراین یک Dictionary را از خواص و مقادیر متناظر با آنها تشکیل داده و این Dictionary را تبدیل به JSON میکنیم.
- همچنین در این بین، مقدار خود فیلد Hash یک شیء نیز نباید در هش محاسبه شده، حضور داشته باشد. به همین جهت پارامتر propertyToIgnore را مشاهده میکنید.
معرفی Context برنامه که کار هش کردن خودکار موجودیتها را انجام میدهد
اکنون نوبت استفاده از تنظیمات انجام شدهی تا این مرحلهاست:
در اینجا اصل کار، در متد بازنویسی شدهی SaveChanges انجام میشود:
در متد OnBeforeSaveChanges، تمام موجودیتهای تغییر کردهی از نوع IAuditableEntity را که دارای فیلد هش هستند، یافته و نام خاصیت و مقدار متناظر با آنها را در ظرفهای AuditEntry که پیشتر معرفی شدند، ذخیره میکنیم. هنوز در این مرحله کار هش کردن را انجام نخواهیم داد. علت را میتوانید در بررسی خواص موقتی مشاهده کنید:
خواص موقتی، عموما تولید شدهی توسط دیتابیس هستند. برای مثال زمانیکه یک Id عددی خود افزاینده را به عنوان کلید اصلی جدول معرفی میکنید، مقدار آن پس از فراخوانی متد base.SaveChanges، از بانک اطلاعاتی دریافت شده و در اختیار برنامه قرار میگیرد. به همین جهت است که نیاز داریم لیست این خواص و مقادیر را یکبار پیش از base.SaveChanges ذخیره کنیم و پس از آن، خواص موقتی را که اکنون دارای مقدار هستند، مقدار دهی کرده و سپس هش نهایی شیء را محاسبه کنیم. اگر پیش از base.SaveChanges این هش را محاسبه کنیم، برای مثال حاوی مقدار Id شیء، نخواهد بود.
همین مقدار تنظیم، برای محاسبه و به روز رسانی خودکار فیلد هش، کفایت میکند.
روش بررسی اصالت یک موجودیت
در متد زیر، روش محاسبهی هش واقعی یک موجودیت دریافت شدهی از بانک اطلاعاتی را توسط متد الحاقی GenerateEntityHash مشاهده میکنید. اگر این هش واقعی (بر اساس مقادیر فعلی این ردیف که حتی ممکن است به صورت دستی و خارج از برنامه تغییر کرده باشد)، با مقدار Hash ثبت شدهی پیشین در آن ردیف یکی بود، اصالت این ردیف تائید خواهد شد:
یک نمونه خروجی آن به صورت زیر است:
اکنون بانک اطلاعاتی را خارج از برنامه، مستقیما دستکاری میکنیم و برای مثال Url اولین ردیف را تغییر میدهیم:
در ادامه یکبار دیگر برنامه را اجرا خواهیم کرد:
همانطور که مشاهده میکنید، هش واقعی جدید، با هش ثبت شدهی در ردیف، یکی نیست؛ که بیانگر ویرایش مستقیم این ردیف میباشد.
به علاوه باید درنظر داشت، محاسبهی این هش بدون خود برنامه، کار سادهای نیست. به همین جهت به روز رسانی دستی آن تقریبا غیرممکن است؛ خصوصا اگر متد GenerateObjectHash، کمی با پیچ و تاب بیشتری نیز تهیه شود.
چگونه وضعیت اصالت تعدادی ردیف را بررسی کنیم؟
مثال قبل، در مورد روش بررسی اصالت یک تک ردیف بود. کوئری زیر روش محاسبهی فیلد جدید IsAuthentic را در بین لیستی از ردیفها نمایش میدهد:
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید: EFCoreRowIntegrity.zip
- پس از خداحافظی با شرکتی که در آن کار میکردی، شخصی با پوزخند به شما میگوید که «میدونستی در برنامهی حق و دستمزد شما، بچههای ادمین شبکه، دیتابیس برنامه رو مستقیما دستکاری میکردند و تعداد ساعات کاری بیشتری رو وارد میکردند»؟!
- مسئول فروشی/مسئول پذیرشی که یاد گرفته چطور به صورت مستقیم به بانک اطلاعاتی دسترسی پیدا کند و آمار فروش/پذیرش روز خودش را در بانک اطلاعاتی، با دستکاری مستقیم و خارج از برنامه، کمتر از مقدار واقعی نمایش دهد.
- باز هم مدیر سیستمی/شبکهای که دسترسی مستقیم به بانک اطلاعاتی دارد، در ساعاتی مشخص، کلمهی عبور هش شدهی خودش را مستقیما، بجای کلمهی عبور ادمین برنامه در بانک اطلاعاتی وارد کرده و پس از آن ...
این موارد متاسفانه واقعی هستند! اکنون سؤال اینجا است که آیا برنامهی شما قادر است تشخیص دهد رکوردهایی که هم اکنون در بانک اطلاعاتی ثبت شدهاند، واقعا توسط برنامه و تمام سطوح دسترسی که برای آن طراحی کردهاید، به این شکل درآمدهاند، یا اینکه توسط اشخاصی به صورت مستقیم و با دور زدن کامل برنامه، از طریق management studioهای مختلف، در سیستم وارد و دستکاری شدهاند؟! در ادامه راه حلی را برای بررسی این مشکل مهم، مرور خواهیم کرد.
چگونه تغییرات رکوردها را در بانکهای اطلاعاتی ردیابی کنیم؟
روش متداولی که برای بررسی تغییرات رکوردها مورد استفاده قرار میگیرد، هش کردن تمام اطلاعات یک ردیف از جدول است و سپس مقایسهی این هشها با هم. علت استفادهی از الگوریتمهای هش نیز، حداقل به دو علت است:
- با تغییر حتی یک بیت از اطلاعات، مقدار هش تولید شده تغییر میکند.
- طول نهایی مقدار هش شدهی اطلاعاتی حجیم، بسیار کم است و به راحتی توسط بانکهای اطلاعاتی، قابل مدیریت و جستجو است.
اگر از SQL Server استفاده میکنید، یک چنین قابلیتی را به صورت توکار به همراه دارد:
SELECT [Id], (SELECT top 1 * FROM [AppUsers] FOR XML auto), HASHBYTES ('SHA2_256', (SELECT top 1 * FROM [AppUsers] FOR XML auto)) AS [hash] -- varbinary(n), since 2012 FROM [AppUsers]
کاری که این کوئری انجام میدهد شامل دو مرحله است:
الف) کوئری "SELECT top 1 * FROM [AppUsers] FOR XML auto" کاری شبیه به serialization را انجام میدهد. همانطور که مشاهده میکنید، نام و مقادیر تمام فیلدهای یک ردیف را به صورت یک خروجی XML در میآورد. بنابراین دیگر نیازی نیست تا کار تبدیل مقادیر تمام ستونهای یک ردیف را به عبارتی قابل هش، به صورت دستی انجام دهیم؛ رشتهی XML ای آن هم اکنون آمادهاست.
ب) متد HASHBYTES، این خروجی serialized را با الگوریتم SHA2_256، هش میکند. الگوریتمهای SHA2_256 و همچنین SHA2_512، از سال 2012 به بعد به SQL Server اضافه شدهاند.
اکنون اگر این هش را به نحوی ذخیره کنیم (برنامه باید این هش را ذخیره و یا به روز رسانی کند) و سپس شخصی به صورت مستقیم ردیف فوق را در بانک اطلاعاتی تغییر دهد، هش جدید این ردیف، با هش قبلی ذخیره شدهی توسط برنامه، یکی نخواهد بود که بیانگر دستکاری مستقیم این ردیف، خارج از برنامه و با دور زدن کامل تمام سطوح دسترسی آن است.
چگونه تغییرات رکوردها را در بانکهای اطلاعاتی، توسط EF Core ردیابی کنیم؟
مزیت روش فوق، توکار بودن آن است که کارآیی فوق العادهای را نیز به همراه دارد. اما چون در ادامه قصد داریم از یک ORM استفاده کنیم و ORMها نیز قرار است توانایی کار کردن با انواع و اقسام بانکهای اطلاعاتی را داشته باشند، دو مرحلهی serialization و هش کردن را در کدهای برنامه و با مدیریت EF Core، مستقل از بانک اطلاعاتی خاصی، انجام خواهیم داد.
معرفی موجودیتهای برنامه
در مثالی که بررسی خواهیم کرد، دو موجودیت Blog و Post تعریف شدهاند:
using System.Collections.Generic; namespace EFCoreRowIntegrity { public interface IAuditableEntity { string Hash { set; get; } } public static class AuditableShadowProperties { public static readonly string CreatedDateTime = nameof(CreatedDateTime); public static readonly string ModifiedDateTime = nameof(ModifiedDateTime); } public class Blog : IAuditableEntity { public int BlogId { get; set; } public string Url { get; set; } public List<Post> Posts { get; set; } public string Hash { get; set; } } public class Post : IAuditableEntity { public int PostId { get; set; } public string Title { get; set; } public string Content { get; set; } public int BlogId { get; set; } public Blog Blog { get; set; } public string Hash { get; set; } } }
- به علاوه جهت تکمیل بحث، دو خاصیت سایهای نیز تعریف شدهاند تا بررسی کنیم که آیا هش اینها نیز درست محاسبه میشود یا خیر.
- علت اینکه خاصیت Hash، سایهای تعریف نشد، سهولت دسترسی و بالا بردن کارآیی آن بود.
معرفی ظرفی برای نگهداری نام خواص و مقادیر متناظر با یک موجودیت
در ادامه دو کلاس AuditEntry و AuditProperty را مشاهده میکنید:
using System.Collections.Generic; using Microsoft.EntityFrameworkCore.ChangeTracking; namespace EFCoreRowIntegrity { public class AuditEntry { public EntityEntry EntityEntry { set; get; } public IList<AuditProperty> AuditProperties { set; get; } = new List<AuditProperty>(); public AuditEntry() { } public AuditEntry(EntityEntry entry) { EntityEntry = entry; } } public class AuditProperty { public string Name { set; get; } public object Value { set; get; } public bool IsTemporary { set; get; } public PropertyEntry PropertyEntry { set; get; } public AuditProperty() { } public AuditProperty(string name, object value, bool isTemporary, PropertyEntry property) { Name = name; Value = value; IsTemporary = isTemporary; PropertyEntry = property; } } }
معرفی روشی برای هش کردن مقادیر یک شیء
زمانیکه توسط سیستم Tracking، در حال کاربر بر روی موجودیتهای اضافه شده و یا ویرایش شده هستیم، میخواهیم فیلد هش آنها را نیز به صورت خودکار ویرایش و مقدار دهی کنیم. کلاس زیر، منطق ارائه دهندهی این مقدار هش را بیان میکند:
using System; using System.Collections.Generic; using System.Security.Cryptography; using System.Text; using Microsoft.EntityFrameworkCore; using Microsoft.EntityFrameworkCore.ChangeTracking; using Newtonsoft.Json; namespace EFCoreRowIntegrity { public static class HashingExtensions { public static string GenerateObjectHash(this object @object) { if (@object == null) { return string.Empty; } var jsonData = JsonConvert.SerializeObject(@object, Formatting.Indented); using (var hashAlgorithm = new SHA256CryptoServiceProvider()) { var byteValue = Encoding.UTF8.GetBytes(jsonData); var byteHash = hashAlgorithm.ComputeHash(byteValue); return Convert.ToBase64String(byteHash); } } public static string GenerateEntityEntryHash(this EntityEntry entry, string propertyToIgnore) { var auditEntry = new Dictionary<string, object>(); foreach (var property in entry.Properties) { var propertyName = property.Metadata.Name; if (propertyName == propertyToIgnore) { continue; } auditEntry[propertyName] = property.CurrentValue; } return auditEntry.GenerateObjectHash(); } public static string GenerateEntityHash<TEntity>(this DbContext context, TEntity entity, string propertyToIgnore) { return context.Entry(entity).GenerateEntityEntryHash(propertyToIgnore); } } }
- نکتهی مهم: ما نمیخواهیم تمام خواص یک موجودیت را هش کنیم. برای مثال اگر موجودیتی دارای چندین رابطه با جداول دیگری بود، ما مقادیر اینها را هش نمیکنیم (چون رکوردهای متناظر با آنها در جداول خودشان میتوانند دارای فیلد هش مخصوصی باشند). بنابراین یک Dictionary را از خواص و مقادیر متناظر با آنها تشکیل داده و این Dictionary را تبدیل به JSON میکنیم.
- همچنین در این بین، مقدار خود فیلد Hash یک شیء نیز نباید در هش محاسبه شده، حضور داشته باشد. به همین جهت پارامتر propertyToIgnore را مشاهده میکنید.
معرفی Context برنامه که کار هش کردن خودکار موجودیتها را انجام میدهد
اکنون نوبت استفاده از تنظیمات انجام شدهی تا این مرحلهاست:
using System; using System.Collections.Generic; using System.IO; using System.Linq; using Microsoft.EntityFrameworkCore; using Microsoft.EntityFrameworkCore.ChangeTracking; using Microsoft.Extensions.Logging; namespace EFCoreRowIntegrity { public class BloggingContext : DbContext { public BloggingContext() { } public BloggingContext(DbContextOptions options) : base(options) { } public DbSet<Blog> Blogs { get; set; } public DbSet<Post> Posts { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { if (!optionsBuilder.IsConfigured) { optionsBuilder.EnableSensitiveDataLogging(); var path = Path.Combine(Directory.GetCurrentDirectory(), "app_data", "EFCore.RowIntegrity.mdf"); optionsBuilder.UseSqlServer($"Server=(localdb)\\mssqllocaldb;Database=EFCore.RowIntegrity;AttachDbFilename={path};Trusted_Connection=True;"); optionsBuilder.UseLoggerFactory(new LoggerFactory().AddConsole((message, logLevel) => logLevel == LogLevel.Debug && message.StartsWith("Microsoft.EntityFrameworkCore.Database.Command"))); } } protected override void OnModelCreating(ModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); foreach (var entityType in modelBuilder.Model .GetEntityTypes() .Where(e => typeof(IAuditableEntity) .IsAssignableFrom(e.ClrType))) { modelBuilder.Entity(entityType.ClrType) .Property<DateTimeOffset?>(AuditableShadowProperties.CreatedDateTime); modelBuilder.Entity(entityType.ClrType) .Property<DateTimeOffset?>(AuditableShadowProperties.ModifiedDateTime); } } public override int SaveChanges() { var auditEntries = OnBeforeSaveChanges(); var result = base.SaveChanges(); OnAfterSaveChanges(auditEntries); return result; } private IList<AuditEntry> OnBeforeSaveChanges() { var auditEntries = new List<AuditEntry>(); foreach (var entry in ChangeTracker.Entries<IAuditableEntity>()) { if (entry.State == EntityState.Detached || entry.State == EntityState.Unchanged) { continue; } var auditEntry = new AuditEntry(entry); auditEntries.Add(auditEntry); var now = DateTimeOffset.UtcNow; foreach (var property in entry.Properties) { var propertyName = property.Metadata.Name; if (propertyName == nameof(IAuditableEntity.Hash)) { continue; } if (property.IsTemporary) { // It's an auto-generated value and should be retrieved from the DB after calling the base.SaveChanges(). auditEntry.AuditProperties.Add(new AuditProperty(propertyName, null, true, property)); continue; } switch (entry.State) { case EntityState.Added: entry.Property(AuditableShadowProperties.CreatedDateTime).CurrentValue = now; auditEntry.AuditProperties.Add(new AuditProperty(propertyName, property.CurrentValue, false, property)); break; case EntityState.Modified: auditEntry.AuditProperties.Add(new AuditProperty(propertyName, property.CurrentValue, false, property)); entry.Property(AuditableShadowProperties.ModifiedDateTime).CurrentValue = now; break; } } } return auditEntries; } private void OnAfterSaveChanges(IList<AuditEntry> auditEntries) { foreach (var auditEntry in auditEntries) { foreach (var auditProperty in auditEntry.AuditProperties.Where(x => x.IsTemporary)) { // Now we have the auto-generated value from the DB. auditProperty.Value = auditProperty.PropertyEntry.CurrentValue; auditProperty.IsTemporary = false; } auditEntry.EntityEntry.Property(nameof(IAuditableEntity.Hash)).CurrentValue = auditEntry.AuditProperties.ToDictionary(x => x.Name, x => x.Value).GenerateObjectHash(); } base.SaveChanges(); } } }
public override int SaveChanges() { var auditEntries = OnBeforeSaveChanges(); var result = base.SaveChanges(); OnAfterSaveChanges(auditEntries); return result; }
if (property.IsTemporary) { // It's an auto-generated value and should be retrieved from the DB after calling the base.SaveChanges(). auditEntry.AuditProperties.Add(new AuditProperty(propertyName, null, true, property)); continue; }
همین مقدار تنظیم، برای محاسبه و به روز رسانی خودکار فیلد هش، کفایت میکند.
روش بررسی اصالت یک موجودیت
در متد زیر، روش محاسبهی هش واقعی یک موجودیت دریافت شدهی از بانک اطلاعاتی را توسط متد الحاقی GenerateEntityHash مشاهده میکنید. اگر این هش واقعی (بر اساس مقادیر فعلی این ردیف که حتی ممکن است به صورت دستی و خارج از برنامه تغییر کرده باشد)، با مقدار Hash ثبت شدهی پیشین در آن ردیف یکی بود، اصالت این ردیف تائید خواهد شد:
private static void CheckRow1IsAuthentic() { using (var context = new BloggingContext()) { var blog1 = context.Blogs.Single(x => x.BlogId == 1); var entityHash = context.GenerateEntityHash(blog1, propertyToIgnore: nameof(IAuditableEntity.Hash)); var dbRowHash = blog1.Hash; Console.WriteLine($"entityHash: {entityHash}\ndbRowHash: {dbRowHash}"); if (entityHash == dbRowHash) { Console.WriteLine("This row is authentic!"); } else { Console.WriteLine("This row is tampered outside of the application!"); } } }
entityHash: P110cYquWpoaZuTpCWaqBn6HPSGdoQdmaAN05s1zYqo= dbRowHash: P110cYquWpoaZuTpCWaqBn6HPSGdoQdmaAN05s1zYqo= This row is authentic!
اکنون بانک اطلاعاتی را خارج از برنامه، مستقیما دستکاری میکنیم و برای مثال Url اولین ردیف را تغییر میدهیم:
در ادامه یکبار دیگر برنامه را اجرا خواهیم کرد:
entityHash: tdiZhKMJRnROGLLam1WpldA0fy/CbjJaR2Y2jNU9izk= dbRowHash: P110cYquWpoaZuTpCWaqBn6HPSGdoQdmaAN05s1zYqo= This row is tampered outside of the application!
به علاوه باید درنظر داشت، محاسبهی این هش بدون خود برنامه، کار سادهای نیست. به همین جهت به روز رسانی دستی آن تقریبا غیرممکن است؛ خصوصا اگر متد GenerateObjectHash، کمی با پیچ و تاب بیشتری نیز تهیه شود.
چگونه وضعیت اصالت تعدادی ردیف را بررسی کنیم؟
مثال قبل، در مورد روش بررسی اصالت یک تک ردیف بود. کوئری زیر روش محاسبهی فیلد جدید IsAuthentic را در بین لیستی از ردیفها نمایش میدهد:
var blogs = (from blog in context.Blogs.ToList() // Note: this `ToList()` is necessary here for having Shadow properties values, otherwise they will considered `null`. let computedHash = context.GenerateEntityHash(blog, nameof(IAuditableEntity.Hash)) select new { blog.BlogId, blog.Url, RowHash = blog.Hash, ComputedHash = computedHash, IsAuthentic = blog.Hash == computedHash }).ToList();
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید: EFCoreRowIntegrity.zip