نظرات مطالب
Protocol Buffers فرمتی برای تبادل دیتا
مقاله جالب و خوبی بود فقط ذکر چند نکته خالی از لطف نیست.
protobuf در مرورگر پشتیبانی نمی‌شود و برای کار با آن می‌توان از  protobuf.js (پیاده سازی Protocol Buffers برای Javascript) استفاده کرد 
برای استفاده از protobuf در دات نت نیز 2 کتابخانه موجود است
1- کتابخانه  Google.Protobuf : که پیاده سازی و استفاده از آن شبیه نسخه اصلی protobuf است. (اطلاعات بیشتر)
2- کتابخانه  protobuf-net : که پیاده سازی و استفاده از آن شبیه بقیه سریالایزر‌های دات نتی بوده و بیشتر متمایل به سی شارپ است. (اطلاعات بیشتر)
به نظرم دومی بیشتر باب میل سی شارپی‌ها باشد و نیز ساده تر. با دیدن مثال هر دو کتابخانه میتوانید بهتر متوجه این تفاوت شوید.
لینک زیر هم به مقایسه این دو کتابخانه پرداخته : 
نظرات مطالب
روش استفاده‌ی صحیح از HttpClient در برنامه‌های دات نت
با سلام و احترام. با توجه به این که ASP.NET Core کدها را با ماهیت SynchronizationContext اجرا نمی‌کند، نوشتن یا ننوشتن ConfigureAwait(false) چه تفاوتی ایجاد می‌کند؟
دوم اینکه اگر فرض کنیم این مثال برای ASP.NET MVC غیر ASP.NET Core ای نوشته شده باشد که در آن نوشتن ConfigureAwait(false) با ننوشتن اش تفاوت ایجاد می‌کند، این نوع استفاده از ConfigureAwait ایجاد مشکل می‌کند، زیرا به علت Restore نشدن Sync Context، عملا مواردی مثل HttpContext.Current مقدار درستی را در خط بعد از await نخواهند داشت.
در مجموع جای ConfigureAwait(false) چه در ASP.NET و چه در ASP.NET Core در Controller و Action نیست. در ASP.NET Core که عملا تفاوتی ندارد و در ASP.NET هم در لایه‌های قبلی مثل Service و Repository اگر از ConfigureAwait(false) استفاده بشه، به بهبود عملکرد سیستم کمک می‌کنه، به شرطی که وقتی کد داره توی Controller و Action فراخونی می‌شه دیگه ConfigureAwait نداشته باشه.
سپاس 
نظرات مطالب
مایکرو سرویس‌ها - قسمت 1 - معرفی
سلام.
مایکرو سرویس یکی از مشتقات SOA می‌باشد. اما تفاوت هایی هم تو این دیدگاه نسبت به SOA وجود دارد
  1. اندازه سرویسها در این دو متفاوت می‌باشد در مایکرو سرویسها اندازه یک سرویسها کوچکتر از اندازه سرویسها در SOA می‌باشد
  2. سرویها در مایکرو سرویس می‌توانند کاملا مستقل از هم قابل استقرار باشندو مکانیزم استقار بصورت خودکار می‌باشد درحالی که در SOA  این امکان وجود ندارد
  3. در SOA  برای بررسی قوانین کسب و کار  و ادغام سیستم‌های یکپارچه  تمرکزبر روی ESB  می باشد ، در حالی که این امر در مایکرو سرویس‌ها یک anti pattern  به شمار می‌آید و دیدگاه  آنها عدم انتقال قوانین کسب کار به مکانیزم ارتباطی می‌باشد (smart endpoints and dumb pipe)
در مورد معایب این روش در آینده صحبت خواهیم کرد اما میتوان گفت که پیاده سازی این معماری هزینه زیادی دارد هم از لحاظ زمانی و هم از لحاظ پیچیدگی در پیاده سازی.
نظرات مطالب
آشنایی با الگوی MVP
تفاوت مهم این‌ها در قسمت ViewModel و Presenter هست که در MVVM قسمت ViewModel آن پیاده سازی کننده‌ی الگوی observer است و تغییرات اطلاعات در مدل یا حتی خواص قرار گرفته‌ی در آن، بلافاصله به View منعکس می‌شوند و برعکس آن هم با two-way binding میسر است.
در MVP، قسمت Presenter از وجود View مطلع هست. برای نمونه در مثال بحث فوق، شیء this را دریافت می‌کند و به این ترتیب هست که قابلیت به روز رسانی آن‌را خواهد یافت. اما در MVVM قسمت ViewModel، هیچ ارجاعی را از View درخود ندارد.

