‫۷ سال و ۱۲ ماه قبل، پنجشنبه ۸ مهر ۱۳۹۵، ساعت ۲۲:۱۱
در اینجا هش توکن‌ها ذخیره می‌شوند؛ در قسمت «الف) سرویس TokenStoreService » و همچنین در متد TokenEndpointResponse  که دسترسی به آن وجود دارد (توضیحات انتهای قسمت «پیاده سازی قسمت لاگین و صدور access token »). ذخیره سازی هش، هم جستجوی سریعی را به همراه خواهد داشت (چون طول آن کوتاه و ثابت است و امکان تعریف ایندکس بر روی آن وجود دارد. به علاوه موارد منقضی شده هم حذف می‌شوند از بانک اطلاعاتی) و هم نیازی به ذخیره‌ی اطلاعات اضافه‌تری در توکن نهایی ندارد و حجم آن‌را افزایش نمی‌دهد و چون در اختیار کاربر نیست، حتی در صورت افشای کلیدهای سمت سرور، قابل تولید در سمت کلاینت نیست. همچنین بحث تعیین اعتبار توکن‌ها صرفا مرتبط با تائید محل صدور آن‌ها نیست. در سرویس TokenStoreService، وضعیت فعال بودن یا نبودن کاربر، تغییر سطح دسترسی‌ها، تغییر اطلاعات پروفایل او و همچنین عملیات خروج از سیستم او و فاقد اعتبارشدن توکن آن جلسه‌ی کاری نیز بررسی می‌شوند. 
‫۷ سال و ۱۲ ماه قبل، چهارشنبه ۷ مهر ۱۳۹۵، ساعت ۲۱:۱۸
من اساسا مخالف هر نوع generic repository هستم. شما الان یک کد «ساده‌» و «زیبای» EF را تبدیل به یک کد پیچیده‌ی غیرقابل درک کردید. این نه پیشرفتی است و نه بر اساس هیچکدام از الگوهای برنامه نویسی.
در این زمینه یک سری مطلب در سایت هستند برای مطالعه:
-Repository‌ها روی UnitOfWork ایده خوبی نیستند
- پیاده سازی generic repository یک ضد الگو است 
- استفاده از الگوی Repository در EF Code First کار اضافی است.
- 5 نکته برای بهبود کیفیت کدهای برنامه‌ای که از یک ORM استفاده می‌کند  
‫۷ سال و ۱۲ ماه قبل، چهارشنبه ۷ مهر ۱۳۹۵، ساعت ۱۷:۲۲
Include باید قبل از Cacheable و حتی قبل از FindAll شما فراخوانی شود. باید پس از ارجاعی به dbSet فراخوانی شود، تا EF بتواند چرخش کاری صحیح آن‌را تشکیل دهد. برای بار دوم فراخوانی، پس از Cacheable، شما یک لیست ساده‌ی LINQ to Objects را خواهید داشت که از Context منقطع است و صرفا از کش خوانده شده‌است. بنابراین فراخوانی متد Include بر روی آن مفهومی ندارد.
‫۷ سال و ۱۲ ماه قبل، سه‌شنبه ۶ مهر ۱۳۹۵، ساعت ۱۳:۴۰
- شما در هر دو حالت، دارای لیست منوهایی با 5 آیتم هستید. یعنی خروجی نهایی هر دو کوئری یکی هست و متد Cacheable درست عمل کرده‌است.
- اینکه در کوئری بعدی LINQ to Objects شما، در حالت بدون Cacheable، «امکانات debug visualizer ویژوال استودیو» موفق به تشکیل روابط شده‌است، صرفا به عدم فراخوانی متد AsNoTracking در کوئری غیر کش شده‌ی شما بر می‌گردد. متد AsNoTracking جهت کاهش سربار کوئری‌های EF و حذف پروکسی‌های آن به صورت خودکار توسط متد  Cacheable اعمال می‌شود؛ چون این نوع کوئری‌های کش شده صرفا مختص به گزارشگیری هستند.
- اگر AsNoTracking فراخوانی شود، برای تشکیل روابط صرفا باید از متدهای Include و ThenInclude برای واکشی سطوح دیگر به هم مرتبط استفاده کنید. همچنین هر Include یا ThenInclude فقط یک سطح را واکشی می‌کند.
«...
بدیهی است در اینجا هنوز روش‌های Include و ThenInclue هم جواب می‌دهند؛ اما چون Lazy loading فعال نیست، عملا نمی‌توان تمام زیر ریشه‌ها را یافت ...»

