نظرات مطالب
آشنایی با الگوی M-V-VM‌ - قسمت پنجم
آقای نصیری من با توجه به مطالب این فصل یک سوال داشتم: وقتی ما از Entity Freamework Code First استفاده میکنیم، و تمام کلاس‌های مربوطه را داخل یک پروژه دیگر به اسم DAL قرار میدهیم، روش درست این است که به ازای هر موجودیت یک کلاس دیگر ساخته و INotifyPropertyChanged و ... را در آن پیاده سازی کنیم؟
به عنوان مثال وقتی کلاس Code First ما Customer می‌باشد ما یک کلاس دیگر مثلاً به اسم CustomerModel بسازیم (برای پیاده سازی INotifyPropertyChanged و IDataErrorInfo و ...) و بعد هنگام انجام عملیات (ثبت و ویرایش و حذف) این دو کلاس رو به هم Map کنیم؟
ممنون.
نظرات مطالب
استفاده از چندین Context در EF 6 Code first
ایده کار، این بود که قسمتی را مثلا توسط یک کلاس پایه، یا یک اینترفیس خالی علامتگذاری کنید و سپس اطلاعات آن‌را تک تک به متد Entity مربوط به DbModelBuilder ارسال کنید. همین ایده را در متد Seed هم می‌شود پیاده سازی کرد. یک اینترفیس خالی را مثلا به نام IِMySeed تعریف کنید و به کلاس دلخواهی انتساب دهید (یا از MEF استفاده کنید). سپس اینطرف با Reflection این نوع کلاس‌ها را بارگذاری کرده و Context متد Seed را به طراحی انجام شده، برای عملیات نهایی و دلخواه ارسال کنید.
نظرات مطالب
Blazor 5x - قسمت نهم - مبانی Blazor - بخش 6 - ساده سازی تعاریف ویژگی‌های المان‌ها و انتقال پارامترها به چندین زیر سطح
یک نکته‌ی تکمیلی: بلیزر به ازای هرکامپوننتی که دریافت کننده‌ی مقدار آبشاری است، یک نوتیفیکیشن اطلاع رسانی تنظیم میکند. هنگامیکه یک مقدار آبشاری تغییر می‌کند، مقدار جدید به درخت کامپوننت فرستاده می‌شود و تمام اجزایی که از آن استفاده می‌کنند به‌روزرسانی می‌شوند. بنابراین، Blazor باید به طور مداوم در حال چک کردن این مقدار باشد. این کار در یک برنامه‌ی بزرگ می‌تواند کارآیی را کاهش دهد . اگر CascadeVaue پس از اولین مقداردهی، مقادیرش دیگر هرگز تغییر نکند، می‌توانیم این بررسی مداوم را متوقف کنیم؛ بوسیله‌ی پارامتر IsFixed که در  CascadingValue وجود دارد. این پارامتر به طور پیش فرض روی false تنظیم شده است؛ اما اگر روی true تنظیم شود، Blazor بررسی مداوم را انجام نمی‌دهد. یکی از مواردی که IsFixed کاربرد دارد در ارسال خواص مشترک کامپوننتها از سمت  MainLayout  به سایر کامپوننتها میباشد.
<CascadingValue Value="this" IsFixed="true">
  main
