وحید نصیری وحید نصیری
نظرات مطالب
نکات کار با استثناءها در دات نت
یک نکته‌ی تکمیلی: بهبود خروجی stack trace استثناءهای رخ داده
خروجی رشته‌ای stack trace استثناءهای رخ داده، سال‌ها است که به روز رسانی نشده و با افزوده شدن امکانات بیشتری به زبان #C، یک چنین خروجی‌های نامفهومی را تولید می‌کند:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
.
.
.
at Program.<>c__DisplayClass8_0.<Method>b__0()
کتابخانه‌ی «Ben.Demystifier » با تغییر ساده‌ی ()exception.Demystify، یک شیء استثنای جدید را تولید می‌کند که خوانایی بیشتری را داشته و با مفاهیم جدید زبان #C سازگاری دارد. این کتابخانه اکنون در بسیاری از محصولات خود مایکروسافت هم مورد استفاده قرار می‌گیرد و تبدیل به یک استاندارد شده‌است. یک نمونه‌ی ساده‌ی استفاده‌ی از آن، لاگ کردن خطاها با استفاده از این شیء بهبود یافته‌است:
 
_logger.LogError(ex.Demystify(), "Invalid operation.");
‫۳ سال و ۸ ماه قبل، جمعه ۲۶ دی ۱۳۹۹، ساعت ۱۸:۵۴
وحید نصیری وحید نصیری
نظرات مطالب
مدیریت پیشرفته‌ی حالت در React با Redux و Mobx - قسمت هفتم - بررسی مفاهیم Mobx
- در Redux فقط یک store سراسری وجود دارد که در برگیرنده‌ی تمام اشیاء حالت‌های کامپوننت‌های مختلف برنامه است. علتش را هم در قسمت اول این سری مطالعه کنید که اصلا چرا به آن نیاز هست. علت انجام اینکارها چی هست. چه مشکلی وجود داشته که نیاز به store سراسری حس شده که بعد از آن مفاهیم مدیریت حالت سراسری ارائه شده‌اند.
- در Mobx می‌توان از چند store سراسری استفاده کرد. طراحی این storeها با خود شما است و برخلاف Redux که دسترسی مستقیمی به آن نیست، در اینجا می‌توان مستقیما خواص observable آن‌را تغییر داد و یا متدهایی را که به صورت action علامتگذاری شده‌اند، فراخوانی کرد و store را به حالت دیگری تغییر داد. یعنی در کل طراحی شیءگرای store در MobX، کاملا به برنامه نویس واگذار شده‌است. می‌توانید چندین store را به ازای اشیاء حالت کامپوننت‌های مختلف ایجاد کنید و سپس آن‌ها را به عنوان خاصیت‌های عمومی store اصلی که توسط Provider به لایه‌های زرین ارسال می‌کنید، معرفی کنید.
‫۴ سال و ۹ ماه قبل، شنبه ۲۱ دی ۱۳۹۸، ساعت ۱۸:۴۸
اردلان شاه قلی اردلان شاه قلی
نظرات مطالب
آموزش MDX Query - قسمت ششم – شروع کار با دستورات MDX
در قسمت اول این مجموعه توضیحات لازم را در خصوص مقدمات کار و مفاهیم اولیه خدمتتان ارایه کردم. برای آشنایی با ساخت Data Warehouse لطفا مراجعه کنید به قسمت (مدل داده‌ای رابطه‌ای (Relational) وچند بعدی (Multidimensional) ) در سری اول.
در خصوص ایجاد ابعاد ی مانند بعد تاریخ و بعد سن باید عرض کنم که این ابعاد امکان ارایه انواع گزارشات مختلف را به شما خواهند داد و مطلقا OLAP را از حالت دینامیک خارج نمیکند.
در خصوص نحوه‌ی تحلیل و طراحی DW ، امیدوارم به زودی بتوانم مقاله ای را انتشار بدهم.
در خصوص عملگر‌های تقسیم و ... و توابع جمعی به زودی در قسمت‌های بعدی اطلاعات کاملی را خدمتتان ارایه خواهم کرد. به طور خلاصه اینکه OLAP برای ایجاد گزارشات مدیریتی می‌باشد و قطعا این موارد شما در ادامه پوشش  داده خواهد شد.(شما به راحتی می‌توانید سرجمع یک بازه‌ی تاریخی یا سنی را برای یک Measure خاص بدست آورید.)
‫۱۰ سال و ۱۰ ماه قبل، سه‌شنبه ۱۰ دی ۱۳۹۲، ساعت ۱۹:۵۵
مهدی سعیدی فر مهدی سعیدی فر
نظرات مطالب
استفاده از چندین Context در EF 6 Code first
می خواستم ببینم می‌توان از این امکان برای پیاده سازی دیتابیس‌های توزیع شده استفاده کرد؟
مثلا جدول کاربران در یک پایگاه داده‌ی مستقل و جدول دیدگاه‌های کاربران در یک پایگاه داده مستقل دیگر باشد و به ازای هر کدام یک Context جداگانه تعریف کرد و  در برنامه با آن‌ها تعامل کرد به گونه ای که به نظر آید با یک پایگاه داده سر و کار داریم.
آیا اگر از این شیوه‌ی طراحی استفاده شود دیگر مسائل رابطه‌ی بین جداول منتفی است؟ و اگر بله شبیه سازی رابطه‌ها باید به این صورت پیاده سازی شود که اطلاعات جداول به صورت جداگانه از دیتابیس‌ها خوانده شود و سپس با استفاده از Linq To Object رابطه‌ی بین آن‌ها برقرار شود؟
با این شیوه‌ی طراحی تراکنش‌ها چگونه پیاده سازی می‌شود؟ آیا هر Context دارای یک تراکنش جداگانه است و یا امکان پیاده سازی آن به صورت یک تراکنش هم وجود دارد؟ الگوی Unit Of Work را باید به ازای هر Context جداگانه تعریف کرد؟
البته من اطلاعات خیلی ناقصی از پایگاه‌های داده توزیع شده دارم و ممکنه حرفام کاملا اشتباه باشد. متاسفانه من جایی را پیدا نکردم که در مورد پیاده سازی عملی آن بحث کرده باشد و بیشتر با یک سری مفاهیم تئوری برخورد کردم.
‫۱۰ سال و ۱۱ ماه قبل، دوشنبه ۴ آذر ۱۳۹۲، ساعت ۰۲:۱۹
محسن خان محسن خان
نظرات مطالب
فلسفه وجودی بخش finally در try catch چیست؟

