هر متغیر استاتیک تنها دارای یک مقدار، در یک AppDomain مشخص است (مگر اینکه با ویژگی ThreadStatic مزین شود). هر برنامهی ASP.NET هم AppDomain جداگانه و منحصر به خود را دارا است. بنابراین تعریف یک متغیر استاتیک در یک برنامهی ASP.NET به معنای به اشتراک گذاری آن در بین تمامی درخواستهای رسیده به سرور است. بنابراین عموما استفاده از متغیرهای استاتیک در برنامههای چند کاربره ASP.NET یک اشتباه بزرگ است و در صورت استفاده از آن باید منتظر تخریب اطلاعات یا دریافت نتایج غیرمنتظرهای باشید (مگر اینکه واقعا میدانید دارید چکار میکنید، برای مثال کش کردن نگاشتهای NHibernate به این صورت و استفاده از الگوی singleton یا روشهای مشابه که باید بین تمام کاربران به یک صورت و یک شکل به اشتراک گذاشه شود و در حین اجرای برنامه تغییری در آن حاصل نمیشود). برای مثال اگر کاربر یک، در صفحهی یک، متغیر استاتیکی را مقدار دهی کند، کاربر 2 نیز با مقدار به روز شدهی کاربر یک کار خواهد کرد که به طور قطع این مورد مد نظر شما نیست (چون به احتمال زیاد طراحی شما بر اساس کار کاربر در یک Session است و نه یک مقدار برای تمام سشنهای موجود در سایت) و همچنین باید دقت داشت که امنیت سیستم نیز در این حالت زیر سؤال است (زیرا در این حالت تمامی کاربران، صرفنظر از سطوح دسترسی تعریف شده برای آنها، دسترسی به اطلاعاتی خواهند داشت که نباید داشته باشند).
نکتهی دیگری را هم که باید در مورد ASP.NET به خاطر داشت این است که ویژگی ThreadStatic نیز در اینجا کمکی نمیکند؛ زیرا مطابق طراحی آن از تردها استفادهی مجدد میگردد.به عبارت دیگر در ASP.NET الزامی ندارد که آغاز یک درخواست جدید حتما به همراه ایجاد یک ترد جدید باشد.
طول عمر این نوع متغیرها هم تا زمانی است که وب سرور یا برنامه ری استارت شوند. فقط در این حالت است که نمونهی موجود تخریب شده و سپس با اجرای مجدد برنامه، بازسازی خواهند شد.
بنابراین متغیرهای استاتیک در ASP.NET همانند شیء Application عمل میکنند و از آن سریعتر هستند زیرا زمانیکه به آنها ارجاع میشود نیازی به جستجو در یک جدول و یافتن آنها نیست (برخلاف شیء Application) و همچنین در اینجا نیازی هم به عملیات تبدیل نوع دادهای وجود ندارد (برخلاف نوع شیء Application که به صورت Object تعریف شده است). وجود اشیاء Application در ASP.NET فقط به جهت حفظ سازگاری آن با ASP کلاسیک است و توصیه شده است در ASP.NET به دلایلی که ذکر شد، اگر و تنها اگر نیاز به اشیایی در سطح برنامه داشتید از متغیرهای استاتیک استفاده کنید. شیء Cache نیز در ASP.NET همین کاربرد را دارد با این تفاوت که میتوان برای آن مدت زمان منقضی شدن تعریف کرد یا اینکه وب سرور بسته به حق تقدم و اهمیتی که برای آن تعریف شده است، مجاز به حذف کردن آن در زمانی است که با کمبود منابع مواجه میشود. همچنین باید دقت داشت که تنها مکان ذخیره سازی متغیرهای استاتیک حافظه است اما امکان دخیره سازی کش بر روی فایل سیستم تا بانک اطلاعاتی و غیره نیز مهیا است.
سؤال: آیا تعریف SqlConnection به صورت استاتیک جزو مواردی است که "مگر واقعا میدانید دارید چکار میکنید؟" ؟
پاسخ: خیر. در اینجا هم واقعا این شخص نمیداند که دارد چکار میکند! یعنی در مورد سازوکار درونی ADO.NET اطلاعاتی ندارد. باز کردن یک کانکشن در ADO.NET به معنای مراجعه به استخر (pool) کانکشنها و بازکردن یکی از آنها و در مقابل، بستن یک کانکشن هم به معنای علامتگذاری یک کانکشن به صورت غیرفعال است و آماده سازی آن برای استفاده در درخواست بعدی. به معنای دیگر این عملیات سربار آنچنانی ندارد که بخواهید آنرا استاتیک تعریف کنید.
همچنین مورد دیگری را هم که این برنامه نویس نمیداند این است که متغیرهای استاتیک thread safe نیستند. به عبارتی حین استفاده از آنها در یک برنامهی چندکاربرهی ASP.NET حتما باید مکانیزمهای قفلگذاری بر روی این نوع متغیرها و اشیاء اعمال شود (که این هم خود یک سربار اضافی است در مقیاس چند 10 یا چند 100 کاربر همزمان). این مشکلات همزمانی به چه معنا است؟ فرض کنید کاربر یک، شیء استاتیک SqlConnection ایی را باز کرده است و با آن مشغول کوئری گرفتن است. کاربر 2 نیز همزمان شروع به استفاده از این کانکشن باز در حال استفاده میکند (SqlConnection استاتیک یعنی استفادهی تمام کاربران فقط و فقط از یک کانکشن باز شده)، نتیجه این خواهد بود که برای مثال پیغام خطایی را دریافت میکند مانند: فیلد مورد نظر در جدول موجود نیست! چرا؟ چون روی شیء استاتیک SqlConnection تعریف شده قفل گذاری صورت نگرفته است و در حین استفاده از آن هر کاربری در سایت نیز همان را استفاده خواهد کرد یا از آن بدتر ممکن است یک کاربر زودتر از کاربر دیگری آنرا ببندد! کاربر سوم در وسط کار با پیغام غیرمعتبر بودن کانکشن مواجه میشود، یا اینکه به صورت پیش فرض یک datareader را بیشتر نمیتوان بر روی یک کانکشن باز شده اعمال کرد. کاربر 4 مشغول خواندن اطلاعات است، کاربر 5 ، پیغام غیرمعتبر بودن کوئری را دریافت میکند.
دوچرخه های هوشمند گوگل
بعد از آزمایشهای موفقیت آمیز خودروهای گوگل نوبت به دوچرخه هوشمند گوگل هم میرسه. در این ویدیو شما شاهد هستید که دوچرخه گوگل به طور هوشمند از خیابانها و معابر عبور میکنه.
دوچه گوگل دو خصوصیت مهم داره:
یک. با استفاده گوشی میتونید بهش مکان فعلیتون رو بگید تا بیاد دنبالتون
دو. لازم نیست پا بزنید و خودش شما رو مکان مربوطه میبره و در حین اینکار شما میتونید روی دوچرخه به کارهای دیگتون برسید.
نگاهی به Duende IdentityServer 5
Securing your application is bloody important. With so much jargon to sift through, it’s easy to get lost, for example there’s SSO, OAuth2, SAML 2.0, OpenID Connect, Federated Identity, 2FA, & MFA. Just to name a few! 😱 In this talk, Anthony will take an in depth look at Federated Identity using OpenID Connect and OAuth2 Framework for ASP. NET Core using Duende IdentityServer (aka IdentityServer 5). You will walk away knowing how to navigate the security options and avoid the madness.
معرفی ASP.NET Identity
استفاده از فونت های مختلف در گزارش
بهبود SEO در ASP.NET MVC
اگر محتوای سایت شما عینا در سایتهای دیگر کپی پیست شده، چگونه میتوانید به گوگل اعلام کنید که محتوای اصلی کدام است؟ کدام یکی کپی است و کدام یک متعلق به شما است؟ برای این منظور باید ذیل مطالب خودتان تنظیمات مربوط به گوگل پلاس خود را نیز قرار دهید:
<a rel="author" href="https://plus.google.com/your_g_plus_id?rel=author">G+</a>