نظرات مطالب
بازسازی جدول MigrationHistory با کد نویسی در EF Code first
- مطلب جاری فقط برای حالتی است که جدول migration حذف شده یا وجود ندارد.
+ مطلب « ارتقاء به Entity framework 6 و استفاده از بانک‌های اطلاعاتی غیر از SQL Server » را باید دقیق مطالعه کنید. یک سری اسمبلی باید حذف شوند. تعدادی اضافه شوند. فایل کانفیگ حتما باید ویرایش شود و تعریف پروایدر را داشته باشد. این کارها را نیوگت به صورت خودکار انجام می‌دهد. ضمنا اینکار باید برای تمام زیر پروژه‌های شما نیز تکرار شود و طوری نباشد که دو کتابخانه از 4 استفاده کنند، دوتای دیگر از 5 و اصلی هم از 6. همه باید یک دست شوند و اسمبلی منسوخ شده قدیمی نیز حذف.
- اسمبلی EF به تنهایی کافی نیست ولی از اینجا به صورت جداگانه قابل دریافت است. باید دقت داشت که ارتقاء به نگارش 6 سه مرحله‌ای است که عنوان شد.
- از اینجا
نظرات مطالب
ASP.NET MVC #12
- مشکلی از این لحاظ نیست که نشود از RenderAction در فایل layout استفاده کرد.
- منطق تهیه گروه بندی مطالب شما احتمالا یک حلقه بی‌نهایت دارد یا یک الگوریتم بازگشتی بی پایان است.
- ممکن است در این حالت از return PartialView استفاده نکردید و return View بوده. در این حالت View بازگشتی ارجاعی را به فایل layout خواهد داشت. یعنی به صورت تو در تو فایل layout اجرا و تکرار می‌شود.
- یا در اینجا بهتر است در ابتدای فایل بنویسید  Layout = null تا زمان رندر شدن در فایل layout دوباره سبب ارجاع بی‌نهایتی به فایل Layout نشود.
نظرات مطالب
Implementing second level caching in EF code first
تکرار مجدد:
- هر کلاس لایه سرویس با پیاده سازی یک اینترفیس باید تهیه شود.این مورد به نظر در قسمت 12 سری EF بحث شده با مثال و فایل و همه چیز در برنامه‌های کنسول و MVC و وب فرم‌ها.
- کلاس کمکی فوق نیازی به وب سرور برای اجرا ندارد و باعث fail آزمون‌های واحد شما نمی‌شود چون در صورت نبودن وب سرور از حافظه سیستم استفاده می‌کند نه کش IIS.
- اگر به این نتیجه رسیدید که کش پروایدر بهتری وجود دارد و نیاز به تعویض نمونه مطرح شده در اینجا هست (که من در «مثال» ارائه شده نیازی به آن نداشتم)، لطفا آن‌را معرفی کنید و همچنین پیاده سازی اصلاح شده را به صورت یک وصله ارائه کنید جهت تکمیل بحث.
نظرات مطالب
ASP.NET MVC #18
        [HttpGet]
        public ActionResult LogOn(string returnUrl)
        {
            if (User.Identity.IsAuthenticated) //remember me
            {
                if (ShouldRedirect(returnUrl))
                {
                    return Redirect(returnUrl);
                }
                return Redirect(FormsAuthentication.DefaultUrl);
            }

            return View(); // show the login page
        }
بعد  از پیاده سازی CustomRoleProvider وقتی که از این فیلتر استفاده می‌کنم :
[Authorize(Roles = "Admin")]
می ره به اکشن Logon اونجا
IsAuthenticated=true
هست و همین طور متد
ShouldRedirect(returnUrl)
هم مقدار true رو بر می‌گردونه و نتیجه اینکه دوباره بر می‌گرده به /User/Create و اونجا هم دوباره برمی گرده به همین اکشن و این Loop تکرار می‌شه.

این کد برای من اینجوری کار می‌کنه