- اینکه شما بروز یک مشکل رو با یک عدد منفی از یک متد بازگشت می‌دید یعنی هنوز دید زبان C رو دارید. در دات نت وجود استثناءها دقیقا برای ننوشتن return 0 یا -1 و شبیه به آن هست. در این حالت برنامه خودکار در هر سطحی که باشد، ادامه‌اش متوقف میشه و نیازی نیست تا مدام خروجی یک متد رو چک کرد.

- اینکه در یک متد کانکشنی برقرار شده و بسته شده یعنی ضعف کپسوله سازی مفاهیم ADO.NET. نباید این مسایل رو مدام در تمام متدها تکرار کرد. میشه یک متد عمومی ExecSQL درست کرد بجای تکرار مدام یک سری کد.

- یک سری از اشیاء اینترفیس IDisposable رو پیاده سازی می‌کنند مثل همین شیء اتصالی که ذکر شد. در این حالت میشه از using استفاده کرد بجای try/finally و اون وقت به دوتا using نیاز خواهید داشت یعنی شیء Command هم نیاز به try/finally داره.

‫۱۱ سال و ۱ ماه قبل، سه‌شنبه ۹ مهر ۱۳۹۲، ساعت ۱۴:۵۸
رضا بزرگی رضا بزرگی
نظرات مطالب
اهمیت Controller های ساده در ASP.NET MVC
- تصور من اینست که معماری چندلایه یک stack است از لایه‌های مختلف با وظایف متفاوت. که پایین‌ترین سطح(دیتا سورس) تا بالاترین سطح(رابط کاربری) هست. در این بین بقیه اجزا مثل BL و غیره قرار میگیره. سوالم اینه که اگر بخواهیم یه الگوی نسبتا کلی ارائه بدیم این لایه‌ها چطور روی هم چیده میشه. 
- تجسم این لایه‌ها شاید از این لحاظ مهم باشه که یکی از مهمترین مفاهیم شی‌گرایی یعنی کپسوله‌سازی و Information hidding باعث تولید ایده‌ی چند لایه‌ای هست. و دانستن و اجرای درست اون خیلی کار توسعه را آسانتر میکنه.
- N-Tier یک معماری برای طراحی هست. ولی MVC یه الگوی طراحی. و این‌ها جایگزین که نه، بلکه به نوعی با هم‌پوشانی کار را اصولی‌تر میکند. همانطور که جناب نصیری در سری MVC اشاره‌ای موکد داشتند که Model در MVC در واقع همان ViewModel است. که این ViewModel از الگوی MVVM آمده.
‫۱۲ سال و ۳ ماه قبل، چهارشنبه ۱ شهریور ۱۳۹۱، ساعت ۰۵:۴۴
مهمان مهمان
نظرات مطالب
ASP.NET Web API - قسمت اول
REST بیشتر برای مواقعی هست که شما عملیات CRUD انجام میدید. در حالی که با Web API می‌تونید علاوه بر CRUD، کارهای بسیار بیشتری انجام بدید. مفاهیم و قابلیت‌های موجود در ASP.NET MVC مانند فیلترها به خوبی در Web API پشتیبانی و به راحتی قابل استفاده هستند. ضمن اینکه با Web API می‌تونید معماری REST رو با تغییر کوچکی در route پیش فرض به دست بیارید و بدین شکل، مهاجرت از REST به Web API بسیار راحت هست. در اوایل معرفی Web API، از پروتوکل OData نیز پشتیبانی اولیه میشد که متاسفانه مایکروسافت در نسخه‌ی RC این پشتیبانی رو حذف کرد. شاید در نسخه‌های بعدی این قابلیت نیز اضافه بشه که به قدرتمندتر شدن Web API کمک می‌کنه.
ضمناً، پشتیبانی مایکروسافت از WCF REST API نیز به اتمام رسیده و پیشنهاد شده که از Web API استفاده کنید.
http://aspnet.codeplex.com/wikipage?title=WCF%20REST 
‫۱۲ سال و ۴ ماه قبل، دوشنبه ۱۲ تیر ۱۳۹۱، ساعت ۰۳:۱۷
مسعود پاکدل مسعود پاکدل
مطالب
آموزش Prism #1
امروزه تقریبا تمام کسانی که پروژه‌های WPF یا Silverlight رو توسعه می‌دهند با مدل برنامه نویسی MVVM آشنایی دارند. فریم ورک‌های مختلفی برای توسعه پروژه‌ها به صورت MVVM وجود دارد. نظیر:
  • MVVM Light
  • Prism
  • Caliburn
  • Cinch
  • WAF
  • Catel
  • Onyx
  • MVVM helpers
  • و...