بر این مبنا MVVM برای برنامه‌های statefull مانند برنامه‌های دسکتاپ و یا حتی برنامه‌های تک صفحه‌ای وب سمت کاربر (استفاده از knockout js) مرسوم است.
MVP برای برنامه‌های stateless مانند برنامه‌های سمت سرور وب بیشتر کاربرد دارد. جایی که یک فریم ورک binding حاصل از زنده نگه داشتن context برنامه در دسترس نیست و طول عمر هر صفحه محدود است به پایان Response آن.
نظرات مطالب
آشنایی با Saltarelle کامپایلر قدرتمند #C به جاوااسکریپت
با تشکر از نوشتارتون ذکر دو نکته را لازم می‌دونم.
اول اینکه هدف از این مطلب الزام به استفاده یا عدم استفاده از این نوع کامپایلرها نیست و فقط برای آشنایی با این گونه ابزارها بوده که در حال حاضر در بسیاری از نرم افزارهای اینترپراز در حال استفاده اند.
و دوم اینکه تفاوت ساختاری و ماهیتی سی شارپ و جاوا اسکریپت اونقدر واضح هست که نباید از این دو انتظار یکسان داشت. و مهمترین عامل به وجود اومدن چنین کامپایلرهایی استفاده از سینتکس سی شارپ بوده و نه قدرت دات نت فریم ورک. بنا براین فکر می‌کنم لزومی به وجود مبدل هایی از زبان میانی وجود ندارد و همچنین واضح است کلاس هایی از قبیل Random و غیره که نه توانایی زبان سی شارپ بلکه امکانات درونی دات نت فریم ورک است برای همچین ابزاری بی معناست.
و فکر می‌کنم برای چنین کامپایلری لازم نیست جاوا اسکریپت همه امکانات سی شارپ را داشته باشد. و اینکه سی شارپ بتواند قسمت زیادی از امکانات جاوا اسکریپت را در اختیار برنامه ساز قرار دهد کافیست.
باز هم تشکر می‌کنم
نظرات مطالب
الگوی استراتژی - Strategy Pattern
تفاوت مهمی نداره؛ فقط اینترفیس ورژن پذیر نیست. یعنی اگر در این بین متدی رو به تعاریف اینترفیس خودتون اضافه کردید، تمام استفاده کننده‌ها مجبور هستند اون رو پیاده سازی کنند. اما کلاس Abstract می‌تونه شامل یک پیاده سازی پیش فرض متد خاصی هم باشه و به همین جهت ورژن پذیری بهتری داره.
بنابراین کلاس Abstact یک اینترفیس است که می‌تواند پیاده سازی هم داشته باشد.
همین مساله خاص نگارش پذیری، در طراحی ASP.NET MVC به کار گرفته شده: (^ )
برای من نوعی شاید این مساله اهمیتی نداشته باشه. اگر من قرارداد اینترفیس کتابخانه خودم را تغییر دادم، بالاخره شما با یک حداقل نق زدن مجبور به به روز رسانی کار خودتان خواهید شد. اما اگر مایکروسافت چنین کاری را انجام دهد، هزاران نفر شروع خواهند کرد به بد گفتن از نحوه مدیریت پروژه تیم‌های مایکروسافت و اینکه چرا پروژه جدید آن‌ها با یک نگارش جدید MVC کامپایل نمی‌شود. بنابراین انتخاب بین این دو بستگی دارد به تعداد کاربر پروژه شما و استراتژی ورژن پذیری قرار دادهای کتابخانه‌ای که ارائه می‌دهید.
نظرات مطالب
ASP.NET MVC #13
با سلام و تشکر فراوان
اعتبار سنجی سمت کلاینت در مثال 13 که فرمودید در سیستم من کار نکرد اما این مثال code project کار می‌کند.
ولی بعد از اینکه دوباره مثال را در mvc4 vs2012 باز نویسی کردم کار نکرد (دقیقا مانند مثال code project) پس از تغییر متداز (-) split به (/) split و تغییر 
 mcvrTwo.ValidationParameters.Add("param", DateTime.Now.ToString("dd/MM/yyyy"));