</CascadingValue>
نظرات مطالب
کار با کلیدهای اصلی و خارجی در EF Code first
سلام
در سناریویی که من دارم باید دو جدول مستر دیتیل رو بصورت یک درخت در WPF نمایش بدم، رابطه‌ی چند به چند بین مدل Master و Detail برقرار شده پس بنابراین هر مدل از نوع Detail میتونه در چندین Master قرار داشته باشه!
در WPF با اضافه کردن یک Detail به لیست فرزندان Master به راحتی اینکار انجام میشه ولی مشکل اینجاست که به دلیل ویژگی‌های Binding در WPF، با ویرایش یکی از Detail‌ها تمام detail‌های موجود در Master های دیگه هم تغییر میکنند.
برای رفع این مشکل من یک کپی از هر Detailهای بعدی می‌میخواهند در یک Master قرار بگیرند درست میکنم و Id اونها رو برابر قرار میدم ولی به ازای هر Detail اضافه شده با وجود یکی بودن Id اونها یک سطر جدید در جدول Detail‌ها ایجاد میشه!
برای جلوگیری از ایجاد شی جدید به ازای اشیا با id‌های مشابه باید چکار کرد؟!
نظرات مطالب
مباحث تکمیلی مدل‌های خود ارجاع دهنده در EF Code first
- این خروجی SQL لاگ شده مطلب جاری (با تمام توضیحات و نگاشت‌های آن) توسط برنامه مطمئن SQL Server Profiler است:
SELECT 
[Extent1].[Id] AS [Id], 
[Extent1].[Body] AS [Body], 
[Extent1].[ReplyId] AS [ReplyId]
FROM [dbo].[BlogComments] AS [Extent1]
منطقی هم هست. چون در ToList اول، کار با دیتابیس تمام و قطع می‌شود. ToList دوم سمت کلاینت اجرا می‌شود. یعنی تشکیل درخت نهایی توسط امکانات LINQ to Objects انجام می‌شود و نه هیچ کار اضافه‌ای در سمت سرور.
- اگر اینجا join اضافی پیدا کردید ... حتما مشکلی در تنظیمات نگاشت‌ها دارید.
- اگر duplicate reader دارید شاید بخاطر lazy loading سایر خواص راهبری است که تعریف کردید مانند User و EditByUser و غیره. این‌ها اگر قرار است نمایش داده شوند، پیش از ToList اول باید توسط متد الحاقی Include به صورت eager loading تعریف شوند تا lazy loading و duplicate reader نداشته باشید.
- برای فیلتر فیلدهای اضافی، پیش از ToList اول، با استفاده از Projection و نوشتن یک Select، موارد مورد نیاز را انتخاب کنید.
نظرات مطالب
کمپین ضد IF !
توضیحات تکمیلی:
سؤال : آیا refactoring صورت گرفته در مطلب فوق از نوع تزریق وابستگی‌ها (dependency injection) بود؟
پاسخ: خیر.
پیاده سازی الگوی تزریق وابستگی‌ها زمانی معنا پیدا می‌کند که شما حداقل 2 کلاس داشته باشید (مطلب فوق با یک کلاس شروع شد)، همچنین این دو کلاس ارجاعی به یکدیگر داشته باشند و اصطلاحا به هم گره خورده باشند.

سؤال : چگونه در یک پروژه بزرگ می‌توان نیاز به پیاده سازی الگوی تزریق وابستگی‌ها را تشخیص داد؟
پاسخ:
آیا نسخه‌ی ultimate ویژوال استودیوی 2010 بر روی سیستم شما نصب است؟
اگر بله: (نصب است)
برای نمونه به مطلب Discovering Circular References مراجعه کنید.

اگر خیر: (نصب نیست)
در این حالت از ابزار رایگانی به نام .NET Architecture Checker می‌توانید استفاده کنید. همان نمودارهای نسخه‌ی ultimate ویژوال استودیو را برای شما ترسیم خواهد کرد.

سؤال : آیا می‌توان از کتابخانه‌های تزریق وابستگی‌ها و فریم ورک‌های مرتبط، جهت مدیریت ساده‌تر قسمت آخر مطلب فوق یعنی تامین پیاده سازی‌های اینترفیس‌هایی که قرار است در زمان اجرا استفاده شوند، کمک گرفت؟
پاسخ: بله.
این مورد یکی از کاربردهای متداول این ابزارها است (برای مثال ساخت برنامه‌های افزونه پذیر و همچنین ساده‌تر کردن Object composition و وهله سازی‌های مرتبط) و ... این مورد را نباید با اصل refactoring صورت گرفته در مثال جاری اشتباه گرفت.