در اینجا هش توکنها ذخیره میشوند؛ در قسمت «الف) سرویس TokenStoreService
» و همچنین در متد TokenEndpointResponse که دسترسی به آن وجود دارد
(توضیحات انتهای قسمت «پیاده سازی قسمت لاگین و صدور access token »).
ذخیره سازی هش، هم جستجوی سریعی را به همراه خواهد داشت (چون طول آن کوتاه و
ثابت است و امکان تعریف ایندکس بر روی آن وجود دارد. به علاوه موارد منقضی
شده هم حذف میشوند از بانک اطلاعاتی) و هم نیازی به ذخیرهی اطلاعات
اضافهتری در توکن نهایی ندارد و حجم آنرا افزایش نمیدهد و چون در اختیار
کاربر نیست، حتی در صورت افشای کلیدهای سمت سرور، قابل تولید در سمت
کلاینت نیست. همچنین بحث تعیین اعتبار توکنها صرفا مرتبط با تائید محل
صدور آنها نیست. در سرویس TokenStoreService، وضعیت فعال بودن یا
نبودن کاربر، تغییر سطح دسترسیها، تغییر اطلاعات پروفایل او و همچنین
عملیات خروج از سیستم او و فاقد اعتبارشدن توکن آن جلسهی کاری نیز بررسی
میشوند.
تصادف برای یک راننده حتی در صورت داشتن بیمه نامهای معتبر، گران تمام خواهد شد (از لحاظ جانی/مادی/...). بنابراین صرف نظر از اینکه شرکت بیمه کننده چه میزان از خسارت راننده را جبران خواهد کرد، باید تا حد ممکن از تصادفات بر حذر بود (defensive driving).
در برنامه نویسی، استثناءها (Exceptions) مانند تصادفات هستند و مدیریت استثناءها (exception handling)، همانند بیمه خودرو میباشند. هر چند مدیریت استثناءها جهت بازگردان برنامه شما به ادامه مسیر مهم هستند، اما جایگزین خوبی برای Defensive programming به شمار نمیروند. استثناءها و مدیریت آنها برای برنامه گران تمام میشوند (خصوصا از لحاظ میزان مصرف منابع سیستمی و سربارهای مربوطه). بنابراین در برنامه باید توجه خاصی را به این موضوع معطوف داشت که چه زمانی، چگونه و در کجا ممکن است استثنائی رخ دهد و علاج واقعه را پیش از وقوع آن نمود.
اصل اول Defensive programming : همیشه ورودی دریافتی را تعیین اعتبار کنید
به مثال زیر دقت بفرمائید:
public void LogEntry(string msg)
{
string path = GetPathToLog();
using (StreamWriter writer = File.AppendText(path))
{
writer.WriteLine(DateTime.Now.ToString(CultureInfo.InstalledUICulture));
writer.WriteLine("Entry: {0}", msg);
writer.WriteLine("--------------------");
}
}
قرار هست رخدادهای برنامه را توسط این متد، لاگ کنیم. اکنون لحظهای دقت نمائید که این تابع در چه مواقعی ممکن است دچار مشکل شود:
path میتواند یک رشته خالی باشد.
path میتواند نال باشد.
path میتواند حاوی کاراکترهای غیرمجازی باشد.
path میتواند فرمت نادرستی داشته باشد.
path میتواند به محلی ناصحیح اشاره نماید.
path میتواند اصلا وجود نداشته باشد.
فایل مورد نظر ممکن است readonly باشد.
برنامه ممکن است دسترسی لازم را برای نوشتن در مسیر ذکر شده، نداشته باشد.
فایل مورد نظر ممکن است توسط پروسهای دیگر قفل شده باشد.
ممکن است در لحظه نوشتن یا خواندن بر روی فایل، هارد دیسک دچار مشکل گردد.
و ...
رخ دادن هر کدام از موارد ذکر شد منجر به بروز یک استثناء خواهد شد.
چگونه این وضعیت را بهبود بخشیم؟
فرض کنید متد GetPathToLog قرار است مسیر ذخیره سازی لاگها را از کاربر در یک برنامه ASP.Net دریافت کند. برای این منظور باید حداقل دو مورد را منظور کرد.
<asp:TextBox ID="txtPath" runat="server" MaxLength="248" />
<asp:RequiredFieldValidator ID="reqval_txtPath" runat="server" ControlToValidate="txtPath" ErrorMessage="Path is required." />
<asp:RegularExpressionValidator ID="regex_txtPath" runat="server" ControlToValidate="txtPath" ErrorMessage="Path is invalid." ValidationExpression='^([a-zA-Z]\:)(\\{1}|((\\{1})[^\\]([^/:*?<>”|]*(?<![ ])))+)$' />
برای تکست باکس ارائه شده، ابتدا یک RequiredFieldValidator در نظر گرفته شده تا مطمئن شویم که کاربر حتما مقداری را وارد خواهد کرد. اما این کافی نیست. سپس با استفاده از عبارات باقاعده و RegularExpressionValidator بررسی خواهیم کرد که آیا فرمت ورودی صحیح است یا خیر.
تا اینجا 4 مورد اول مشکلاتی که ممکن است رخ دهند (موارد ذکر شده فوق)، کنترل میشوند بدون اینکه احتمال رخ دادن این استثناءها در برنامه وجود داشته باشد. Defensive programming به این معنا است که طراحی برنامه باید به گونهای باشد که در اثر استفادهی غیر قابل پیش بینی از آن، در عملکرد برنامه اختلالی رخ ندهد.
با فرض فعال سازی و ثبت PersianDateModelBinder، این خطا زمانی حاصل میشود که یک فیلد datetime مقدار دهی نشده را بخواهید در بانک اطلاعاتی ذخیره کنید. نوع datetime در دات نت value type است و مقدار پیش فرض آن 0001-01-01 است (DateTime.MinValue) که قابل ذخیره سازی در بانک اطلاعاتی نیست. یا فیلد را nullable تعریف کنید (هم در سمت کدها و هم در سمت بانک اطلاعاتی) و یا حتما هنگام ذخیره سازی اطلاعات، آنرا مقدار دهی کنید تا مقدار پیش فرض خود را نداشته باشد.
همانطور که در قسمت اول این سری نیز عنوان شد، انجام عملیات Reflection عموما به همراه سربار محاسبهی هربارهی اطلاعات مورد نیاز آن است و اکنون میتوان یک چنین محاسباتی را توسط Source generators، در زمان کامپایل برنامه، تامین و جزئی از خروجی نهایی کامپل شدهی آن کرد تا کارآیی برنامه به شدت افزایش یابد. یک نمونه مثال آن، استفاده از ویژگی Display بر روی عناصر یک enum است تا بتوان توضیحات بیشتری را جهت نمایش در UI، ارائه داد:
روش متداول جهت دسترسی به اطلاعات ویژگی Display، استفاده از Reflection به صورت زیر است:
یعنی هرجائی که در برنامه نیاز باشد تا برای مثال نام نمایشی Gender.Female محاسبه شود، باید یکبار عملیات فوق در زمان اجرا، تکرار گردد با محاسبهی تمام ویژگیهای یک عنصر enum، بررسی وجود DisplayAttribute در این بین و در صورت وجود، محاسبهی مقدار خاصیت Name آن.
یعنی در اصل متد کمکی که برای اینکار نیاز داریم، چنین خروجی را دارد:
مزیت این روش نسبت به Reflection، از پیش محاسبه شده بودن و سرعت بالای کار با آن است؛ اما ... باید به ازای هر enum نوشته شده، یکبار به صورت اختصاصی، تکرار شود و همچنین اگر اطلاعات enum متناظر با آن تغییر کرد، نیاز است تا این کلاسها و متدهای کمکی نیز اصلاح شوند. به همین جهت است که عموما کار با Reflection ترجیح داده میشود؛ چون حجم کدنویسی کمتری را به همراه دارد و همچنین میتواند انواع و اقسام enum را پوشش دهد و عمومی است.
با ارائهی Source Generators، مشکلات یاد شده دیگر وجود ندارند. یعنی کار تولید متدهای اختصاصی برای هر enum، خودکار است و همچنین به روز رسانی آنی آنها با هر تغییری در enumها نیز پیشبینی شدهاست.
تهیهی تولید کنندهی خودکار کدی که نام نمایشی enumها را به صورت از پیش محاسبه شده ارائه میدهد
در قسمت قبل، با روش تهیه و استفاده از Source Generators آشنا شدیم. در اینجا نیز از همان قالب، در جهت تولید کد متد الحاقی GetDisplayName فوق، استفاده خواهیم کرد. یعنی هدف رسیدن به کلاس GenderExtensions فوق و متد GetDisplayName آن، در زمان کامپایل برنامه و به صورت خودکار است:
کار را با ایجاد یک کلاس عمومی جدید که پیاده سازی کنندهی اینترفیس ISourceGenerator و مزین به ویژگی Generator است، شروع میکنیم. در مورد وابستگیهای مورد نیاز یک چنین پروژهای، در قسمت قبل توضیحات کافی ارائه شد.
در اینجا در متد Execute، دسترسی کاملی را به اطلاعات تهیه شدهی توسط کامپایلر داریم. توسط آن تمام Enumهای برنامه را یا همان EnumDeclarationSyntax را در اینجا، یافته و سپس حلقهای را بر روی اطلاعات آنها تشکیل داده و برای تک تک آنها، توسط متد GenerateEnumExtensions، کد معادل کلاس GenderExtensions را که در این مطلب معرفی شد، تولید میکنیم. در پایان کار نیز این کد را توسط متد AddSource، به کامپایلر معرفی خواهیم کرد تا بلافاصله در IDE ظاهر شده و قابلیت استفاده را پیدا کند.
یک نکته: اگر میخواهید صرفا enumهای خاصی در این بین بررسی شوند، میتوانید کدهای یک Attribute سفارشی را مثلا با نام فرضی [GenerateExtensions] در همینجا توسط متد context.AddSource به مجموعه سورسها اضافه کنید و سپس بر اساس نام آن، در قسمت Where ایی که کامنت شدهاست، تنها اطلاعات مدنظر را فیلتر و پردازش کنید.
متدی هم که ابتدا کلاس Extensions را بر اساس نام هر Enum موجود تولید و سپس بدنهی متد GetDisplayName اختصاصی آنرا تکمیل میکند، به صورت زیر است:
در مورد روش استفادهی از این source generator نیز در قسمت قبل بحث شد و فقط کافی است ارجاعی را به اسمبلی آن به پروژهی مدنظر افزود و OutputItemType را به آنالایزر تنظیم کرد.
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید: SourceGeneratorTests-part3.zip
سؤال: چگونه میتوان کدهای تولید شدهی توسط یک Source Generator را ذخیره کرد؟
Source Generators به صورت پیشفرض هیچ فایلی را بر روی دیسک سخت ذخیره نمیکنند و تمام عملیات آنها در حافظه انجام میشود. اگر علاقمند به مطالعهی این خروجیهای خودکار، به صورت فایلهای واقعی هستید، نیاز به انجام تغییرات زیر در فایل csproj پروژهی مصرف کنندهی Source Generator است:
توضیحات:
- EmitCompilerGeneratedFiles سبب ثبت فایلهای خودکار تولید شده، بر روی دیسک سخت میشود که قالب مسیر پیشفرض ذخیره سازی آن به صورت زیر است:
- اگر میخواهید نام پوشهی generated را تغییر دهید، میتوان از ویژگی CompilerGeneratedFilesOutputPath استفاده کرد.
- چون این فایلهای cs. جدید ثبت شدهی بر روی دیسک سخت، مجددا وارد پروسهی کامپایل میشوند و خود Source Generator هم یک نمونهی از آنهارا پیشتر به کامپایلر معرفی کردهاست، برنامه دیگر به علت وجود اطلاعات تکراری، کامپایل نخواهد شد. به همین جهت نیاز است تا قسمت Compile Remove فوق را نیز معرفی کرد تا کامپایلر از پوشهی Generated تنظیمی، صرفنظر کند.
- اطلاعات موجود در پوشهی Generated، فقط یکبار تولید میشوند؛ صرفنظر از اطلاعات موجود در حافظه که همیشه به روز است. به همین جهت اگر میخواهید نمونههای به روز شدهی آنها را نیز بر روی دیسک سخت داشته باشید، نیاز به قسمت RemoveDir تنظیمی وجود دارد.
using System.ComponentModel.DataAnnotations; namespace NotifyPropertyChangedGenerator.Demo; public enum Gender { NotSpecified, [Display(Name = "مرد")] Male, [Display(Name = "زن")] Female }
public static class Extensions { public static string GetDisplayName(this Enum value) { if (value is null) throw new ArgumentNullException(nameof(value)); var attribute = value.GetType().GetField(value.ToString())? .GetCustomAttributes<DisplayAttribute>(false).FirstOrDefault(); if (attribute is null) return value.ToString(); return attribute.GetType().GetProperty("Name")?.GetValue(attribute, null)?.ToString(); } }
یعنی در اصل متد کمکی که برای اینکار نیاز داریم، چنین خروجی را دارد:
namespace NotifyPropertyChangedGenerator.Demo { public static class GenderExtensions { public static string GetDisplayName(this Gender @enum) { return @enum switch { Gender.NotSpecified => "NotSpecified", Gender.Male => "مرد", Gender.Female => "زن", _ => throw new ArgumentOutOfRangeException(nameof(@enum)) }; } } }
با ارائهی Source Generators، مشکلات یاد شده دیگر وجود ندارند. یعنی کار تولید متدهای اختصاصی برای هر enum، خودکار است و همچنین به روز رسانی آنی آنها با هر تغییری در enumها نیز پیشبینی شدهاست.
تهیهی تولید کنندهی خودکار کدی که نام نمایشی enumها را به صورت از پیش محاسبه شده ارائه میدهد
در قسمت قبل، با روش تهیه و استفاده از Source Generators آشنا شدیم. در اینجا نیز از همان قالب، در جهت تولید کد متد الحاقی GetDisplayName فوق، استفاده خواهیم کرد. یعنی هدف رسیدن به کلاس GenderExtensions فوق و متد GetDisplayName آن، در زمان کامپایل برنامه و به صورت خودکار است:
[Generator] public class EnumExtensionsGenerator : ISourceGenerator { public void Initialize(GeneratorInitializationContext context) {} public void Execute(GeneratorExecutionContext context) { var compilation = context.Compilation; foreach (var syntaxTree in compilation.SyntaxTrees) { var semanticModel = compilation.GetSemanticModel(syntaxTree); var immutableHashSet = syntaxTree.GetRoot() .DescendantNodesAndSelf() .OfType<EnumDeclarationSyntax>() .Select(enumDeclarationSyntax => semanticModel.GetDeclaredSymbol(enumDeclarationSyntax)) .OfType<ITypeSymbol>() /*.Where(typeSymbol => typeSymbol.GetAttributes().Any( attributeData => string.Equals(attributeData.AttributeClass?.Name, "GenerateExtensions", StringComparison.Ordinal) ))*/ .ToImmutableHashSet(); foreach (var typeSymbol in immutableHashSet) { var source = GenerateEnumExtensions(typeSymbol); context.AddSource($"{typeSymbol.Name}Extensions.cs", source); } } }
در اینجا در متد Execute، دسترسی کاملی را به اطلاعات تهیه شدهی توسط کامپایلر داریم. توسط آن تمام Enumهای برنامه را یا همان EnumDeclarationSyntax را در اینجا، یافته و سپس حلقهای را بر روی اطلاعات آنها تشکیل داده و برای تک تک آنها، توسط متد GenerateEnumExtensions، کد معادل کلاس GenderExtensions را که در این مطلب معرفی شد، تولید میکنیم. در پایان کار نیز این کد را توسط متد AddSource، به کامپایلر معرفی خواهیم کرد تا بلافاصله در IDE ظاهر شده و قابلیت استفاده را پیدا کند.
یک نکته: اگر میخواهید صرفا enumهای خاصی در این بین بررسی شوند، میتوانید کدهای یک Attribute سفارشی را مثلا با نام فرضی [GenerateExtensions] در همینجا توسط متد context.AddSource به مجموعه سورسها اضافه کنید و سپس بر اساس نام آن، در قسمت Where ایی که کامنت شدهاست، تنها اطلاعات مدنظر را فیلتر و پردازش کنید.
متدی هم که ابتدا کلاس Extensions را بر اساس نام هر Enum موجود تولید و سپس بدنهی متد GetDisplayName اختصاصی آنرا تکمیل میکند، به صورت زیر است:
private string GenerateEnumExtensions(ITypeSymbol typeSymbol) { return $@"namespace {typeSymbol.ContainingNamespace} {{ public static class {typeSymbol.Name}Extensions {{ public static string GetDisplayName(this {typeSymbol.Name} @enum) {{ {GenerateExtensionMethodBody(typeSymbol)} }} }} }}"; } private static string GenerateExtensionMethodBody(ITypeSymbol typeSymbol) { var sb = new StringBuilder(); sb.Append(@"return @enum switch { "); foreach (var fieldSymbol in typeSymbol.GetMembers().OfType<IFieldSymbol>()) { var displayAttribute = fieldSymbol.GetAttributes() .FirstOrDefault(attributeData => string.Equals(attributeData.AttributeClass?.Name, "DisplayAttribute", StringComparison.Ordinal)); if (displayAttribute is null) { sb.AppendLine( $@" {typeSymbol.Name}.{fieldSymbol.Name} => ""{fieldSymbol.Name}"","); } else { var displayAttributeName = displayAttribute.NamedArguments .FirstOrDefault(x => string.Equals(x.Key, "Name", StringComparison.Ordinal)) .Value; sb.AppendLine( $@" {typeSymbol.Name}.{fieldSymbol.Name} => ""{displayAttributeName.Value}"","); } } sb.Append( @" _ => throw new ArgumentOutOfRangeException(nameof(@enum)) };"); return sb.ToString(); }
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید: SourceGeneratorTests-part3.zip
سؤال: چگونه میتوان کدهای تولید شدهی توسط یک Source Generator را ذخیره کرد؟
Source Generators به صورت پیشفرض هیچ فایلی را بر روی دیسک سخت ذخیره نمیکنند و تمام عملیات آنها در حافظه انجام میشود. اگر علاقمند به مطالعهی این خروجیهای خودکار، به صورت فایلهای واقعی هستید، نیاز به انجام تغییرات زیر در فایل csproj پروژهی مصرف کنندهی Source Generator است:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>net6.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> <CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath> </PropertyGroup> <Target Name="CleanSourceGeneratedFiles" BeforeTargets="BeforeBuild" DependsOnTargets="$(BeforeBuildDependsOn)"> <RemoveDir Directories="$(CompilerGeneratedFilesOutputPath)" /> </Target> <ItemGroup> <!-- Exclude the output of source generators from the compilation --> <Compile Remove="$(CompilerGeneratedFilesOutputPath)/**/*.cs" /> <Content Include="$(CompilerGeneratedFilesOutputPath)/**" /> </ItemGroup> <ItemGroup> <ProjectReference Include="..\NotifyPropertyChangedGenerator\NotifyPropertyChangedGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" /> </ItemGroup> </Project>
- EmitCompilerGeneratedFiles سبب ثبت فایلهای خودکار تولید شده، بر روی دیسک سخت میشود که قالب مسیر پیشفرض ذخیره سازی آن به صورت زیر است:
{BaseIntermediateOutpath}/generated/{Assembly}/{SourceGeneratorName}/{GeneratedFile}
- چون این فایلهای cs. جدید ثبت شدهی بر روی دیسک سخت، مجددا وارد پروسهی کامپایل میشوند و خود Source Generator هم یک نمونهی از آنهارا پیشتر به کامپایلر معرفی کردهاست، برنامه دیگر به علت وجود اطلاعات تکراری، کامپایل نخواهد شد. به همین جهت نیاز است تا قسمت Compile Remove فوق را نیز معرفی کرد تا کامپایلر از پوشهی Generated تنظیمی، صرفنظر کند.
- اطلاعات موجود در پوشهی Generated، فقط یکبار تولید میشوند؛ صرفنظر از اطلاعات موجود در حافظه که همیشه به روز است. به همین جهت اگر میخواهید نمونههای به روز شدهی آنها را نیز بر روی دیسک سخت داشته باشید، نیاز به قسمت RemoveDir تنظیمی وجود دارد.
فرض کنید یک چنین کلاسی طراحی شدهاست:
میخواهیم از طریق Reflection مقادیر فیلدها و متدهای مخفی آنرا بخوانیم.
حالت متداول دسترسی به فیلد خصوصی آن از طریق Reflection، یک چنین شکلی را دارد:
و یا دسترسی به مقدار خروجی متد خصوصی آن، به نحو زیر است:
در اینجا دسترسی به مقدار فیلد مخفی NestedClass، شامل مراحل زیر است:
البته این مقدار کد فقط برای دسترسی به دو سطح تو در تو بود.
چقدر خوب بود اگر میشد بجای این همه کد، نوشت:
نه؟!
برای این مشکل راه حلی معرفی شدهاست به نام Dynamic Proxy که در ادامه به معرفی آن خواهیم پرداخت.
معرفی Dynamic Proxy
Dynamic Proxy یکی از مفاهیم AOP است. به این معنا که توسط آن یک محصور کنندهی نامرئی، اطراف یک شیء تشکیل خواهد شد. از این غشای نامرئی عموما جهت مباحث ردیابی اطلاعات، مانند پروکسیهای Entity framework، همانجایی که تشخیص میدهد کدام خاصیت به روز شدهاست یا خیر، استفاده میشود و یا این غشای نامرئی کمک میکند که در حین دسترسی به خاصیت یا متدی، بتوان منطق خاصی را در این بین تزریق کرد. برای مثال فرآیند تکراری logging سیستم را به این غشای نامرئی منتقل کرد و به این ترتیب میتوان به کدهای تمیزتری رسید.
یکی دیگر از کاربردهای این محصور کننده یا غشای نامرئی، ساده سازی مباحث Reflection است که نمونهای از آن در پروژهی EntityFramework.Extended بکار رفتهاست.
در اینجا، کار با محصور سازی نمونهای از کلاس مورد نظر با Dynamic Proxy شروع میشود. سپس کل عملیات Reflection فوق در همین چند سطر ذیل به نحوی کاملا عادی و طبیعی قابل انجام است:
خروجی Dynamic Proxy از نوع dynamic دات نت 4 است. پس از آن میتوان در اینجا هر نوع خاصیت یا متد دلخواهی را به شکل dynamic تعریف کرد و سپس به مقادیر آنها دسترسی داشت.
بنابراین با استفاده از Dynamic Proxy فوق میتوان به دو مهم دست یافت:
1) ساده سازی و زیبا سازی کدهای کار با Reflection
2) استفادهی ضمنی از مباحث Fast Reflection. در کتابخانهی Dynamic Proxy معرفی شده، دسترسی به خواص و متدها، توسط کدهای IL بهینه سازی شدهاست و در دفعات آتی کار با آنها، دیگر شاهد سربار بالای Reflection نخواهیم بود.
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید:
DynamicProxyTests.zip
public class NestedClass { private int _field2; public NestedClass() { _field2 = 12; } } public class MyClass { private int _field1; private NestedClass _nestedClass; public MyClass() { _field1 = 1; _nestedClass = new NestedClass(); } private string GetData() { return "Test"; } }
حالت متداول دسترسی به فیلد خصوصی آن از طریق Reflection، یک چنین شکلی را دارد:
var myClass = new MyClass(); var field1Obj = myClass.GetType().GetField("_field1", BindingFlags.NonPublic | BindingFlags.Instance); if (field1Obj != null) { Console.WriteLine(Convert.ToInt32(field1Obj.GetValue(myClass))); }
var getDataMethod = myClass.GetType().GetMethod("GetData", BindingFlags.NonPublic | BindingFlags.Instance); if (getDataMethod != null) { Console.WriteLine(getDataMethod.Invoke(myClass, null)); }
var nestedClassObj = myClass.GetType().GetField("_nestedClass", BindingFlags.NonPublic | BindingFlags.Instance); if (nestedClassObj != null) { var nestedClassFieldValue = nestedClassObj.GetValue(myClass); var field2Obj = nestedClassFieldValue.GetType() .GetField("_field2", BindingFlags.NonPublic | BindingFlags.Instance); if (field2Obj != null) { Console.WriteLine(Convert.ToInt32(field2Obj.GetValue(nestedClassFieldValue))); } }
چقدر خوب بود اگر میشد بجای این همه کد، نوشت:
myClass._field1 myClass._nestedClass._field2 myClass.GetData()
برای این مشکل راه حلی معرفی شدهاست به نام Dynamic Proxy که در ادامه به معرفی آن خواهیم پرداخت.
معرفی Dynamic Proxy
Dynamic Proxy یکی از مفاهیم AOP است. به این معنا که توسط آن یک محصور کنندهی نامرئی، اطراف یک شیء تشکیل خواهد شد. از این غشای نامرئی عموما جهت مباحث ردیابی اطلاعات، مانند پروکسیهای Entity framework، همانجایی که تشخیص میدهد کدام خاصیت به روز شدهاست یا خیر، استفاده میشود و یا این غشای نامرئی کمک میکند که در حین دسترسی به خاصیت یا متدی، بتوان منطق خاصی را در این بین تزریق کرد. برای مثال فرآیند تکراری logging سیستم را به این غشای نامرئی منتقل کرد و به این ترتیب میتوان به کدهای تمیزتری رسید.
یکی دیگر از کاربردهای این محصور کننده یا غشای نامرئی، ساده سازی مباحث Reflection است که نمونهای از آن در پروژهی EntityFramework.Extended بکار رفتهاست.
در اینجا، کار با محصور سازی نمونهای از کلاس مورد نظر با Dynamic Proxy شروع میشود. سپس کل عملیات Reflection فوق در همین چند سطر ذیل به نحوی کاملا عادی و طبیعی قابل انجام است:
// Accessing a private field dynamic myClassProxy = new DynamicProxy(myClass); dynamic field1 = myClassProxy._field1; Console.WriteLine((int)field1); // Accessing a nested private field dynamic field2 = myClassProxy._nestedClass._field2; Console.WriteLine((int)field2); // Accessing a private method dynamic data = myClassProxy.GetData(); Console.WriteLine((string)data);
بنابراین با استفاده از Dynamic Proxy فوق میتوان به دو مهم دست یافت:
1) ساده سازی و زیبا سازی کدهای کار با Reflection
2) استفادهی ضمنی از مباحث Fast Reflection. در کتابخانهی Dynamic Proxy معرفی شده، دسترسی به خواص و متدها، توسط کدهای IL بهینه سازی شدهاست و در دفعات آتی کار با آنها، دیگر شاهد سربار بالای Reflection نخواهیم بود.
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید:
DynamicProxyTests.zip
- همیشه باید احتمال نفوذ پذیر بودن قسمتهای مختلف برنامه را داد. وجود یک سطح امنیتی بیشتر به هیچ عنوان ضرری ندارد.
- اگر اطلاعات دسترسی را در ابتدای کار در دسترس دارید، مابقی کار تزریق اطلاعات و پر کردن جاهای خالی است.
- ممکن است دسترسی حرکت از یک مرحله به مرحلهی بعد، نیازمند محاسبات خاصی فراتر از سطح دسترسیهای معمولی سیستم باشد. مثلا به یک کاربر خاص بدون دسترسی به پنل مدیریتی سیستم، امکان برگشت زدن یا تائید را داد. در یک چنین حالتی یک گردش کاری، سطح دسترسی محاسباتی خاص خودش را نیاز دارد.
- یک گردش کاری را در یک scheduled job پس زمینه هم میشود اجرا کرد. بنابراین طراحی اصولی آن به همین شکل است (و غیر وابسته به فناوری خاصی).
- اگر اطلاعات دسترسی را در ابتدای کار در دسترس دارید، مابقی کار تزریق اطلاعات و پر کردن جاهای خالی است.
- ممکن است دسترسی حرکت از یک مرحله به مرحلهی بعد، نیازمند محاسبات خاصی فراتر از سطح دسترسیهای معمولی سیستم باشد. مثلا به یک کاربر خاص بدون دسترسی به پنل مدیریتی سیستم، امکان برگشت زدن یا تائید را داد. در یک چنین حالتی یک گردش کاری، سطح دسترسی محاسباتی خاص خودش را نیاز دارد.
- یک گردش کاری را در یک scheduled job پس زمینه هم میشود اجرا کرد. بنابراین طراحی اصولی آن به همین شکل است (و غیر وابسته به فناوری خاصی).
- حالتهای دیگر اتصال را مانند signalR.HttpTransportType.ServerSentEvents با سطح لاگ بالا مانند signalR.LogLevel.Trace بررسی کنید.
یک مثال: پیاده سازی INotifyPropertyChanged توسط Source Generators
هدف از اینترفیس INotifyPropertyChanged که به همراه یک رخداد است:
مطلع سازی استفاده کنندهی از یک شیء، از تغییرات رخدادهی در مقادیر خواص آن است که نمونهی آن، در برنامههای WPF، جهت به روز رسانی UI، زیاد مورد استفاده قرار میگیرد. البته این رخداد به خودی خود کار خاصی را انجام نمیدهد و برای استفادهی از آن، باید مقدار زیادی کد نوشت و این مقدار کد نیز باید به ازای تک تک خواص یک کلاس مدل، تکرار شوند:
همچنین باید درنظر داشت که با تغییر نام خاصیتی، میزان قابل ملاحظهای از این کدهای تکراری نیز باید به روز رسانی شوند که این عملیات میتواند ایدهی خوبی برای استفادهی از Source Generators باشد.
اگر بخواهیم تولید این کدهای تکراری را به Source Generators محول کنیم، میتوان برای مثال فیلد خصوصی مرتبط را نگه داشت و تولید مابقی کدها را خودکار کرد:
در این حالت کلاس مدل، به صورت partial تعریف میشود و فقط فیلد خصوصی، در کدهای ما حضور خواهد داشت. مابقی کدهای این کلاس partial به صورت خودکار توسط یک Source Generator سفارشی تولید خواهد شد. همانطور که ملاحظه میکنید، کاهش حجم قابل ملاحظهای حاصل شده و همچنین اگر فیلد خصوصی دیگری نیز در اینجا اضافه شود، واکنش Source Generator ما آنی خواهد بود و بلافاصله کدهای مرتبط را تولید میکند و برنامه، بدون مشکلی کامپایل خواهد شد؛ هرچند به ظاهر INotifyPropertyChanged ذکر شده، در این کلاس اصلا پیاده سازی نشدهاست.
ایجاد پروژهی Source Generator
در ابتدا برای ایجاد تولید کنندهی خودکار کدهای INotifyPropertyChanged، یک class library را به solution جاری اضافه میکنیم. سپس نیاز است ارجاعاتی را به دو بستهی نیوگت زیر نیز افزود:
سپس کلاس جدید NotifyPropertyChangedGenerator را به نحو زیر به آن اضافه میکنیم:
- این کلاس باید اینترفیس ISourceGenerator را پیاده سازی کرده و همچنین مزین به ویژگی Generator باشد.
- اینترفیس ISourceGenerator به همراه دو متد Initialize و Execute است که در صورت نیاز باید پیاده سازی شوند.
در متد Execute، به خاصیت context.Compilation دسترسی داریم. این خاصیت تمام اطلاعاتی را که کامپایلر از Solution جاری در اختیار دارد، به توسعه دهنده ارائه میدهد. برای نمونه پیاده سازی متد Execute تولید کنندهی کد مثال جاری، چنین شکلی را دارد:
در اینجا با استفاده از context.Compilation به اطلاعات کامپایلر دسترسی پیدا کرده و سپس SyntaxTrees آنرا یکی یکی، جهت یافتن کلاسها و یا همان ClassDeclarationSyntax ها، پیمایش و بررسی میکنیم. سپس از بین این کلاسها، کلاسهایی که INotifyPropertyChanged را پیاده سازی کرده باشند، انتخاب میکنیم که اطلاعات آن در پایان کار، به متد GeneratePropertyChanged جهت تولید مابقی کدهای partial class ارسال شده و کد تولیدی، به context اضافه میشود تا به نحو متداولی همانند سایر کدهای برنامه، به مجموعه کدهای مورد بررسی کامپایلر اضافه شود.
نکتهی مهم و جالب در اینجا این است که نیازی نیست تا قطعه کد جدید را به صورت SyntaxTrees در آورد و به کامپایلر اضافه کرد. میتوان این قطعه کد را به نحو متداولی، به صورت یک قطعه رشتهی استاندارد #C، تولید و به کامپایلر با متد context.AddSource ارائه کرد که نمونهای از آنرا در ذیل مشاهده میکنید:
در اینجا در ابتدا بدنهی کلاس partial تکمیل میشود. سپس خواص عمومی آن بر اساس فیلدهای خصوصی تعریف شده، تکمیل میشوند. در این مثال اگر یک فیلد خصوصی به عبارت BackingField ختم شود، به عنوان فیلدی که قرار است معادل کدهای INotifyPropertyChanged را داشته باشد، شناسایی میشود و به همراه کدهای تولید شدهی خودکار خواهد بود.
کدهای source generator ما همین مقدار بیشتر نیست. اکنون میخواهیم از آن در یک برنامهی کنسول جدید (برای مثال به نام NotifyPropertyChangedGenerator.Demo) استفاده کنیم. برای اینکار نیاز است ارجاعی را به آن اضافه کنیم؛ اما این ارجاع، یک ارجاع متداول نیست و نیاز به ذکر چنین ویژگی خاصی وجود دارد:
در اینجا میسر دهی پروژهی تولید کنندهی کد، همانند سایر پروژهها است؛ اما نوع آن باید آنالایزر معرفی شود. به همین جهت از خاصیت OutputItemType با مقدار Analyzer استفاده شدهاست. همچنین تنظیم ReferenceOutputAssembly به false به این معنا است که این اسمبلی ویژه، یک وابستگی و dependency واقعی پروژهی جاری نیست و ما قرار نیست به صورت مستقیمی از کدهای آن استفاده کنیم.
برای آزمایش این تولید کنندهی کد، کلاس CarModel را به صورت زیر به پروژهی کنسول آزمایشی اضافه میکنیم:
این کلاس پیاده سازی کنندهی INotifyPropertyChanged است؛ اما به همراه هیچ خاصیت عمومی نیست. فقط به همراه یکسری فیلد خصوصی ختم شدهی به «BackingField» است که توسط تولید کنندهی کد شناسایی شده و اطلاعات آنها تکمیل میشود. فقط باید دقت داشت که این کلاس حتما باید به صورت partial تعریف شود تا امکان تکمیل خودکار کدهای آن وجود داشته باشد.
نحوهی مشاهدهی کدهای خودکار تولید شده
اگر علاقمند باشید تا کدهای خودکار تولید شده را مشاهده کنید، در Visual Studio، در قسمت و درخت نمایشی dependencies پروژه، گرهای به نام Analyzers وجود دارد که در آن برای مثال نام NotifyPropertyChangedGenerator و ذیل آن، کلاسهای تولید شدهی توسط آن، قابل مشاهده و دسترسی هستند و حتی قابل دیباگ نیز میباشند؛ یعنی میتوان بر روی سطور مختلف آن، break-point قرار داد.
هدف از اینترفیس INotifyPropertyChanged که به همراه یک رخداد است:
public interface INotifyPropertyChanged { event PropertyChangedEventHandler PropertyChanged; }
partial class CarModel : INotifyPropertyChanged { private double _speedKmPerHour; public double SpeedKmPerHour { get => _speedKmPerHour; set { _speedKmPerHour = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(SpeedKmPerHour))); } } public event PropertyChangedEventHandler? PropertyChanged; }
اگر بخواهیم تولید این کدهای تکراری را به Source Generators محول کنیم، میتوان برای مثال فیلد خصوصی مرتبط را نگه داشت و تولید مابقی کدها را خودکار کرد:
partial class CarModel : INotifyPropertyChanged { private double _speedKmPerHour; }
ایجاد پروژهی Source Generator
در ابتدا برای ایجاد تولید کنندهی خودکار کدهای INotifyPropertyChanged، یک class library را به solution جاری اضافه میکنیم. سپس نیاز است ارجاعاتی را به دو بستهی نیوگت زیر نیز افزود:
<Project Sdk="Microsoft.NET.Sdk"> <ItemGroup> <PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.3"> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> <PrivateAssets>all</PrivateAssets> </PackageReference> <PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="4.2.0" PrivateAssets="all" /> </ItemGroup> </Project>
[Generator] public class NotifyPropertyChangedGenerator : ISourceGenerator { public void Initialize(GeneratorInitializationContext context) { } public void Execute(GeneratorExecutionContext context) {
- اینترفیس ISourceGenerator به همراه دو متد Initialize و Execute است که در صورت نیاز باید پیاده سازی شوند.
در متد Execute، به خاصیت context.Compilation دسترسی داریم. این خاصیت تمام اطلاعاتی را که کامپایلر از Solution جاری در اختیار دارد، به توسعه دهنده ارائه میدهد. برای نمونه پیاده سازی متد Execute تولید کنندهی کد مثال جاری، چنین شکلی را دارد:
public void Execute(GeneratorExecutionContext context) { // uncomment to debug the actual build of the target project // Debugger.Launch(); var compilation = context.Compilation; var notifyInterface = compilation.GetTypeByMetadataName("System.ComponentModel.INotifyPropertyChanged"); foreach (var syntaxTree in compilation.SyntaxTrees) { var semanticModel = compilation.GetSemanticModel(syntaxTree); var immutableHashSet = syntaxTree.GetRoot() .DescendantNodesAndSelf() .OfType<ClassDeclarationSyntax>() .Select(x => semanticModel.GetDeclaredSymbol(x)) .OfType<ITypeSymbol>() .Where(x => x.Interfaces.Contains(notifyInterface)) .ToImmutableHashSet(); foreach (var typeSymbol in immutableHashSet) { var source = GeneratePropertyChanged(typeSymbol); context.AddSource($"{typeSymbol.Name}.Notify.cs", source); } } }
نکتهی مهم و جالب در اینجا این است که نیازی نیست تا قطعه کد جدید را به صورت SyntaxTrees در آورد و به کامپایلر اضافه کرد. میتوان این قطعه کد را به نحو متداولی، به صورت یک قطعه رشتهی استاندارد #C، تولید و به کامپایلر با متد context.AddSource ارائه کرد که نمونهای از آنرا در ذیل مشاهده میکنید:
private string GeneratePropertyChanged(ITypeSymbol typeSymbol) { return $@" using System.ComponentModel; namespace {typeSymbol.ContainingNamespace} {{ partial class {typeSymbol.Name} {{ {GenerateProperties(typeSymbol)} public event PropertyChangedEventHandler? PropertyChanged; }} }}"; } private static string GenerateProperties(ITypeSymbol typeSymbol) { var sb = new StringBuilder(); var suffix = "BackingField"; foreach (var fieldSymbol in typeSymbol.GetMembers().OfType<IFieldSymbol>() .Where(x=>x.Name.EndsWith(suffix))) { var propertyName = fieldSymbol.Name[..^suffix.Length]; sb.AppendLine($@" public {fieldSymbol.Type} {propertyName} {{ get => {fieldSymbol.Name}; set {{ {fieldSymbol.Name} = value; PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof({propertyName}))); }} }}"); } return sb.ToString(); }
کدهای source generator ما همین مقدار بیشتر نیست. اکنون میخواهیم از آن در یک برنامهی کنسول جدید (برای مثال به نام NotifyPropertyChangedGenerator.Demo) استفاده کنیم. برای اینکار نیاز است ارجاعی را به آن اضافه کنیم؛ اما این ارجاع، یک ارجاع متداول نیست و نیاز به ذکر چنین ویژگی خاصی وجود دارد:
<Project Sdk="Microsoft.NET.Sdk"> <ItemGroup> <ProjectReference Include="..\NotifyPropertyChangedGenerator\NotifyPropertyChangedGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false"/> </ItemGroup> </Project>
برای آزمایش این تولید کنندهی کد، کلاس CarModel را به صورت زیر به پروژهی کنسول آزمایشی اضافه میکنیم:
using System.ComponentModel; namespace NotifyPropertyChangedGenerator.Demo { public partial class CarModel : INotifyPropertyChanged { private double SpeedKmPerHourBackingField; private int NumberOfDoorsBackingField; private string ModelBackingField = ""; public void SpeedUp() => SpeedKmPerHour *= 1.1; } }
یک نکته: در این حالت هرچند برنامه بدون مشکل کامپایل و اجرا میشود، ممکن است خطوط قرمزی را در IDE خود مشاهده کنید که عنوان میکند این قطعه از کد قابل کامپایل نیست. اگر با چنین صحنهای مواجه شدید، یکبار solution را بسته و مجددا باز کنید تا تولید کنندهی کد، به خوبی شناسایی شود. البته نگارشهای جدیدتر Visual Studio و Rider به همراه قابلیت auto reload پروژه برای کار با تولید کنندههای کد هستند و دیگر شاهد چنین صحنههایی نیستیم و حتی اگر برای مثال فیلد جدیدی را به CarModel اضافه کنیم، نه فقط بلافاصله کدهای متناظر آن تولید میشوند، بلکه خواص عمومی تولید شده در Intellisense نیز قابل دسترسی هستند.
نحوهی مشاهدهی کدهای خودکار تولید شده
اگر علاقمند باشید تا کدهای خودکار تولید شده را مشاهده کنید، در Visual Studio، در قسمت و درخت نمایشی dependencies پروژه، گرهای به نام Analyzers وجود دارد که در آن برای مثال نام NotifyPropertyChangedGenerator و ذیل آن، کلاسهای تولید شدهی توسط آن، قابل مشاهده و دسترسی هستند و حتی قابل دیباگ نیز میباشند؛ یعنی میتوان بر روی سطور مختلف آن، break-point قرار داد.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: SourceGeneratorTests.zip
معرفی تعدادی منبع تکمیلی
- برنامه Source generator playground
در اینجا تعدادی مثال را که توسط مایکروسافت توسعه یافتهاست، مشاهده میکنید که اتفاقا یکی از آنها پیاده سازی تولید کنندهی کد اینترفیس INotifyPropertyChanged است. در این برنامه، خروجی کدهای تولیدی نیز به سادگی قابل مشاهدهاست.
- برنامه SharpLab
برای توسعهی تولید کنندههای کد، عموما نیاز است تا با Roslyn API آشنا بود. در این برنامه اگر از منوی بالای صفحه قسمت results، گزینهی «syntax tree» را انتخاب کنید و سپس قسمتی از کد خود را انتخاب کنید، بلافاصله معادل Roslyn API آن، در سمت راست صفحه نمایش داده میشود.
- معرفی مجموعهای از Source Generators
در اینجا میتوان مجموعهای از پروژههای سورس باز Source Generators را مشاهده و کدهای آنها را مطالعه کنید و یا از آنها در پروژههای خود استفاده نمائید.
- معرفی یک cookbook در مورد Source Generators
این cookbook توسط خود مایکروسافت تهیه شدهاست و جهت شروع به کار با این فناوری، بسیار مفید است.
- مجموعه مثالهای Source generators از مایکروسافت
در اینجا میتوانید مجموعه مثالهایی از Source generators را که توسط مایکروسافت تهیه شدهاست، مشاهده کنید. شرح و توضیحات تعدادی از آنها را هم در اینجا مطالعه کنید.
در اینجا تعدادی مثال را که توسط مایکروسافت توسعه یافتهاست، مشاهده میکنید که اتفاقا یکی از آنها پیاده سازی تولید کنندهی کد اینترفیس INotifyPropertyChanged است. در این برنامه، خروجی کدهای تولیدی نیز به سادگی قابل مشاهدهاست.
- برنامه SharpLab
برای توسعهی تولید کنندههای کد، عموما نیاز است تا با Roslyn API آشنا بود. در این برنامه اگر از منوی بالای صفحه قسمت results، گزینهی «syntax tree» را انتخاب کنید و سپس قسمتی از کد خود را انتخاب کنید، بلافاصله معادل Roslyn API آن، در سمت راست صفحه نمایش داده میشود.
- معرفی مجموعهای از Source Generators
در اینجا میتوان مجموعهای از پروژههای سورس باز Source Generators را مشاهده و کدهای آنها را مطالعه کنید و یا از آنها در پروژههای خود استفاده نمائید.
- معرفی یک cookbook در مورد Source Generators
این cookbook توسط خود مایکروسافت تهیه شدهاست و جهت شروع به کار با این فناوری، بسیار مفید است.
- مجموعه مثالهای Source generators از مایکروسافت
در اینجا میتوانید مجموعه مثالهایی از Source generators را که توسط مایکروسافت تهیه شدهاست، مشاهده کنید. شرح و توضیحات تعدادی از آنها را هم در اینجا مطالعه کنید.
یک سناریوی فرضی را در نظر بگیرید. اگر بخواهیم IdentityDbContext و دیگر DbContextهای اپلیکیشن را ادغام کنیم چه باید کرد؟ مثلا یک سیستم وبلاگ که برخی کاربران میتوانند پست جدید ثبت کنند، برخی تنها میتوانند کامنت بگذارند و تمامی کاربران هم اختیارات مشخص دیگری دارند. در چنین سیستمی شناسه کاربران (User ID) در بسیاری از مدلها (موجودیتها و مدلهای اپلیکیشن) وجود خواهد داشت تا مشخص شود هر رکورد به کدام کاربر متعلق است. در این مقاله چنین سناریو هایی را بررسی میکنیم و best practiceهای مربوطه را مرور میکنیم.
پس از ورود به سایت بعنوان یک مدیر، میتوانید ToDoهای ثبت شده توسط تمام کاربران را مشاهده کنید.
در این پست یک اپلیکیشن ساده ToDo خواهیم ساخت که امکان تخصیص to-doها به کاربران را نیز فراهم میکند. در این مثال خواهیم دید که چگونه میتوان مدلهای مختص به سیستم عضویت (IdentityDbContext) را با مدلهای دیگر اپلیکیشن مخلوط و استفاده کنیم.
تعریف نیازمندیهای اپلیکیشن
- تنها کاربران احراز هویت شده قادر خواهند بود تا لیست ToDoهای خود را ببینند، آیتمهای جدید ثبت کنند یا دادههای قبلی را ویرایش و حذف کنند.
- کاربران نباید آیتمهای ایجاد شده توسط دیگر کاربران را ببینند.
- تنها کاربرانی که به نقش Admin تعلق دارند باید بتوانند تمام ToDoهای ایجاد شده را ببینند.
پس بگذارید ببینیم چگونه میشود اپلیکیشنی با ASP.NET Identity ساخت که پاسخگوی این نیازمندیها باشد.
ابتدا یک پروژه ASP.NET MVC جدید با مدل احراز هویت Individual User Accounts بسازید. در این اپلیکیشن کاربران قادر خواهند بود تا بصورت محلی در وب سایت ثبت نام کنند و یا با تامین کنندگان دیگری مانند گوگل و فیسبوک وارد سایت شوند. برای ساده نگاه داشتن این پست ما از حسابهای کاربری محلی استفاده میکنیم.
در مرحله بعد ASP.NET Identity را راه اندازی کنید تا بتوانیم نقش مدیر و یک کاربر جدید بسازیم. میتوانید با اجرای اپلیکیشن راه اندازی اولیه را انجام دهید. از آنجا که سیستم ASP.NET Identity توسط Entity Framework مدیریت میشود میتوانید از تنظیمات پیکربندی Code First برای راه اندازی دیتابیس خود استفاده کنید.
در قدم بعدی راه انداز دیتابیس را در Global.asax تعریف کنید.
Database.SetInitializer<MyDbContext>(new MyDbInitializer());
ایجاد نقش مدیر و کاربر جدیدی که به این نقش تعلق دارد
اگر به قطعه کد زیر دقت کنید، میبینید که در خط شماره 5 متغیری از نوع UserManager ساخته ایم که امکان اجرای عملیات گوناگونی روی کاربران را فراهم میکند. مانند ایجاد، ویرایش، حذف و اعتبارسنجی کاربران. این کلاس که متعلق به سیستم ASP.NET Identity است همتای SQLMembershipProvider در ASP.NET 2.0 است.
در خط 6 یک RoleManager میسازیم که امکان کار با نقشها را فراهم میکند. این کلاس همتای SQLRoleMembershipProvider در ASP.NET 2.0 است.
در این مثال نام کلاس کاربران (موجودیت کاربر در IdentityDbContext) برابر با "MyUser" است، اما نام پیش فرض در قالبهای پروژه VS 2013 برابر با "ApplicationUser" میباشد.
public class MyDbInitializer : DropCreateDatabaseAlways<MyDbContext> { protected override void Seed(MyDbContext context) { var UserManager = new UserManager<MyUser>(new UserStore<MyUser>(context)); var RoleManager = new RoleManager<IdentityRole>(new RoleStore<IdentityRole>(context)); string name = "Admin"; string password = "123456"; //Create Role Admin if it does not exist if (!RoleManager.RoleExists(name)) { var roleresult = RoleManager.Create(new IdentityRole(name)); } //Create User=Admin with password=123456 var user = new MyUser(); user.UserName = name; var adminresult = UserManager.Create(user, password); //Add User Admin to Role Admin if (adminresult.Succeeded) { var result = UserManager.AddToRole(user.Id, name); } base.Seed(context); } }
حال فایلی با نام Models/AppModels.cs بسازید و مدل EF Code First اپلیکیشن را تعریف کنید. از آنجا که از EF استفاده میکنیم، روابط کلیدها بین کاربران و ToDoها بصورت خودکار برقرار میشود.
public class MyUser : IdentityUser { public string HomeTown { get; set; } public virtual ICollection<ToDo> ToDoes { get; set; } } public class ToDo { public int Id { get; set; } public string Description { get; set; } public bool IsDone { get; set; } public virtual MyUser User { get; set; } }
در قدم بعدی با استفاده از مکانیزم Scaffolding کنترلر جدیدی بهمراه تمام Viewها و متدهای لازم برای عملیات CRUD بسازید. برای اطلاعات بیشتر درباره نحوه استفاده از مکانیزم Scaffolding به این لینک مراجعه کنید.
لطفا دقت کنید که از DbContext فعلی استفاده کنید. این کار مدیریت دادههای Identity و اپلیکیشن شما را یکپارچهتر میکند. DbContext شما باید چیزی شبیه به کد زیر باشد.
public class MyDbContext : IdentityDbContext<MyUser> { public MyDbContext() : base("DefaultConnection") { } protected override void OnModelCreating(DbModelBuilder modelBuilder) { public System.Data.Entity.DbSet<AspnetIdentitySample.Models.ToDo> ToDoes { get; set; } }
تنها کاربران احراز هویت شده باید قادر به اجرای عملیات CRUD باشند
برای این مورد از خاصیت Authorize استفاده خواهیم کرد که در MVC 4 هم وجود داشت. برای اطلاعات بیشتر لطفا به این لینک مراجعه کنید.
[Authorize] public class ToDoController : Controller
کنترلر ایجاد شده را ویرایش کنید تا کاربران را به ToDoها اختصاص دهد. در این مثال تنها اکشن متدهای Create و List را بررسی خواهیم کرد. با دنبال کردن همین روش میتوانید متدهای Edit و Delete را هم بسادگی تکمیل کنید.
یک متد constructor جدید بنویسید که آبجکتی از نوع UserManager میپذیرد. با استفاده از این کلاس میتوانید کاربران را در ASP.NET Identity مدیریت کنید.
private MyDbContext db; private UserManager<MyUser> manager; public ToDoController() { db = new MyDbContext(); manager = new UserManager<MyUser>(new UserStore<MyUser>(db)); }
اکشن متد Create را بروز رسانی کنید
هنگامی که یک ToDo جدید ایجاد میکنید، کاربر جاری را در ASP.NET Identity پیدا میکنیم و او را به ToDoها اختصاص میدهیم.
public async Task<ActionResult> Create ([Bind(Include="Id,Description,IsDone")] ToDo todo) { var currentUser = await manager.FindByIdAsync (User.Identity.GetUserId()); if (ModelState.IsValid) { todo.User = currentUser; db.ToDoes.Add(todo); await db.SaveChangesAsync(); return RedirectToAction("Index"); } return View(todo); }
اکشن متد List را بروز رسانی کنید
در این متد تنها ToDoهای کاربر جاری را باید بگیریم.
public ActionResult Index() { var currentUser = manager.FindById(User.Identity.GetUserId()); return View(db.ToDoes.ToList().Where( todo => todo.User.Id == currentUser.Id)); }
تنها مدیران سایت باید بتوانند تمام ToDoها را ببینند
بدین منظور ما یک اکشن متد جدید به کنترل مربوطه اضافه میکنیم که تمام ToDoها را لیست میکند. اما دسترسی به این متد را تنها برای کاربرانی که در نقش مدیر وجود دارند میسر میکنیم.
[Authorize(Roles="Admin")] public async Task<ActionResult> All() { return View(await db.ToDoes.ToListAsync()); }
نمایش جزئیات کاربران از جدول ToDo ها
از آنجا که ما کاربران را به ToDo هایشان مرتبط میکنیم، دسترسی به دادههای کاربر ساده است. مثلا در متدی که مدیر سایت تمام آیتمها را لیست میکند میتوانیم به اطلاعات پروفایل تک تک کاربران دسترسی داشته باشیم و آنها را در نمای خود بگنجانیم. در این مثال تنها یک فیلد بنام HomeTown اضافه شده است، که آن را در کنار اطلاعات ToDo نمایش میدهیم.
@model IEnumerable<AspnetIdentitySample.Models.ToDo> @{ ViewBag.Title = "Index"; } <h2>List of ToDoes for all Users</h2> <p> Notice that we can see the User info (UserName) and profile info such as HomeTown for the user as well. This was possible because we associated the User object with a ToDo object and hence we can get this rich behavior. 12: </p> <table class="table"> <tr> <th> @Html.DisplayNameFor(model => model.Description) </th> <th> @Html.DisplayNameFor(model => model.IsDone) </th> <th>@Html.DisplayNameFor(model => model.User.UserName)</th> <th>@Html.DisplayNameFor(model => model.User.HomeTown)</th> </tr> 25: 26: @foreach (var item in Model) 27: { 28: <tr> 29: <td> 30: @Html.DisplayFor(modelItem => item.Description) 31: </td> 32: <td> @Html.DisplayFor(modelItem => item.IsDone) </td> <td> @Html.DisplayFor(modelItem => item.User.UserName) </td> <td> @Html.DisplayFor(modelItem => item.User.HomeTown) </td> </tr> } </table>
صفحه Layout را بروز رسانی کنید تا به ToDoها لینک شود
<li>@Html.ActionLink("ToDo", "Index", "ToDo")</li> <li>@Html.ActionLink("ToDo for User In Role Admin", "All", "ToDo")</li>
حال اپلیکیشن را اجرا کنید. همانطور که مشاهده میکنید دو لینک جدید به منوی سایت اضافه شده اند.
ساخت یک ToDo بعنوان کاربر عادی
روی لینک ToDo کلیک کنید، باید به صفحه ورود هدایت شوید چرا که دسترسی تنها برای کاربران احراز هویت شده تعریف وجود دارد. میتوانید یک حساب کاربری محلی ساخته، با آن وارد سایت شوید و یک ToDo بسازید.
پس از ساختن یک ToDo میتوانید لیست رکوردهای خود را مشاهده کنید. دقت داشته باشید که رکوردهایی که کاربران دیگر ثبت کرده اند برای شما نمایش داده نخواهند شد.
مشاهده تمام ToDoها بعنوان مدیر سایت
روی لینک ToDoes for User in Role Admin کلیک کنید. در این مرحله باید مجددا به صفحه ورود هدایت شوید چرا که شما در نقش مدیر نیستید و دسترسی کافی برای مشاهده صفحه مورد نظر را ندارید. از سایت خارج شوید و توسط حساب کاربری مدیری که هنگام راه اندازی اولیه دیتابیس ساخته اید وارد سایت شوید.
User = Admin Password = 123456
debug visualizer در ویژوال استودیو با استفاده از reflection و به کمک lazy loading فعال، سعی در واکشی اطلاعات کردهاست.