نظرات مطالب
معرفی System.Text.Json در NET Core 3.0.
یک نکته‌ی تکمیلی: روش تزریق وابستگی‌ها به تنظیمات MvcBuilder در متد ConfigureServices

- روش دیگر آن به کمک IConfigureOptions و معرفی آن به سیستم تزریق وابستگی‌ها است تا وابستگی‌های آن‌را به صورت خودکار تامین کند:
    public class AppJsonOptions : IConfigureOptions<JsonOptions>
    {
        private readonly IHttpContextAccessor _accessor;

        public AppJsonOptions(IHttpContextAccessor accessor)
        {
            _accessor = accessor;
        }

        public virtual void Configure(JsonOptions options)
        {
            options.JsonSerializerOptions.Converters.Add(new BooleanConverter(_accessor));
        }
    }

پس از این تعریف، نحوه‌ی معرفی آن به سیستم به صورت زیر خواهد بود:
    public void ConfigureServices(IServiceCollection services)
    {
       services.AddHttpContextAccessor();
       services.AddSingleton<IConfigureOptions<JsonOptions>, AppJsonOptions>();

و Converter تعریف شده هم به این نحو می‌تواند به وابستگی‌ها دسترسی پیدا کند:
    public class BooleanConverter : JsonConverter<bool>
    {
        private readonly IHttpContextAccessor _accessor;

        public BooleanConverter(IHttpContextAccessor accessor)
        {
            _accessor = accessor;
        }

        public override bool Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
        {
            var testService = _accessor.HttpContext.RequestServices.GetRequiredService<TestService>();

            // ...
            throw new NotSupportedException();
        }

        public override void Write(Utf8JsonWriter writer, bool value, JsonSerializerOptions options)
        {
        }
    }

علت استفاده‌ی از IHttpContextAccessor در اینجا این است که چون IConfigureOptions به صورت Singleton ثبت می‌شود، بنابراین فقط سرویس‌هایی با طول عمر Singleton را هم می‌توان به آن تزریق کرد؛ اما RequestServices.GetRequiredService این محدودیت را ندارد.
نظرات مطالب
بخش اول - آشنایی و شروع کار با Svelte
حجم زیاد برنامه‌های بزرگ که به طور مثال با angular نوشته شده اند همیشه دردسر ساز بوده و کاربرانی که از اینترنت‌های ضعیف‌تر استفاده میکنند را با مشکل مواجه کرده. بخصوص داخل ایران کاربر کم نداریم که این مشکل رو دارند در نتیجه به نظر من معیار بدی نیست برای مقایسه. 
در مورد کم کردن حجم و زمان کدنویسی هم به مراتب به نظر من svelte آمار بسیار مناسبی نسبت به سایر فریم ورک‌های معتبر داره همینطور یادگیری و کارکردن با آن ساده است که به فرایند تولید نرم افزار بسیار کمک میکنه. حداقل برای من این نکته خیلی مهم هستش. 
مورد آخری که میمونه در مورد performance هست که اتفاقا من از دیشب مجددا پس از نوشتن این مقاله در موردش تحقیق کردم ولی هنگام نوشتن این مقاله نخواستم بهش اشاره کنم چرا که شاید به نظر میومد قصد دارم حقیقت رو به شکل دیگه ای نشون بدم.
در واقع  از نظر performance به طور کلی این کامپالر عملکرد به مراتب بهتری داره نسبت به سایر فریم ورک هایی که تا امروز استفاده کرده ایم. چه در استفاده از مموری و چه در اجرای کد تنها به دلیل اینکه از virtual-DOM استفاده نمیکند. در آمار بالا خیلی از پارامتر‌های مهم لحاظ نشده بودند به همین جهت رتبه بندی به این شکل است, چرا که تنها svelte در این لیست یک کامپایلر است و الباقی فریم ورک هستند که وضعیت حدودا برابری با هم دارند. 
پیشنهاد میکنم اگر در مورد مزیت‌های این کامپایلر نیاز به اطلاعات بیشتر داشتید این چند ویدئو رو مشاهده کنید. با جزئیات به این موارد بخصوص در بحث Performance پرداخته اند.
جواب سوال شما در ویدئو اول داده شده و در مورد performance دو ویدئو بعدی دلایل بهتر بودن آن را بیان میکند.
در آخر منظور من به طور قطعی بهتر یا بدتر بودن این کامپایلر نیست ولی با توجه به امکانات و تفاوت هایی که داره ارزش امتحان کردن رو قطعا داره. درمورد تعداد سوال و مشارکتی که گذاشتید حق با شماست این پروژه کاملا یک کار یک نفره است و هنوز جا نیفتاده, شاید هم نیفته به همین جهت من بزرگترین ایراد اون رو نداشتن پشتوانه قوی بیان کردم در قسمت معایب.
نظرات مطالب
Defensive Programming - بازگشت نتایج قابل پیش بینی توسط متدها
Application Service‌ها هر آنچه برای انجام یک Use-case نیاز است را در دل خود دارند به عنوان مثال:
        [HttpPost, AjaxOnly, ValidateAntiForgeryToken, ValidateModelState]
        public virtual async Task<ActionResult> Create([Bind(Prefix = "Model")]MeetingCreateModel model)
        {
            await _service.CreateAsync(model).ConfigureAwait(false);

            return InformationNotification("Messages.Save.Success");
        }
صحبت شما کاملا درست است ولی زمانی که به عنوان مثال بخشی از منطق تجاری اصلی در بالاترین لایه هم قرار می‌گرفت.
فرض کنید، برای ثبت یک جلسه نیاز است این اعتبارسنجی انجام شود که مدعوین انتخاب شده از حیث جایگاه خود در ساختار سازمانی امکان انتخاب شدن به عنوان مدعو توسط کاربر جاری را داشتند یا خیر؛ مکان این اعتبارسنجی قطعا لایه سرویس می‌باشد. چه بسا در این اعتبارسنجی کوئری‌های مختلفی اجرا شود که خروجی Null هم داشته باشند و مشکلی هم ندارد و من هم روی این خروجی‌ها بررسی شرطی انجام می‌دهم ولی اینها همه در دل متد CreateAsync قرار دارند یا برای آنها Validator مناسب در نظر گرفته شده است. صحبت این است که این متد اگر خود یک استثنا صادر نکند، باید یک OperationResult بازگشت دهد و نهایتا این خطاها به ModelState اضافه شوند برای نمایش به کاربر نهایی. من استثنا صادر می‌کنم و آن را گرفته و هم می‌توانم به خطاهای ModelState اضافه کنم یا به عنوان پاسخ یک درخواست Ajax ای استفاده کنم.
Action‌های لایه Presentation مورد نظر من هیچ کاری انجام نمی‌دهند؛ برای مثال اگر قرار است یکسری برچسب به یک مطلب اضافه شود این قضیه که کدام یک قبلا بودن یا جدید هستند و از این قبیل کارها در دل متد مثلا Create مرتبط با مطلب یا ویرایش آنها صورت می‌گیرد و در واقع در پیاده سازی آنها همان بررسی Null بودن یا این چنین بررسی‌ها انجام خواهد گرفت قطعا.
صحبت نهایی اینکه Application Service‌های مورد نظر من هر آنچه نیاز است را برای انجام یک use-case انجام خواهند داد و واقعا به عنوان مدخل ورودی سیستم عمل می‌کنند. حال مدخل ورودی سیستم مورد نظر شما شاید همان بالاترین لایه یا خارجی‌ترین آن باشد که در آن صورت قضیه متفاوت می‌باشد.
نظرات مطالب
پردازش‌های Async در Entity framework 6
من با خطای A second operation started... روبرو می‌شوم. وقتی لاگهای ثبت شده توسط Elmah را بررسی کردم، متوجه این جزییات شدم. 
   ...
   at System.Data.Entity.Infrastructure.IDbAsyncEnumerableExtensions.<FirstOrDefaultAsync>d__25`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   ...
   at MyApplication.ServiceLayer.EfServices.Content.BlogService.<GetBlogByIdForPublicViewAsync>d__24.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   ...
   at MyApplication.Controllers.BlogController.<Details>d__87.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
اکشن Details و متد GetBlogByIdForPublicViewAsync را بدین نحو تعریف کرده‌ام.  
public async Task<BlogViewModel> GetBlogByIdForPublicViewAsync(int blogId)
{
    var result = await _blogs
        .ProjectTo<BlogViewModel>()
        .FirstOrDefaultAsync(a => a.Id == blogId);
    return result;
}

public virtual async Task<ActionResult> Details(int id)
{
    var blog = await _blogService.GetBlogByIdForPublicViewAsync(id);
    return View("Details", blog);
}
با وجود استفاده از واژه‌ی await برای تمام رویه‌های غیرهمزمان، اما بازهم با همان خطا روبرو می‌شوم.
ممکن است لطفا بفرمایید کجا را اشتباه انجام داده‌ام؟  
نظرات مطالب
معماری لایه بندی نرم افزار #3
بعد از پیاده سازی UOW و لایه‌بندی نرم‌افزار به این این شکل که در مطلب فعلی توضیح داده شد،
 فرض کنید دو ویومدل زیر را داریم:
 public class PersonFormViewModel
    {
        public long Id { get; set; }
        public long RequestId { get; set; }
        [DisplayName("نام کاربری"), Required(ErrorMessage = "نام کاربری الزامی می‌باشد.")]
        public string Username { get; set; }
        public bool Accepted { get; set; }
        [DisplayName("مدل")]
        public string DeviceModel { get; set; }
        public DateTime? ExpireDate { get; set; }
        public RequestViewModel RequestViewModel { get; set; }
    }
public class RequestViewModel
    {
        public long Id { get; set; }
        public string Username { get; set; }
        [DisplayName("توضیحات")]
        [DataType(DataType.MultilineText)]
        public string Description { get; set; }
        public DateTime CreateDate { get; set; }
        public Nullable<long> DeviceId { get; set; }
        public Nullable<long> ParentId { get; set; }
        public long RequestTypeId { get; set; }
        public bool IsFinalized { get; set; }
        public virtual  PersonFormViewModel PersonFormViewModel { get; set; }
    }
سناریو به این شکل است که ما فرمی داریم برای ایحاد یک درخواست (RequestViewModel) که با ایجاد آن در واقع اطلاعات شخص (PersonFormViewModel) را نیز دریافت می‌کنیم.
برای افزودن RequestٰViewModel به دیتابیس این دو روش قابل پیاده‌سازی است:
روش اول: 
تنها RequestViewModel را از طریق RequestService اضافه می‌کنیم و به دلیل وجود PersonFormViewModel داخل RequestViewModel اطلاعات شخص به خودی خود داخل entity مربوطه اضافه می‌شود:
_requestService.Add(requestViewModel);
_uow.SaveChanges();
روش دوم:
ابتدا RequestViewModel را از طریق سرویس مربوطه اضافه می‌کنیم و بعد به طور جداگانه PersonViewModel را از طریق سرویس PersonFormService اضافه می‌کنیم:
var addedRequest = _requestService.Add(requestViewModel ); 
var personViewModel = requestViewModel .PersonFormViewModel; 
_personFormService.Add(personViewModel);
_uow.SaveChanges();
در حال حاضر روش درست کدام است؟
نظرات مطالب
پیاده سازی UnitOfWork به وسیله MEF
در مورد سوال اول که چرا CategoryMap رو به متد AddFromAssembly پاس دادم.
متد AddFromAssembly نیاز به یک Assembly دارد تا بتونه تمام کلاس هایی رو که از کلاس EntityTypeConfiguration ارث برده اند رو پیدا کنه و اونها رو به صورت خودکار به ModelBuilder اضافه کنه. به همین دلیل من Assembly کلاس CategoryMap رو به اون پاس دادم. دقت کنید که اگر من n تا کلاس Map دیگه هم توی این ClassLibrary داشتم باز توسط همین دستور این کار به صورت خودکار انجام می‌شد. (پیشنهاد می‌کنم تست کنید)
نکته: این متد برگرفته شده از متد AddFromAssembly در NHibernate Session Configuration   است.
البته بهتر است که یک کلاس پایه برای این کار بسازید و اون کلاس رو به AddFromAssembly پاس بدید.

در مورد سوال دوست عزیز مبنی بر اینکه متد Save رو در خود توابع Repository قرار دادم.
اگر به کد‌های نوشته شده دقت کنید من اصلا مفهومی به نام Repository رو پیاده سازی نکردم. به این دلیل که خود DbContext ترکیبی از Repository Pattern , UnitOfWork است. متد SaveChange صدا زده شده همان متد SaveChange در DbContext است.
فرض کنید من یک کلاس Business دیگر به صورت زیر داشتم.

public class MyBusiness : BusinessBase<Entity.MyEntity>
    {
        [ImportingConstructor]
        public MyBusiness  ( [Import( typeof( IUnitOfWork ) )] IUnitOfWork unitOfWork )
            : base( unitOfWork )
        {
        }
        public void Add(Entity.MyEntity entity)
        {
            UnitOfWork.Set<MyEntity>().Add(entity);
        }
    }
حالا کد کلاس Business Category به صورت زیر تغییر می‌کنه.
public class Category : BusinessBase<Entity.Category>
    {      
        [ImportingConstructor]
        public Category( [Import( typeof( IUnitOfWork ) )] IUnitOfWork unitOfWork )
            : base( unitOfWork )
        {
        }

        public override void Add( Entity.Category entity )
        {
            new MyBusiness().Add( new Entity.MyEntity() );
            UnitOfWork.Set<Entity.Category>().Add( entity );
            UnitOfWork.SaveChanges();
        }
    }
همان طور که می‌بینید فقط یک بار متد SaveChange فراخوانی شده است. Virtual کردن متد BusinessBase دقیقا به همین دلیل است.

نظرات مطالب
وی‍‍ژگی های پیشرفته ی AutoMapper - قسمت دوم
سلام ، مشکلی که من با Automapper دارم اینه 
 کلاسی به شکل زیر دارم 
 public class ProductType:BaseEntity
    {
        #region Field
        private string persianTitle;
        private string englishTitle;
        private IList<Product> products;
        #endregion
        #region Memebr
        public string PersianTitle
        {
            get
            {
                return (persianTitle);
            }
            set
            {
                persianTitle = Microsoft.Security.Application.Encoder.HtmlEncode(value);
            }
        }
        public string EnglishTitle
        {
            get
            {
                return (englishTitle);
            }
            set
            {
                englishTitle = Microsoft.Security.Application.Encoder.HtmlEncode(value);
            }
        }
        public virtual IList<Product> Products
        {
            get
            {
                return (products);
            }
            set
            {
                products = value;
            }
        }
        #endregion
    }
و خوب کلاسی با عنوان Product  هم موجوده  با کدی به این شکل سعی در آپدیت کردن این کلاس دارم
[HttpPost]
        public ActionResult Update(ProductTypeViewModel productTypeViewModel)
        {
            if (productTypeViewModel.ExaminId())
            {
                ProductType productType;
                productType = _productType.Find(x => x.Id == productTypeViewModel.Id);
                AutoMapper.Mapper.Map(productTypeViewModel, productType);
                _uow.SaveChanges();
            }
            return RedirectToAction("Index");
        }
متاسفانه خطا رخ میده ، خطایی مربوط به Context ظاهرا اینم پیام خطا 
issing type map configuration or unsupported mapping.

Mapping types:
ProductTypeViewModel -> ProductType_5334DF7BAFBE780DF5328E2D6DF2A0DC3350F23340BE2EE2FC506AE9EDEC38DA
MvcUserInterface.Areas.Management.Models.ProductTypeViewModel -> System.Data.Entity.DynamicProxies.ProductType_5334DF7BAFBE780DF5328E2D6DF2A0DC3350F23340BE2EE2FC506AE9EDEC38DA

Destination path:
ProductType_5334DF7BAFBE780DF5328E2D6DF2A0DC3350F23340BE2EE2FC506AE9EDEC38DA

Source value:
MvcUserInterface.Areas.Management.Models.ProductTypeViewModel
ممنون میشم اگه کسی تجربه ای داره کمکم کنه من برای پیاده سازی لایه‌های سرویس ، دامین و دیتا از روشی که آقای نصیری گفته استفاده کردم . ویرایش کلاس هایی که دارای عضوی به صورت لیست از کلاس دیگر هستند چگونه باید باشه ؟ برای map کردن این کلاس‌ها کار خاصی باید انجام بشه ؟
مطالب
مدیریت هدایت خودکار صفحات در حین خطاهای عملیاتی ای‌جکسی در ASP.NET MVC
قطعه کد زیر را در نظر بگیرید :
     [HttpPost,AjaxOnly, ValidateAntiForgeryToken]
        public virtual JsonResult Create(AddDeviceGroupViewModel deviceGroupViewModel)
        {
        
            if (ModelState.IsNotValid())
            {
                Response.StatusCode = (int)HttpStatusCode.BadRequest;
                return Json(new { success = false, message = ModelState.FirstErrorMessage(), notificationType = NotificationType.Error }, JsonRequestBehavior.AllowGet);
            }
            var result = _deviceGroupService.Add(deviceGroupViewModel);

           // other codes

        }
اکشن متد فوق به صورت زیر فراخوانی می‌شود :
@using (Ajax.BeginForm(MVC.Admin.DeviceGroup.Create(), 
new AjaxOptions { HttpMethod = "POST", OnSuccess = "saveAjaxForm", OnFailure = "SaveFailure" }))
{
// form content
}
و تابع جاوا اسکریپت SaveFailure  به صورت زیر پیاده سازی شده بود :
function SaveFailure(data) {
  
    $("button[type=submit]").prop('disabled', false);
    var result = $.parseJSON(data.responseText);
    showMessage(result.message, result.notificationType);
}
کار تابع فوق، فعال کردن مجدد دکمه ثبت و نمایش پیغامی به کاربر می‌باشد. قطعه کد فوق بدون هیچ مشکلی اجرا می‌شد تا اینکه تمامی اکشن متد‌هایی که به صورت ای‌جکس به صورت اکشن متد فوق پیاده سازی شده بودند، از کار افتادند.
مشکل به وجود آمده حاصل اضافه شدن تگ‌های زیر به وب کانفیگ بود :
<httpErrors errorMode="Custom">
      <remove statusCode="404"/>
      <error statusCode="404" path="/Error/NotFound" responseMode="ExecuteURL"/>
</httpErrors>
بعد از افزودن کد‌های فوق وقتی برنامه به خط زیر می‌رسید، سعی در انتقال به کنترلر Error می‌کرد:
Response.StatusCode = (int)HttpStatusCode.BadRequest;

و در خروجی تنها مقداری که به سمت کاربر برگشت داده می‌شد، مقدار BadRequest بود و خط زیر باعث خطا و توقف برنامه می‌شد:
    var result = $.parseJSON(data.responseText);
با کامنت کامنت کردن کدهای اضافه شده در Web.config مشکل فوق رفع خواهد شد.
همچنین در صورتیکه قصد داشتید تگ‌های فوق را در web.config داشته باشید (جهت هندل کردن صفحات پیدا نشده) می‌توانید از مقدار دهی TrySkipIISCustomError با true این مشکل را رفع کنید.
  Response.TrySkipIisCustomErrors = true;

روشی دیگر:
<system.webServer>
    <httpErrors errorMode="DetailedLocalOnly" existingResponse="PassThrough" />
مطالب
پیاده سازی یک سیستم دسترسی Role Based در Web API و AngularJs - بخش دوم
در بخش پیشین مروری اجمالی را بر روی یک سیستم مبتنی بر نقش کاربر داشتیم. در این بخش تصمیم داریم تا به جزئیات بیشتری در مورد سیستم دسترسی ارائه شده بپردازیم.
همانطور که گفتیم ما به دو صورت قادر هستیم تا دسترسی‌های (Permissions) یک سیستم را تعریف کنیم. روش اول این بود که هر متد از یک کنترلر، دقیقا به عنوان یک آیتم در جدول Permissions قرار گیرد و در نهایت برای تعیین نقش جدید، مدیر باید جزء به جزء برای هر نقش، دسترسی به هر متد را مشخص کند. در روش دوم مجموعه‌ای از API Methodها به یک دسترسی تبدیل شده است.
مراحل توسعه این روش به صورت زیر خواهند بود:
  1. توسعه پایگاه داده سیستم دسترسی مبتنی بر نقش
  2. توسعه یک Customized Filter Attribute بر پایه Authorize Attribute
  3. توسعه سرویس‌های مورد استفاده در Authorize Attribute
  4. توسعه کنترلر Permissions: تمامی APIهایی که در جهت همگام سازی دسترسی‌ها بین کلاینت و سرور را بر عهده دارند در این کنترلر توسعه داده میشود.
  5. توسعه سرویس مدیریت دسترسی در کلاینت توسط AngularJS

توسعه پایگاه داده

در این مرحله پایگاه داده را به صورت Code First پیاده سازی مینماییم. مدل Permissions به صورت زیر میباشد:
    public class Permission
    {
        [Key]
        public string Id { get; set; }
        public string Title { get; set; }
        public string Description { get; set; }
        public string Area { get; set; }
        public string Control { get; set; }
        public virtual ICollection<Role> Roles { get; set; }
    }
در مدل فوق همانطور که مشاهده میکنید یک ارتباط چند به چند، به Roles وجود دارد که در EF به صورت توکار یک جدول اضافی Junction اضافه خواهد شد با نام RolesPermissions. Area و Control نیز طبق تعریف شامل محدوده مورد نظر و کنترل‌های روی ناحیه در نظر گرفته می‌شوند. به عنوان مثال برای یک سایت فروشگاهی، برای بخش محصولات می‌توان حوزه‌ها و کنترل‌ها را به صورت زیر تعریف نمود:
 Control Area 
 view  products
 add  products
 edit  products
 delete  products

با توجه به جدول فوق همانطور که مشاهده می‌کنید تمامی آنچه که برای دسترسی Products مورد نیاز است در یک حوزه و 4 کنترل گنجانده میشود. البته توجه داشته باشید سناریویی که مطرح کردیم برای روشن سازی مفهوم ناحیه یا حوزه و کنترل بود. همانطور که میدانیم در AngularJS تمامی اطلاعات توسط APIها فراخوانی می‌گردند. از این رو یک موهبت دیگر این روش، خوانایی مفهوم حوزه و کنترل نسبت به نام کنترلر و متد است.

مدل Roles را ما به صورت زیر توسعه داده‌ایم:

    public class Role
    {
        [Key]
        public string Id { get; set; }
        public string Title { get; set; }
        public string Description { get; set; }
        public virtual ICollection<Permission> Permissions { get; set; }
        public virtual ICollection<User> Users { get; set; }
    }

در مدل فوق می‌بینید که دو رابطه چند به چند وجود دارد. رابطه اول که همان Permissions است و در مدل پیشین تشریح شد. رابطه‌ی دوم رابطه چند به چند بین کاربر و نقش است. چند کاربر قادرند یک نقش در سیستم داشته باشند و همینطور چندین نقش میتواند به یک کاربر انتساب داده شود.

ما در این سیستم از ASP.NET Identity 2.1 استفاده و کلاس IdentityUser را override کرده‌ایم. در مدل override شده، برخی اطلاعات جدید کاربر، به جدول کاربر اضافه شده‌اند. این اطلاعات شامل نام، نام خانوادگی، شماره تماس و ... می‌باشد.

public class ApplicationUser : IdentityUser
    {
        [MaxLength(100)]
        public string FirstName { get; set; }
        [MaxLength(100)]
        public string LastName { get; set; }
        public bool IsSysAdmin { get; set; }
        public DateTime JoinDate { get; set; }

        public virtual ICollection<Role> Roles { get; set; }
    }

در نهایت تمامی این مدل‌ها به وسیله EF Code First پایگاه داده سیستم ما را تشکیل خواهند داد.

توسعه یک Customized Filter Attribute بر پایه Authorize Attribute 

اگر در مورد Custom Filter Attributeها اطلاعات ندارید نگران نباشید! مقاله «فیلترها در MVC» تمامی آنچه را که باید در اینباره بدانید، به شما خواهد گفت. همچنین در  مقاله وب سایت  مایکروسافت به صورت عملی (ایجاد یک سیستم Logger) همه چیز را برای شما روشن خواهد کرد. حال بپردازیم به Filter Attribute نوشته شده که قرار است وظیفه پیش پردازش تمامی درخواست‌های کاربر را انجام دهد. در ابتدا کمی در اینباره بگوییم که این فیلتر قرار است چه کاری را دقیقا انجام دهد!
این فیلتر قرار است پیش از پردازش هر API Method، درخواست کاربر را با استفاده از نقشی که او در سیستم دارد، بررسی نماید که آیا کاربر به API اجازه دسترسی دارد یا خیر. برای این کار باید ما در ابتدا نقش‌های کاربر را بررسی نماییم. پس از اینکه نقش‌های کاربر واکشی شدند، باید بررسی کنیم آیا نقشی که کاربر دارد، شامل این حوزه و کنترل بوده است یا خیر؟ Area و Control دو پارامتری هستند که در سیستم پیش از هر متد، Hard Code شده‌اند و در ادامه نمونه‌ای از آن را نمایش خواهیم داد.
    public class RBACAttribute : AuthorizeAttribute
    {
        public string Area { get; set; }
        public string Control { get; set; }
        AccessControlService _AccessControl = new AccessControlService();
        public override void OnAuthorization(HttpActionContext actionContext)
        {
            var userId = HttpContext.Current.User.Identity.GetCurrentUserId();
            // If User Ticket is Not Expired
            if (userId == null || !_AccessControl.HasPermission(userId, this.Area, this.Control))
            {
                actionContext.Response = new HttpResponseMessage(HttpStatusCode.Unauthorized);
            }
        }
    }
در خط پنجم، سرویس AccessControl را فراخوانی کرده‌ایم که در ادامه به پیاده سازی آن نیز خواهیم پرداخت. متد HasPermission از این سرویس دو پارامتر id کاربر و Area و Control را دریافت میکند و با استفاده از این سه پارامتر بررسی میکند که آیا کاربر جاری به این بخش دسترسی دارد یا خیر؟ در صورت منقضی شدن ticket کاربر و یا عدم دسترسی، سرور Unauthorized status code را به کاربر باز می‌گرداند.
بلوک زیر استفاده از این فیلتر را نمایش می‌دهد:
[HttpPost]
[Route("ChangeProductStatus")]
[RBAC(Area = "products", Control = "edit")]
public async Task<HttpResponseMessage> ChangeProductStatus(StatusCodeBindingModel model)
{
// Method Body
}
همانطور که مشاهده می‌کنید کافیست RBAC را با دو پارامتر، پیش از متد نوشت. به صورت خودکار پیش از فراخوانی این متد که وظیفه تغییر وضعیت کالا را بر عهده دارد، فیلتر نوشته شده فراخوانی خواهد شد.
در بخش بعدی به بیان ادامه جریان و توسعه سرویس Access Control خواهیم پرداخت.
مطالب
به روز رسانی ساده‌تر اجزاء ارتباطات در EF Code first به کمک GraphDiff
دو نوع حالت کلی کارکردن با EF وجود دارند: متصل و منقطع.
در حالت متصل مانند برنامه‌های متداول دسکتاپ، Context مورد استفاده در طول عمر صفحه‌ی جاری زنده نگه داشته می‌شود. در این حالت اگر شیءایی اضافه شود، حذف شود یا تغییر کند، توسط EF ردیابی شده و تنها با فراخوانی متد SaveChanges، تمام این تغییرات به صورت یکجا به بانک اطلاعاتی اعمال می‌شوند.
در حالت غیرمتصل مانند برنامه‌های وب، طول عمر Context در حد طول عمر یک درخواست است. پس از آن از بین خواهد رفت و دیگر فرصت ردیابی تغییرات سمت کاربر را نخواهد یافت. در این حالت به روز رسانی کلیه تغییرات انجام شده در خواص و همچنین ارتباطات اشیاء موجود، کاری مشکل و زمانبر خواهد بود.
برای حل این مشکل، کتابخانه‌ای به نام GraphDiff طراحی شده‌است که صرفا با فراخوانی متد UpdateGraph آن، به صورت خودکار، محاسبات تغییرات صورت گرفته در اشیاء منقطع و اعمال آن‌ها به بانک اطلاعاتی صورت خواهد گرفت. البته ذکر متد SaveChanges پس از آن نباید فراموش شود.


اصطلاحات بکار رفته در GraphDiff

برای کار با GraphDiff نیاز است با یک سری اصطلاح آشنا بود:

Aggregate root
گرافی است از اشیاء به هم وابسته که مرجع تغییرات داده‌ها به شمار می‌رود. برای مثال یک سفارش و آیتم‌های آن‌را درنظر بگیرید. بارگذاری آیتم‌های سفارش، بدون سفارش معنایی ندارند. بنابراین در اینجا سفارش aggregate root است.

AssociatedCollection/AssociatedEntity
حالت‌های Associated به GraphDiff اعلام می‌کنند که اینگونه خواص راهبری تعریف شده، در حین به روز رسانی aggregate root نباید به روز رسانی شوند. در این حالت تنها ارجاعات به روز رسانی خواهند شد.
اگر خاصیت راهبری از نوع ICollection است، حالت AssociatedCollection و اگر صرفا یک شیء ساده است، از AssociatedEntity استفاده خواهد شد.

OwnedCollection/OwnedEntity
حالت‌های Owned به GraphDiff اعلام می‌کنند که جزئیات و همچنین ارجاعات اینگونه خواص راهبری تعریف شده، در حین به روز رسانی aggregate root باید به روز رسانی شوند.


دریافت و نصب GraphDiff

برای نصب خودکار کتابخانه‌ی GraphDiff می‌توان از دستور نیوگت ذیل استفاده کرد:
 PM> Install-Package RefactorThis.GraphDiff


بررسی GraphDiff در طی یک مثال

مدل‌های برنامه آزمایشی، از سه کلاس ذیل که روابط many-to-many و one-to-many با یکدیگر دارند، تشکیل شده‌است:
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations.Schema;

namespace GraphDiffTests.Models
{
    public class BlogPost
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public string Content { get; set; }

        public virtual ICollection<Tag> Tags { set; get; } // many-to-many

        [ForeignKey("UserId")]
        public virtual User User { get; set; }
        public int UserId { get; set; }

        public BlogPost()
        {
            Tags = new List<Tag>();
        }
    }

    public class Tag
    {
        public int Id { set; get; }

        [StringLength(maximumLength: 450), Required]
        public string Name { set; get; }

        public virtual ICollection<BlogPost> BlogPosts { set; get; } // many-to-many

        public Tag()
        {
            BlogPosts = new List<BlogPost>();
        }
    }

    public class User
    {
        public int Id { get; set; }
        public string Name { get; set; }

        public virtual ICollection<BlogPost> BlogPosts { get; set; } // one-to-many
    }
}
- یک مطلب می‌تواند چندین برچسب داشته باشد و هر برچسب می‌تواند به چندین مطلب انتساب داده شود.
- هر کاربر می‌تواند چندین مطلب ارسال کند.

در این حالت، Context برنامه چنین شکلی را خواهد یافت:
using System;
using System.Data.Entity;
using GraphDiffTests.Models;

namespace GraphDiffTests.Config
{
    public class MyContext : DbContext
    {
        public DbSet<User> Users { get; set; }
        public DbSet<BlogPost> BlogPosts { get; set; }
        public DbSet<Tag> Tags { get; set; }


        public MyContext()
            : base("Connection1")
        {
            this.Database.Log = sql => Console.Write(sql);
        }
    }
}
به همراه تنظیمات به روز رسانی ساختار بانک اطلاعاتی به صورت خودکار:
using System.Data.Entity.Migrations;
using System.Linq;
using GraphDiffTests.Models;

namespace GraphDiffTests.Config
{
    public class Configuration : DbMigrationsConfiguration<MyContext>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
        }

        protected override void Seed(MyContext context)
        {
            if(context.Users.Any())
                return;

            var user1 = new User {Name = "User 1"};
            context.Users.Add(user1);

            var tag1 = new Tag { Name = "Tag1" };
            context.Tags.Add(tag1);

            var post1 = new BlogPost { Title = "Title...1", Content = "Content...1", User = user1};
            context.BlogPosts.Add(post1);

            post1.Tags.Add(tag1);

            base.Seed(context);
        }
    }
}
در متد Seed آن یک سری اطلاعات ابتدایی ثبت شده‌اند؛ یک کاربر، یک برچسب و یک مطلب.




در این تصاویر به Id هر کدام از رکوردها دقت کنید. از آن‌ها در ادامه استفاده خواهیم کرد.
در اینجا نمونه‌ای از نحوه‌ی استفاده از GraphDiff را جهت به روز رسانی یک Aggregate root ملاحظه می‌کنید:
            using (var context = new MyContext())
            {
                var user1 = new User { Id = 1, Name = "User 1_1_1" };
                var post1 = new BlogPost { Id = 1, Title = "Title...1_1", Content = "Body...1_1",
                    User = user1, UserId = user1.Id };
                var tags = new List<Tag>
                {
                    new Tag {Id = 1, Name = "Tag1_1"},
                    new Tag {Id=12, Name = "Tag2_1"},
                    new Tag {Name = "Tag3"},
                    new Tag {Name = "Tag4"},
                };
                tags.ForEach(tag => post1.Tags.Add(tag));

                context.UpdateGraph(post1, map => map
                    .OwnedEntity(p => p.User)
                    .OwnedCollection(p => p.Tags)
                    );

                context.SaveChanges();
            }
پارامتر اول UpdateGraph، گرافی از اشیاء است که قرار است به روز رسانی شوند.
پارامتر دوم آن، همان مباحث Owned و Associated بحث شده در ابتدای مطلب را مشخص می‌کنند. در اینجا چون می‌خواهیم هم برچسب‌ها و هم اطلاعات کاربر مطلب اول به روز شوند، نوع رابطه را Owned تعریف کرده‌ایم.
در حین کار با متد UpdateGraph، ذکر Idهای اشیاء منقطع از Context بسیار مهم هستند. اگر دستورات فوق را اجرا کنیم به خروجی ذیل خواهیم رسید:




- همانطور که مشخص است، چون id کاربر ذکر شده و همچنین این Id در post1 نیز درج گردیده است، صرفا نام او ویرایش گردیده است. اگر یکی از موارد ذکر شده رعایت نشوند، ابتدا کاربر جدیدی ثبت شده و سپس رابطه‌ی مطلب و کاربر به روز رسانی خواهد شد (userId آن به userId آخرین کاربر ثبت شده تنظیم می‌شود).
- در حین ثبت برچسب‌ها، چون Id=1 از پیش در بانک اطلاعاتی موجود بوده، تنها نام آن ویرایش شده‌است. در سایر موارد، برچسب‌های تعریف شده صرفا اضافه شده‌اند (چون Id مشخصی ندارند یا Id=12 در بانک اطلاعاتی وجود خارجی ندارد).
- چون Id مطلب مشخص شده‌است، فیلدهای عنوان و محتوای آن نیز به صورت خودکار ویرایش شده‌اند.

و ... تمام این کارها صرفا با فراخوانی متدهای UpdateGraph و سپس SaveChanges رخ داده‌است.


کدهای کامل این مثال را از اینجا می‌توانید دریافت کنید:
GraphDiffTests.zip