به (فقط فرمت تاریخ تغییر کرد)
mcvrTwo.ValidationParameters.Add("param", DateTime.Now.ToString("dd-MM-yyyy"));
و حذف
@section Scripts {
    @Scripts.Render("~/bundles/jqueryval")
}
کار کرد.
چرا به این تغییرات نیاز بود؟ (در صورتی که مثال code project کار می‌کرد، آیا به دلیل تفاوت ورژن است)
این مثال با مثال شما چه تفاوتی دارد که مثال شما در سیستم من اجرا نشد؟
این هم فایل نهایی من بعد از تغییر که کار کرد: MvcApplication-JsValidation.zip
نظرات مطالب
ASP.NET Web API - قسمت اول
من فکر کنم مطلب این دوستمون رو این جوری مطرح کنم بهتره
وقتی شما از WCF Data Services استفاده می‌کنید، WCF Data Services Client دارید، که به شما امکان نوشتن کوئری‌های Linq در سمت کلاینت، Change Tracking و Merge و ... رو می‌ده
اما من همچین آیتمی رو برای Web API پیدا نکردم، بهترین چیزی که دیدم Http Client بوده که در حد مثال زدن خوبه، ولی به درد پروژه نویسی نمی‌خوره، این که شما یک کلاینت قوی داشته باشید، خیلی مهمه، Http Client تفاوت مفهومی زیادی با ajax.$ نداره 
حتی در JayData هم همین طور هستش، و شما پشتیبانی خیلی بهتری از WCF Data Services می‌بینید تا از Web API، همین طور در Breeze.js
در اندروید و iOS هم شما پشتیبانی WCF Dat Services Client رو دارید، ولی Web API خیر
موفق باشید
نظرات مطالب
WF:Windows Workflow #1
مشکل جایی شروع میشه که خروجی هایی که هر سازمان از یه مفهوم دارند متفاوت هست، بطور مثال در حوزه نرم افزار‌های مربوط به حضور و غیاب که به ظاهر شاید فقط ورود و خروج و اضافه کار و کسر کار است ولی در ریز کار و در اعمال قوانین مربوط به سازمان استفاده کننده کاملا متفاوت و شاید تجمیع آنها در قالب هارد کد دست نیافتی باشد: برای نمونه میتوان روی نوع برخورد با اضافه کاری صحبت کرد که در یک سازمان طریق تجمیع و محاسبه این مورد در روز و ماه و سال تفاوت است. جایی حتی ورود قبل از ساعت کاری اضافه کار محسوب میشود و ضرایب و نوع ضرایب آن متغییر و متفاوت است، شاید با گروه بندی و راهکارهایی از این دست بتوان از این سفارشی سازی‌ها تا حدودی در امان ماند ولی در نهایت کار پروژه به اجبار باید به تولید یه موتور تعریف قوانین برای سپردن این مسئولیت (ساخت و ویرایش، بهمراه پیچیدگیهای سازمانی آن) برود که در بعضی از اوقات WF جواب دلخواه هیچ کدام از دو سمت را نمیدهد.
نظرات مطالب
ASP.NET MVC #11
خلاصه موردی را که عنوان کردید این است:
اگر یک صفحه داریم که از مثلا 4 ویجت نمایش آب و هوا، نمایش اخبار، نمایش تعداد کاربران حاضر در سایت و آمار سایت و نمایش منوی پویای سایت تشکیل شده، تمام این‌ها رو در یک ViewModel قرار ندیدم که اشتباه است. بله این مورد درست است؛ اما ... به معنای نفی استفاده از ViewModel ها نیست.
هر کدام از ویجت‌ها را می‌شود به Partial viewهای مختلفی برای مثال خرد کرد. اما نهایتا هر کدام از این اجزای کلی سیستم اصلی، نیاز به ViewModel دارند که این مورد، بحث اصلی جاری است. یعنی تفاوت قائل شدن بین domain model و view model. پوشه‌ی مدلی که در ساختار پروژه پیش فرض ASP.NET MVC قرار داره در واقع امر یک ViewModel است و نه مدل به معنای تعریف مدل‌های domain سیستم چون قرار است خواص آن مستقیما در View مورد استفاده قرار گیرند.
استفاده از ViewModelها کار را اندکی بیشتر می‌کنند، چون نهایتا خواص آن‌ها باید به مدل اصلی نگاشت شوند اما خوشبختانه برای این مورد هم راه حل هست و روش پیشنهادی، استفاده از کتابخانه‌ی سورس بازی است به نام AutpoMapper :  (^)