در کل، کوئری دوم شما (حاصل نهایی واکشی تمام عناصر یک جدول) متصل به Context نیست و LINQ to Objects است. بنابراین زمانیکه لیست کامل عناصر را در حافظه‌ی سمت کلاینت دارید (و در اینجا هر عملی بر روی این لیست دوم، نیازی به رفت و برگشت به بانک اطلاعاتی را ندارد)، تشکیل درخت آن‌ها کار مشکلی نیست؛ چون هر آیتم، توسط خاصیت MenuId، به قبلی متصل است و یا خیر. در مثال زیر، لیست نهایی، بر اساس ReplyIdها (دقیقا همان اطلاعات اصلی که در بانک اطلاعاتی ذخیره می‌شود)، حاوی لیست Children چند سطحی خواهد شد. زمانی هم که این لیست را داشتید، از کلاس TreeViewHelper برای نمایش آن استفاده کنید.
        void buildTreeLinqToObjects()
        {
            var comment1 = new BlogComment { Id = 1, Body = "نظر من این است که" };
            var comment12 = new BlogComment { Id = 2, Body = "پاسخی به نظر اول", ReplyId = 1 };
            var comment121 = new BlogComment { Id = 3, Body = "پاسخی به پاسخ به نظر اول", ReplyId = 2 };

            var comment2 = new BlogComment { Id = 4, Body = "نظر من این بود که" };
            var comment22 = new BlogComment { Id = 5, Body = "پاسخی به نظر قبلی", ReplyId = 4 };
            var comment221 = new BlogComment { Id = 6, Body = "پاسخی به پاسخ به نظر من اول", ReplyId = 5 };

            var list = new List<BlogComment>
            {
                comment1, comment12, comment121,
                comment2, comment22, comment221
            };

            foreach (var item in list)
            {
                if (item.ReplyId == null)
                {
                    continue;
                }

                var parent = list.First(x => x.Id == item.ReplyId.Value);
                parent.Children.Add(item);
            }

        }
‫۷ سال و ۱۲ ماه قبل، دوشنبه ۵ مهر ۱۳۹۵، ساعت ۱۵:۴۲
- Collation بانک اطلاعاتی ایجاد شده، بر اساس collation «کل سرور» تنظیم می‌شود. برای مثال بر روی سیستم من Server collation به Persian_100_CI_AS تنظیم شده‌است. بنابراین بانک اطلاعاتی ایجاد شده‌ی در اینجا هم دقیقا همین Collation را دارد (امتحان کردم).
/* Identify SQL Server Collation Settings*/
USE Master
GO
SELECT SERVERPROPERTY('collation') AS SQLServerCollation
GO
 - Collation، ارتباطی به نحوه‌ی ذخیره شدن اطلاعات یونیکد ندارد. بیشتر هدف آن sort صحیح اطلاعات است و همچنین مشخص سازی نحوه‌ی مقایسه‌ی عبارات و حساس بودن به بزرگی و کوچکی حروف. شما در Collation فارسی، هم ی فارسی و هم ی عربی را می‌توانید بدون مشکل ثبت کنید. اگر این Collation وجود نداشت، شبیه به SQLite، در مرتب سازی حروف فارسی، عملیات نهایی بر اساس کد اسکی آن‌ها انجام می‌شد و در این حالت مثلا «پ» را در انتهای لیست مشاهده می‌کردید.
 - اگر مشکل ثبت اطلاعات یونیکد را داشت، شما در بانک اطلاعاتی فقط ????? را مشاهده می‌کردید و نه هیچ چیز دیگری را و نه اینکه قسمتی درست ثبت شود و قسمتی نادرست.
 - ویژوال استودیو عموما بر مبنای «تنظیمات محلی سیستم عامل شما» فایل‌ها را ذخیره می‌کند. اگر می‌خواهید این مورد را همواره به UTF8 تغییر دهید، از افزونه‌ی ForceUTF8 (with BOM) استفاده کنید.
اگر علاقمند بودید تا کار افزودن مهاجرت‌ها، به همراه تولید خودکار نام فایل، بر اساس تاریخ و ساعت روز باشد، می‌توان از دستورات ذیل در خط فرمان استفاده کرد (و یا درست کردن یک فایل bat. برای آن):
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c_%%a_%%b)
For /f "tokens=1-2 delims=/:" %%a in ("%TIME: =0%") do (set mytime=%%a%%b)
dotnet ef --configuration Release --startup-project ../ProjName/ migrations add V%mydate%_%mytime%