نظرات اشتراک‌ها
RIA Services و پشتیبانی از EntityFramework 5.0.0
چون داخل مرورگر کاربر اجرا می‌شود و یک فناوری سمت سرور نیست؛ دقیقا مانند جاوا اسکریپت است. فناوری‌های سمت کلاینت هم محصور هستند به sandbox امنیتی مرورگرها و امکان تعامل آنچنانی با سیستم کاربر ندارند (هرچند حالت‌های خارج از مرورگر و با دسترسی بالای آن هم وجود دارد اما نه در حالت پیش فرض و نه باز هم با دسترسی خیلی بالا). همچنین برنامه‌های سیلورلایت، برنامه‌های N-Tier واقعی هستند. از این جهت که برنامه مصرف کننده اطلاعات سرور یا همان برنامه سیلورلایت، روی سروری که دیتابیس و وب سرور قرار دارند، اجرا نمی‌شود. به علاوه قرار نبوده از روز اول (و دیگر هم به نظر قرار نیست) که حجم دریافتی سیلورلایت بالا باشد. به همین جهت حاوی بسیاری از کلاس‌های دات نت نیست و انتقال کدهای خیلی از کتابخانه‌های حجیم با وابستگی‌های زیاد به اجزای مختلف دات نت، به آن ساده نخواهد بود.
نظرات مطالب
EF Code First #11
1- بله.
 2- بله.
3- این هم خوبه ولی اگر بانک اطلاعاتی و برنامه وب شما مثلا در یک سرور قرار دارند ضرورتی به استفاده از WCF نیست و به کارآیی بیشتری حین استفاده مستقیم از بانک اطلاعاتی خواهید رسید. WCF برای معماری چند tier توصیه می‌شود (هر tier رو یک سرور در اینجا فرض کنید. یک سرور جدای وب، یک سرور جدای اس کیوال و الی آخر ....)
4- BLL همان لایه سرویسی‌است که عنوان کردم. جایی که از EF استفاده می‌شود.
5- بله.