هر کدوم از فریم ورک‌های بالا مزایا، معایب و طرفداران خاص خودشون رو دارند(^) ولی به جرات می‌تونیم Prism رو به عنوان قوی‌ترین فریم ورک برای پیاده سازی پروژهای بزرگ و قوی و ماژولار با تکنولوژی WPF یا Silverlight بنامیم. در این پست به معرفی و بررسی مفاهیم اولیه Prism خواهیم پرداخت و در پست‌های دیگر به پیاده سازی عملی همراه با مثال می‌پردازیم.

*اگر به هر دلیلی مایل به یادگیری و استفاده از Prism نیستید، بهتون پیشنهاد می‌کنم از WAF استفاده کنید.

پیش نیازها:

برای یادگیری PRISM ابتدا باید با مفاهیم زیر در WPF یا Silverlight آشنایی داشته باشید.(فرض بر این است که به UserControl و Xaml و Dependency Properties، تسلط کامل دارید)

  • Data binding 
  • Resources
  • Commands
  • Behaviors

چرا Prism ؟

  • Prism به صورت کامل از Modular Programming برای پروژه‌های WPF و Silverlight پشتیانی می‌کند*
  • از Prism هم می‌توانیم در پروژه‌های WPF استفاده کنیم و هم Silverlight.
  • Prism به صورت کامل از الگوی MVVM برای پیاده سازی پروژه‌ها پشتیبانی می‌کند.
  • پیاده سازی مفاهیمی نظیر Composite Command و Command Behavior و Asynchronous Interacion  به راحتی در Prism امکان پذیر است.
  • مفاهیم تزریق وابستگی به صورت توکار در Prism فراهم است که برای پیاده سازی این مفاهیم  به طور پیش فرض امکان استفاده از UnityContainer و MEF در Prism تدارک دیده شده است.
  • پیاده سازی Region navigation در Prism به راحتی امکان پذیر است.
  • به وسیله امکان Event Aggregation به راحتی می‌توانیم بین ماژول‌های مختلف ارتباط برقرار کنیم.

