- مثلا زمانیکه با ORMها کار میکنید استفاده از فیلدهای Identity در حین ثبت تعداد بالایی از رکوردها مشکل ساز میشوند. چون این فیلدها تحت کنترل دیتابیس هستند و نه برنامه، ORM نیاز دارد پس از هربار Insert یکبار آخرین Id را از بانک اطلاعاتی واکشی کند. همین مساله یعنی افت سرعت در تعداد بالای Insertها (چون یکبار کوئری Insert باید ارسال شود و یکبار هم یک Select اضافی دوم برای دریافت Id تولیدی توسط دیتابیس).
- روش دوم تعیین PK استفاده از نوع Guid است. در این حالت، هم مشکل حذف رکوردها و خالی شدن یک شماره را در این بین ندارید و هم چون عموما تحت کنترل برنامه است، سرعت کار کردن با آن بالاتر است. فقط تنها مشکل آن زیبا نبودنش است در مقایسه با یک عدد ساده فیلدهای Identity.
در مورد فیلدهای Identity، تغییر شماره Id به صلاح نیست چون:
الف) همانطور که عنوان کردید روابط بین جداول را به هم خواهد ریخت.
ب) در یک وب سایت و یا هر برنامهای، کلا آدرسها و ارجاعات قدیمی را از بین میبرد. مثلا فرض کنید شماره این مطلب 1381 است و شما آنرا یادداشت کردهاید. در روزی بعد، برنامه نویس شماره Idها را کلا ریست کرده. در نتیجه یک هفته بعد شما به شماره 1381 ایی خواهید رسید که تطابقی با مطلب مدنظر شما ندارد (حالا فرض کنید که این عدد شماره پرونده یک شخص بوده یا شماره کاربری او و نتایج و خسارات حاصل را درنظر بگیرید).
ج) این خوب است که در بین اطلاعات یک ردیف خالی وجود دارد. چون بر این اساس میتوان بررسی کرد که آیا واقعا رکوردی حذف شده یا خیر. گاهی از اوقات کاربران ادعا میکنند که اطلاعات ارسالی آنها نیست در حالیکه نبود این رکوردها به دلیل حذف بوده و نه عدم ثبت آنها. با بررسی این Idها میشود با کاربران در این مورد بحث کرد و پاسخ مناسبی را ارائه داد.
و اگر شمارهای که به کاربر نمایش میدهید فقط یک شماره ردیف است (و از این لحاظ میخواهید که حتما پشت سرهم باشد)، بهتر است یک View جدید ایجاد کنید تا این Id خود افزاینده را تولید کند (بدون استفاده از pk جدول).
پ.ن.
هدف من از این توضیحات صرفا عنوان این بود که به PK به شکل یک فیلد read only نگاه کنید. این دقیقا برخوردی است که Entity framework با این مفهوم دارد و صحیح است و اصولی. اگر در یک کشور هر روزه عدهای به رحمت ایزدی میروند به این معنا نیست که سازمان ثبت احوال باید شماره شناسنامهها را هر ماه ریست کند!
ویژگیهای یک مایکرو سرویس چیست؟
Componentization via Services
Technology Heterogeneity
یک سیستم را در نظر بگیرید که از همکاری چندین سرویس تشکیل شدهاست. ما میتوانیم تصمیم بگیریم که برای هر کدام از سرویسها از تکنولوژی متفاوتی استفاده کنیم. این امر به ما اجازه میدهد برای حل هر مشکل، از بهترین ابزار و تکنولوژی استفاده کنیم. این امر بر خلاف سیستمهایی که تنها باید از تکنولوژی بکار رفته در سیستم استفاده کنند، انعطاف پذیری سیستم را بسیار بالا میبرد.برای روشن شدن موضوع فرض کنید میخواهیم در بخشی از سیستم، performance را افزایش دهیم. برای این امر میتوانیم از هر تکنولوژی که به ما کمک میکند، استفاده کنیم. برای نمونه در یک سیستم شبکه اجتماعی، میتوانیم اطلاعات مربوط به کاربران و ارتباطات آنها را در یک دیتابیس مبتنی بر گراف و اطلاعات مربوط به پستها و نظرات کاربران را در یک دیتابیس سندگرا ذخیره کنیم. به این ترتیب مشاهده میکنیم که وابستهی به تکنولوژی خاصی نمیباشیم و میتوانیم بر اساس نیاز خود، از تکنولوژی مورد نظر بهره ببریم.
مایکرو سرویسها به ما این اجازه را میدهند تا در انتخاب تکنولوژیها نهایت دقت را انجام دهیم و متوجه شویم که تکنولوژیهای جدید چگونه میتوانند به ما کمک کنند.
یکی از بزرگترین موانع در استفاده و انتخاب یک تکنولوژی جدید، ایجاد وابستگی سیستم به آن میباشد. در یک سیستم یکپارچه چنانچه قصد تغییر زبان مورد استفاده یا دیتابیس یا فریمورک مورد استفاده را داشته باشیم، سیستم هزینهی سنگینی را متحمل میشود. در حالیکه در مایکرو سرویسها میتوانیم این تغییرات را با کمترین هزینه انجام دهیم. البته باید توجه داشت که استفاده از تکنولوژی جدید چالشها و سربارهای خودش را دارد و انتخاب یک تکنولوژی جدید نیازمند بررسی کارشناسانه و دقیق میباشد.
Resilience
چنانچه یکی ازسرویسها دچار اشکال شود و این مسئله بصورت زنجیروار برای تمام سرویسها رخ ندهد، با جدا شدن آن سرویس، درروند کار سیستم خللی بوجود نمیآید و سیستم بدون کمترین مشکلی به ادامه کار خود میپردازد. یعنی محدوده یک سرویس، دیوار حائلی میشود تا سایر بخشها تاثیر نپذیرند. در سیستمهای یکپارچه چنانچه یک سرویس دچار اشکال شود، سایر بخشهای سیستم نیز غیر قابل استفاده میشوند. البته میتوان با نصب نسخههای متفاوتی بر روی ماشینهای متفاوت (Scale out)، تاثیر اینگونه اختلالات را تا حدودی کاهش داد. اما بوسیله مایکرو سرویسها میتوانیم سیستمهایی را بسازیم که قادرند با خطاهای بوجود آمده در سرویسها بهدرستی رفتار کنند؛ تا خللی در کار سیستم ایجاد نشود.Scaling
Gilt یک خرده فروش آنلاین در صنعت مد میباشد که بخاطر مسائل Performance به معماری مایکروسرویسها روی آورد. آنها در سال 2007 با یک نرم افزار یکپارچه شروع به کار کردند. اما بعد از دوسال سیستم آنها قادر به مقابله با ترافیک سایت نبود. آنها با تقسیم بندی قسمتهای اصلی سیستم خود به مایکرو سرویسها، توانستند خیلی بهتر و موثرتر با ترافیک رسیده مقابله کنند و قابلیت دسترسی پذیری سیستم را افزایش دهند. در حال حاضر سیستم آنها از حدود 450 مایکرو سرویس تشکیل شده که هر کدام روی چندین ماشین مختلف در حال اجرا میباشند.
Ease of Deployment
Organizational Alignment
Composability
Optimizing for Replaceability
معرفی کتابخانه PdfReport
از لطف شما بسیار سپاس گزارم
ارسال ایمیل در ASP.NET Core
این نیاز وجود دارد که PasswordValidator موجود در Identity را برای پروژههای مختلف سفارشیسازی کرد و این امکان فراهم شود که بتوان سیاستهای کاری شرکت و پروژه را در قالب PasswordValidator اعمال کرد. به عنوان مثال بررسی کنیم اگر پسورد کاربر عدد 12345 وارد شده است، خطا صادر کنیم و اجازه انتساب آن را برای کاربر ندهیم یا منطقهای دیگری که نیاز داریم. پس در اینجا به وجود یک CustomPasswordValidator نیاز هست است.
public class CustomPasswordValidator : PasswordValidator { public override async Task<IdentityResult> ValidateAsync(string pass) { IdentityResult result = await base.ValidateAsync(pass); if (pass.Contains("12345")) { var errors = result.Errors.ToList(); errors.Add("Passwords cannot contain numeric sequences"); result = new IdentityResult(errors); } return result; } }
نقطهی پایان کار اینجاست که در داخل کلاس کانفیگ موجود برای Identity که درون فایل web.config مشخص شده است (در این مثال کلاس IdentityConfig) برای قسمت PasswordValidator ، حالا باید از کلاس CustomPasswordValidator، یک شیء جدید ساخته شود:
// Configure custom validation logic for passwords manager.PasswordValidator = new CustomPasswordValidator { RequiredLength = 6, RequireNonLetterOrDigit = false, RequireDigit = false, RequireLowercase = false, RequireUppercase = false, };
بانک اطلاعاتی InfluxDB یکی از انواع بانکهای اطلاعات NoSQL و مدل Time Series هست که برای مدیریت دادههای سری زمانی بهینه شده است و هر ورودی با یک مهر زمانی مرتبط است.
محیط مدیریتی برای این بانک اطلاعاتی بعد از نصب از روی یک آدرس وب و با امکانات مفید در دسترس میباشد.
همچنین جهت کانکت شدن به این دیتابیس یک توکن بر اساس نام کاربری و پسوردی
که برای کاربر ساخته میشود تولید میشود که از محیط مدیریتی این بانک
اطلاعاتی بر روی وب قابل دسترس میباشد و برای اتصال از طریق دات نت از
همان توکن استفاده میکند
نمونه کد اتصال به این بانک اطلاعاتی در صفحه اول سایت influxdata.com در دسترس میباشد.
📌 مستندات جهت یادگیری پایگاه اطلاعاتی InfluxDB
همچنین از طریق نصب پکیج InfluxDB.Client امکان کوئری زدن و فیلتر کردن اطلاعات با دستورات Linq روی این پایگاه داده فراهم شده است.
جهت شروع استفاده از این بانک اطلاعاتی در دات نت میتوانید از لینک پیوست شروع به مطالعه فرمایید.
تصویر صفحه داشبورد تحت وب این دیتابیس
تصویر صفحه کار با دادهها و نمایش اطلاعات به صورت گرافهای متنوع در محیط مدیریتی این دیتابیس بر روی وب