نظرات مطالب
EF Code First #11
چندتا بحث هست. مدیریت پروژه. استفاده از Repository.
اینکه پوشه درست کنید،  class library‌ درست کنید. اسم‌های متفاوت استفاده کنید. همه این‌ها خوب است.
باز هم در طراحی خودتون اومدید ORM رو مخفی کردید. کل بحث جاری این است که اینکار اتلاف وقت است. «فقط با یک Config ساده در DI این موضوع به طور کامل حل می‌شود» : .... نمی‌شود. خیر! قصد ندارم مواردی رو که عنوان کردم تکرار کنم. مدتی با یک ORM با قابلیت‌های بالا کار کنید، این مطلب رو دیگر عنوان نخواهید کرد.
به نظر در مورد اسامی کمی تداخل اینجا هست. مفهومی رو که از Repository‌ دنبال می‌کنید، همان چیزی است که در لایه سرویس من به آن اشاره کردم.
اگر علاقمند بودید، به پیاده سازی generic repository که لینک دادم مراجعه کنید.
واژه‌ها‌ی مورد استفاده رو اگر یکسان کنیم شاید خیلی از سؤ تفاهم‌ها برطرف شود.
نظرات مطالب
MVVM و فراخوانی متدهای اشیاء View از طریق ViewModel
خوب، سخت بودن کار سورس باز هم همینجا است. در کارهای سورس باز در تمام آن‌ها، شما مجاز هستید کار مشتق شده رو بفروشید. تنها تفاوت در اینجا است که یکی می‌گه حتما باید سورس رو هم کنارش قرار بدی و یکی می‌گه مهم نیست و گرنه تمامشون با این مساله مالی مشکلی ندارند.
در کل به درجه‌ی روانی به اشتراک گذاری اطلاعات رسیدن، کار سختی است. به همین جهت باز هم تکرار می‌کنم این دور و اطراف بگردید، ماهی 5 نفر رو شاید پیدا کنید که حاضر باشند مطلب فنی مهمی رو به رایگان منتشر کنند و قید همه چیز آن‌را بزنند. زمانیکه هم که روز به روز تعدادشون کمتر بشه، انگیزه رو از بقیه خواهند گرفت.
مطالب
الگوریتم‌های داده کاوی در SQL Server Data Tools یا SSDT - قسمت پنجم - الگوریتم‌ Association Rules

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


مقدمه

خودتان را جای مدیر یک سوپرمارکت بگذارید. یکی از وظایف شما فروش بالاتر نسبت به بقیه مدیران یک سوپرمارکت زنجیره ای است. برای نیل به این هدف، درک الگوی خرید مشتریان بسیار حایز اهمیت است. فرض کنید متوجه شده‌اید که مشتریان شما در 75 درصد موارد سس، هات داگ و ترشی را با هم خریده‌اند. بنابراین چیدن قفسه به طوری که این اقلام کنار یکدیگر باشند، بهتر است. همچنین می‌توانید پکیجی را شامل این اقلام ایجاد کرده و با درصد تخفیف مناسبی به‌فروش برسانید؛ برای مثال یک ترشی را که تازه به بازار آمده و هنوز اقبال عمومی در رابطه با آن وجود ندارد، اما سود خوبی در فروش آن نصیب شما می‌شود، در این پکیج و در کنار هات داگ و سس معروفی قرار داده و بفروش برسانید.


نحوه عملکرد الگوریتم

این الگوریتم، براساس شمارش ترکیبات تکرارشونده‌ی حالات گوناگون ویژگی‌های یک مدل، کار می‌کند. این الگوریتم شبیه به الگوریتم Naïve Bayes می‌باشد؛ با این تفاوت که دارای رویکرد کمی است (براساس عدد خامی از وقوع ترکیبات حالات یک ویژگی) و رویکرد کیفی ندارد (محاسبه تمامی احتمالات شرطی، آنچه که در الگوریتم Naïve Bayes اتفاق می‌افتاد). همچنین در اینجا ماتریس ضرایبی محاسبه نمی‌شود، بلکه تنها ضرایب قابل توجه، نگهداری می‌شوند.


تفسیر مدل

این الگوریتم، پس از پردازش، سه تب دارد.


تب Itemsets تعداد تکرار مجموعه اقلام کشف شده را نشان می‌دهد. مقدار پارامتر Minimum_Support اگر خیلی پایین در نظر گرفته شود، آنگاه لیست طولانی را ایجاد می‌کند. با استفاده از Filter Item Set می‌توان Item Set‌های موردنظر را فیلتر نمود. برای مثال می‌توان چنین Item Set ای را در نظر گرفت Gender=Male.