*توضیح درباره برنامه‌های ماژولار

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

Prism امکاناتی رو برای طراحی و توسعه این گونه پروژه‌ها به صورت ماژولار فراهم کرده است:

  • ابتدا باید نام و مکان هر ماژول رو به Prism معرفی کنیم که می‌تونیم اون‌ها رو در کد یا Xaml یا Configuration File تعریف کنیم.
  • با استفاده از Metadata باید وابستگی‌ها و مقادیر اولیه برای هر ماژول مشخص شود.
  • با کمک تزریق وابستگی‌ها ارتباطات بین ماژول‌ها میسر می‌شود.
  • ماژول مورد نظر به دو صورت OnDemand و Available  لود خواهد شد.

در شکل زیر مراحل بالا قابل مشاهده است:

Bootstrapper چیست؟

در هر پروژه ماژولار (مختص Prism نیست) برای اینکه ماژول‌های مختلف یک پروژه، قابلیت استفاده به صورت یک پارچه رو در یک Application  داشته باشند باید مفهومی به نام Bootstapper رو پیاده سازی کنیم که وظیفه اون شناسایی و پیکربندی و لود ماژول هاست. در Prism دو نوع Bootstrapper پیش فرض وجود دارد.

  1. MefBootstrapper : کلاس پایه Bootstrapper که مبنای آن MEF است. اگر قصد استفاده از MEF رو در پروژه‌های خود دارید(^) Bootstrapper شما باید از این کلاس ارث ببرد.
  2. UnityBootstrapper : کلاس پایه Bootstrapper که مبنای آن UnityContainer است. اگر قصد استفاده از UnityContainer یا Service Locator (^) رو در پروژه‌های خود دارید Bootstrapper شما باید از این کلاس ارث ببرد. 

تصویری از ارتباط Bootstrapper با ماژول‌های سیستم

مفهوم Shell

در پروژه‌های WPF، در فایل App.xaml توسط یک Uri نقطه شروع پروژه را تعیین می‌کنیم. در پروژه‌های Silverlight به وسیله خاصیت RootVisual نقطه شروع سیستم تعیین می‌شود. در Prism نقطه شروع پروژه توسط bootsrapper تعیین می‌شود. دلیل این امر این است که Shell در پروژه‌های مبتنی بر Prism متکی بر Region Manager است. از Region  برای لود و نمایش ماژول‌ها استفاده خواهیم کرد.

ادامه دارد...

‫۱۱ سال و ۴ ماه قبل، شنبه ۱ تیر ۱۳۹۲، ساعت ۱۲:۴۵
سیاوش زاهدی سیاوش زاهدی
بازخوردهای پروژه‌ها
درخواست راهنمایی بیشتر
با سلام، خیلی ممنون که سورس این وب اپلیکیشن را در اختیار کاربران قرار داده اید؛
بنده با مطالعه (بخشی از) این مطالب: 
مسیر راه Entity framework code-first ، 
مسیر راه ASP.NET MVC ،
بررسی مفاهیم معکوس سازی وابستگی‌ها و ابزارهای مرتبط با آن ،
AutoMapper ،
چک لیست تهیه یک برنامه ASP.NET MVC ،
تا حد زیاد نحوه پیاده سازی back end پروژه را درک کردم (البته ابتدا پروژه فروشگاه اینترنتی شهر طلایی من که ساده‌تر است را بررسی کردم).
با این وجود بخش هایی از پروژه از نظر بنده همچنان پیچیده است!
- مدیریت کاربران، نقش‌ها و تعیین دسترسی ها؛
- نحوه لاگ کردن فعالیت ها؛
- ارسال و دریافت پیام؛
- نحوه پیاده‌سازی front end پروژه (به طور خاص)،
لطفا در صورت امکان در این موارد (به ویژه مورد آخر طراحی UI) اگر منبعی یا مسیر راهی وجود دارد، معرفی نمایید.
با تشکر،  
‫۶ سال و ۱۰ ماه قبل، دوشنبه ۲۷ آذر ۱۳۹۶، ساعت ۰۰:۰۷
مهدی ملائیان مهدی ملائیان
مسیرراه‌ها
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x
‫۶ سال و ۱ ماه قبل، دوشنبه ۱۲ شهریور ۱۳۹۷، ساعت ۱۴:۱۳