این M در MVC مرتبط با ASP.NET MVC جای بحث زیاد دارد. بیشتر ViewModel است تا Model به معنای Domain Classes .
پاسخ به بازخورد‌های پروژه‌ها
سوال در مورد Authenticate_Request
سلام؛
بله منطقی است. به این علت که role کاربر در کوکی‌های شخص ذخیره می‌شود این کوئری باید به بانک ارسال شود.
برای مثال فرض کنید که کاربری که وارد سایت شده را مدیر بن کرد یا سطح دسترسیش را تغییر داد، اما تا زمانی که کاربر مجددا اقدام به ورود به سایت نکنه نمی‌توانیم آن کاربر را مسدود کنیم. حال در اینجا به بانک اطلاعاتی متصل شده و سطوج دسترسی و وضعیت کاربر را بررسی می‌کنیم تا در صورت لزوم کاربر را logout اجباری کنیم.
این را هم در نظر بگیری ما با یک DBMS قدرتمند طرف هستیم. اگر قرار باشد با چند ده تا کوئری سیستم مختل شود که...
برای بهینه سازی هم می‌توانید از کش مدت دار سمت سرور استفاده کنید.
در ضمن قسمت مربوط به مدیریت کاربران این سیستم  را از صفر بازنویسی کردم که بسیار قوی‌تر از سیستم کنونی است و هر موقع رابط کاربریش تحت AngularJs آماده شد آن را به اشتراک می‌گذارم.
بازخوردهای دوره
الگوی معکوس سازی کنترل چیست؟
مثلا می‌توانید دسترسی به داده‌ها رو مستقیما در کدهای یک کنترلر یا فرم قرار دهید و یا با استفاده از معکوس سازی وابستگی‌ها، این دسترسی را به یک لایه سرویس منتقل و معکوس کرده و استفاده کنید (در کنترلر یا فرم برنامه). استفاده نهایی از امکانات اینترفیس‌های لایه سرویس خواهد بود، بدون اطلاع از نحوه پیاده سازی خاص لایه سرویس برنامه. به این ترتیب علاوه بر جداسازی لایه‌های مختلف برنامه، امکان ارائه نگارش‌های مختلفی از پیاده سازی‌های اینترفیس‌ها نیز وجود خواهد داشت. در برنامه واقعی، پیاده سازی کننده‌ها، از دیتابیس واقعی استفاده می‌کنند و در مثلا در حین آزمایش واحد، از پیاده سازی خاص استفاده کننده از یک بانک اطلاعاتی ساده تشکیل شده در حافظه برای بالا رفتن سرعت آزمون‌ها.
نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت پنجم - سیاست‌های دسترسی پویا
مشکل؟ یا طبیعت سیستم؟
- به ازای هر درخواست، یکبار متد RetrieveAsync کلاس DistributedCacheTicketStore فراخوانی می‌شود؛ چون شیء User موجود در HttpContext، بر اساس اطلاعات کوکی دریافتی ساخته می‌شود. اکنون که این کوکی داخل دیتابیس هست، خوب باید خوانده شود تا این شیء را تشکیل دهد.
- فعالسازی ()services.enableImmediateLogout ، سبب فراخوانی RenewAsync کلاس DistributedCacheTicketStore به ازای هر درخواست می‌شود. اگر می‌خواهید تعداد آن‌را کمتر کنید، قابلیت logout آنی کاربران در زمان غیرفعال شدن آن‌ها در بانک اطلاعاتی را حذف کنید.
نظرات مطالب
طراحی گردش کاری با استفاده از State machines - قسمت اول
برای به گردش درآوردن آبجکت در Flow ایجاد شده تحت وب ایده ای می‌توانید بدهید؟
قاعدتا چندین راه (مانند موارد دیگر) برای آن وجود دارد اما راه بهینه بدون استفاده از WF و مستقل از شیء چیست؟
با جستجوی در وب چیزی دستگیرم نشد. اولین راه حلی که به نظرم می‌رسد در سمت application با mvc کنترلی با تحریف OnActionExecuting  و OnResultExecuted داشته باشیم برای پردازش State‌های مختلف و در متدهای ذکر شده ذخیره در بانک اطلاعاتی را انجام دهیم و در سمت دیتابیس هم جدولی داشته باشیم که با تغییر وضعیت، شناسه Workflow و شناسه State را برای نگهداشتن تاریخچه وضعیت‌ها و پیگیری آن را ذخیره کنیم. البته همچنان برای بررسی شروط هنگام transition‌ها به نتیجه ای نرسیده ام
نظرات مطالب
EF Code First #4
- این‌ها ساده هستند و قابل اجرا بر روی دیتابیس ریموت (فقط باید ConnectionString را صریحا ذکر کنید):
Update-Database -StartUpProjectName "...name..." -ConnectionString "...data..." -ConnectionProviderName "System.Data.SqlClient"
- و بله. «ویژگی مهاجرت خودکار» را در برنامه فعال کنید و لذت ببرید. نیازی به هیچ دستور پاور شلی ندارد. هر زمان که مدل‌های شما تغییر کرد، به صورت خودکار ساختار بانک اطلاعاتی را در اولین اجرای بعدی برنامه، به روز می‌کند.
- «بازسازی جدول MigrationHistory با کد نویسی در EF Code first»
نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت چهارم - User Claims
- این سیستم مدنظر شما نیست؟ اشکالی ندارد! از صفر خودتان آن‌را بنویسید و تنظیم کنید: «اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity»
- در Identity به ازای هر نقش کاربر، یک select به بانک اطلاعاتی وجود ندارد. دقیقا پس از لاگین، اطلاعات User Claims در کوکی شخص به صورت رمزنگاری شده، کش می‌شوند و در دفعات بعدی/درخواست‌های بعدی، از این کوکی خوانده خواهند شد. اما در پروژه‌ی DNT Identity به ازای هر درخواست، طوری تنظیم شده تا وضعیت اعتبار کاربر، بررسی شود و اینکار توسط تنظیم enableImmediateLogout و ValidationInterval = TimeSpan.Zero آن انجام می‌شود. چرا؟ چون اگر در سمت سرور، کاربری را غیرفعال کردید، آیا باید تا زمان منقضی شدن اعتبار کوکی آن، بتواند از سایت استفاده کند؟ بله. این مورد هزینه‌ی اعتبارسنجی User Claims و در نتیجه، کوئری گرفتن از بانک اطلاعاتی را به ازای هر درخواست، به همراه دارد؛ ولی ضروری است. یعنی این سیستم صرفا هر کوکی را که شامل یکسری User Claims باشد، معتبر نمی‌داند.
نظرات مطالب
چک لیست تهیه یک برنامه ASP.NET MVC
ضمن تشکر از مطالب خوبتون
آقای نصیری من به ASP.NET MVC علاقه پیدا کرده ام و در نظر دارم پروژه ای را با این تکنولوژی شروع کنم.قبلا هم دو تا وب سایت با ASP.NET Web Form نوشته ام اما از وقتی با این تکنولوژی آشنا شده ام هدفم پیشرفت در این زمینه می‌باشد.اکثر مطالب شما را خوانده ام.اما اگر می‌شد مواردی را که در این چک لیست ذکر کرده اید با یک پروژه عملی توضیح داده شود از نظر یادگیری و در ک مطلب خیلی مفید واقع خواهد شد.ضمنا ممنون می‌شم موارد زیر را با مثال توضیح دهید
«-مدل‌های متناظر با جداول بانک اطلاعاتی نباید مستقیما در Viewهای برنامه استفاده شوند.
- پوشه Models، از پروژه اصلی حذف شود. یک پروژه class library جدید به نام MyProjectName.Models برای نگهداری ViewModels ایجاد گردد.
- یک پروژه Class library دیگر به نام MyProjectName.DomainClasses برای نگهداری کلاس‌های متناظر با جداول بانک اطلاعاتی ایجاد شود.در هیچ کنترلری نباید جزئیات پیاده سازی متدی مشاهده شود. تمام پیاده سازی‌ها باید به لایه سرویس‌های مختلف برنامه منتقل و از طریق تزریق وابستگی‌ها در دسترس باشند.
-در صفحه لاگین سایت، autocomplete خاموش شود.
- تعداد رفت و برگشت‌های به بانک اطلاعاتی در یک صفحه توسط پروفایلرها بررسی شده و اطلاعات عمومی پرمصرف کش شوند
- هیچکدام از کلاس‌های ASP.NET MVC نباید از HttpContext مستقیما استفاده شود.
-تمام درخواست‌های jQuery Ajax باید بررسی شوند»