تب Rules نشان دهنده قوانین وابستگی کاربردی و ارزشمندی می‌باشد که به همراه احتمال و درجه اهمیتشان در یک جدول آورده شده‌اند. درجه اهمیت (Importance) نشان دهنده میزان سودمندی یک قانون است و هرچه بیشتر باشد، قانون متناظر آن درجه کیفی بالاتری دارد. به عبارت دیگر بیشتر می‌توان روی آن قانون حساب کرد. توسط پارامترهای Minimum_Probability و Minimum_Importance به ترتیب می‌توان لیست مزبور را براساس مینیمم احتمال و مینیمم درجه اهمیت فیلتر کرد.

تب Network Dependency، هر آیتم و قانون، وابستگی بین آن‌ها را نشان می‌دهد.


نکته آخر: در یک مدل وابستگی، اگر ستونی به عنوان ورودی در نظر گرفته شود، مقادیرش فقط می‌توانند در itemset‌های تکرار شونده و درسمت چپ قوانین وابستگی قرار بگیرند. اگر ستونی به عنوان خروجی درنظر گرفته شود، حالات مختلف آن ستون می‌توانند در itemset‌های تکرار شونده و در سمت راست قوانین وابستگی قرار بگیرند. اگر ستونی به عنوان ورودی-خروجی در نظر گرفته شود، آنگاه حالات مختلف آن ستون می‌توانند در itemset‌های تکرار شونده و در سمت چپ و هم راست قوانین وابستگی قرار بگیرند.  

پاسخ به بازخورد‌های پروژه‌ها
نمایش ردیف های اضافه در انتهای هر صفحه
خیلی متشکرم.
مثال محاسبه بیمه و مالیات یک فاکتور نیاز من را برآورده می‌کرد ، اگر در هر صفحه تکرار می‌شد. 
چون table.NumberOfDataRowsPerPage تنظیم شده نمی‌توانم از Footer سفارشی استفاده کنم.
روش events.RowStartedInjectCustomRows را قبلا امتحان کرده ام ، باید ردیف‌ها بعد از ردیف مجموع باشد. 
برای این سناریو روشی که به نظرم می‌آید استفاده از روش محاسبه بیمه و مالیات یک فاکتور است اما به این حالت که تعداد رکورد‌های گزارش را تقسیم بر تعداد رکورد در هر صفحه کنم سپس برای هر صفحه یک گزارش تهیه  کنم و داده‌های سلول‌های انتهایی مثل مچموع را خودم حساب کنم، سپس همه‌ی گزارش‌ها را یکی کنم. به نظر شما جوابگو خواهد بود؟
با تشکر.
بازخوردهای پروژه‌ها
مدیریت پروژه
قبل از هر چیز سپاس گذارم از وب سایت بسیار قوی شما 
صحبتم را با یک مثال پیش می‌برم 
فرض کنیم یک پروژه کوچک مثل فروشگاه اینترنتی یا برنامه مدیرت املاک را یک تیم 4 نفره می‌خواهند انجام دهند پروژه باید چگونه تقسیم بندی بشه . حالا تقسیم بندی شد هر کسی در سیستم خودش داره قسمت مورد نظر را توسعه میده پایان کار چگونه باید پروژه اسمبل بشه و مباحثی در مورد مدیرت پروژه به صورت کاربردی مثل مطالب سایتتون البته بازم تکرار می‌کنم من مباحثی مانند Scrum و Uml نیاز ندارم . مدیرت پروژه تیمی ونحوه کار هر یک از اعضا - و نهایتا چگونگی اسمبل کردن پروژه در یک vs . با تشکر 
پاسخ به پرسش‌ها
ساخت یک دیتابیس ترکیبی از SQL و فایل های XML

یقینا سرعت کار با بانک‌های اطلاعاتی رابطه‌ای و امکانات توکار آن‌ها همیشه بیشتر از کار با XML و هر حالت مشابه دیگری در آن‌هاست و بنابراین ... بله. حالت دوم بهینه‌تر نیست، سریعتر نیست و همچنین کم‌حجم‌تر هم نیست. اساسا بانک‌های اطلاعاتی رابطه‌ای زمانی طراحی شدند که یک هارد دیسک 4 مگابایتی، چندهزار دلار قیمت داشت. به همین جهت در زمینه ذخیره سازی اطلاعات، بسیار بهینه و کم‌حجم عمل می‌کنند؛ با حداقل تکرار و سربار و با سرعت بالا. استفاده از XML و JSON امثال این‌ها زمانی باب شدند که قیمت هارد دیسک‌های حجیم کاهش یافته بود و همچنین بیشتر سرعت read مطرح بود و نه سرعت write. اطلاعات بیشتر