امید احمدپور امید احمدپور
اشتراک‌ها
مفهوم و پیاده سازی Scalability در CQRS

اگر به مبحث CQRS علاقمند هستید و میخواهید بطور کامل و درست اونو تو پروژه‌های خودتون پیاده سازی کنید و از پرفرمنس اپلیکیشن خود راضی باشید، ریپازیتوری ای را که معرفی می‌کنم، دنبال کنید.

یکی از مزایای CQRS ، Scalability است. بدون Scale کردن ، کل اپلیکیشن ما درون یک سرور قرار دارد و تنها به منابع یک سرور محدود می‌شود. با گذشت زمان و رشد اپلیکیشن منابع بیشتری مورد نیاز خواهد بود و باید این سرور را قوی‌تر کنیم که این ماجرا هزینه بر است.

چونکه عملیات خواندن بیشتر از نوشتن، آپدیت و حذف اطلاعات درخواست می‌شود درنتیجه بار بیشتری روی کوری‌های اپلیکیشن هست ، پس جداسازی دیتابیس‌های Query و Command می‌تواند تاثیر چشمگیری در سرعت و کارایی اپلیکیشن شما داشته باشد.

بدین ترتیب می‌توانیم برای عملیات Read ، سرور را قویتر و برای باقی عملیات از سرورهای ضعیف‌تر استفاده کنیم و این چیزی است که توسط Scalability فراهم می‌شود.

در این پروژه کانتکست‌ها و ریپازیتوری‌های خواندن و نوشتن جدا شده است و به این ترتیب میتونید در Query ‌ها از کانتکست یا ریپازیتوری خواندن و در Command ‌ها از کانتکست یا ریپازیتوری نوشتن استفاده کنید.

یک راه برای جداسازی دیتابیس‌های خواندن و نوشتن استفاده از تکنیک Always On اسکول سرور است که بعد از پیاده سازی آن، شما می‌توانید کانکشن استرینگ‌های دیتابیس‌های خود را در فایل appsettings.json قرار داده و دیتابیس Command و Query اپلیکیشن خود را بدین ترتیب جدا سازی نمایید.

راه حل دیگر می‌تواند این باشد که در پیاده سازی ریپازیتوری خواندن خود از  Dapper  برای کوری گرفتن استفاده کنید که کارایی و سرعت آن در مواردی به مراتب بیشتر از ef است.

یک راه بهتر می تواند طراحی دیتابیسی باشد که جداول Denormal و  Flat داشته باشد که تمام فیلدهای مورد نیاز درون آن قرارگیرد. سپس با هر بار درج اطلاعات در دیتابیس Command این جداول نیر آپدیت شوند. با داشتن این جداول دیگر نیاز به Join های عجیب و غریب  SQL  نداریم.

بسته به بیزینس مورد نظر و منابع موجود می‌توانید از تکنیک ها، ابزارها و دیتابیس‌های دیگری هم در پیاده سازی‌های خود استفاده کنید.

مفهوم و پیاده سازی Scalability در CQRS
‫۳ سال و ۴ ماه قبل، پنجشنبه ۲۳ اردیبهشت ۱۴۰۰، ساعت ۲۰:۴۷
وحید نصیری وحید نصیری
مطالب
امکان یافتن پیش از موعد مشکلات قالب‌های Angular در نگارش 5 آن
مشکلات کامپوننت‌های Angular را چون با زبان TypeScript تهیه می‌شوند، می‌توان بلافاصله در ادیتور مورد استفاده و یا در حین کامپایل برنامه مشاهده کرد؛ اما یک چنین بررسی در مورد قالب‌های HTML ایی آن در زمان کامپایل انجام نمی‌شود و اگر مشکلی وجود داشته باشد، این مشکلات را صرفا در زمان اجرای برنامه در مرورگر می‌توان مشاهده کرد. برای رفع این مشکل و بهبود این وضعیت، در نگارش 5.2.0 فریم ورک Angular (و همچنین Angular CLI 1.7 به بعد)، پرچم جدیدی به تنظیمات کامپایلر آن اضافه شده‌است که با فعالسازی آن، مشکلات binding احتمالی در قالب‌های کامپوننت‌ها را می‌توان یافت. زمانیکه توسط Angular CLI یک برنامه‌ی Angular را در حالت AoT کامپایل می‌کنیم، کامپایلر مراحلی را طی می‌کند که توسط آن کدهای یک قالب کامپوننت، تبدیل به دستور العمل‌هایی قابل اجرای در مرورگر می‌شوند. در طی یکی از این مراحل، کامپایلر قالب‌های Angular، از کامپایلر TypeScript برای اعتبارسنجی عبارت‌های binding استفاده می‌کند. اکنون می‌توان خروجی این مرحله را نیز در حین کار با Angular CLI، مشاهده و مشکلات گزارش شده‌ی توسط آن‌را برطرف کرد.


فعالسازی بررسی مشکلات قالب‌های کامپوننت‌ها

برای فعالسازی بررسی مشکلات قالب‌های کامپوننت‌ها، نیاز است به فایل تنظیمات کامپایلر TypeScript و یا همان tsconfig.json مراجعه کرد و سپس قسمت جدیدی را به آن به نام angularCompilerOptions، افزود:
{
  "compilerOptions": {
    "experimentalDecorators": true,
    ...
   },
   "angularCompilerOptions": {
     "fullTemplateTypeCheck": true,
     "preserveWhiteSpace": false,
     ...
   }
 }
- در اینجا با معرفی خاصیت fullTemplateTypeCheck و تنظیم آن به true، مشکلات موجود در قالب‌ها را در زمان کامپایل برنامه می‌توانید مشاهده کنید.
- البته این خاصیت در حین استفاده‌ی از یکی از دستورات ng serve --aot  و یا  ng build --prod انتخاب می‌شود.
- مقدار این پرچم در نگارش‌های 5x به صورت پیش‌فرض به false تنظیم شده‌است؛ اما در نگارش 6 آن به true تنظیم خواهد شد. بنابراین بهتر است از هم اکنون کار با آن‌را شروع کنید.


یک مثال: بررسی خاصیت fullTemplateTypeCheck

فرض کنید اینترفیس یک مدل را به صورت زیر تعریف کرده‌اید که فقط دارای خاصیت name است:
export interface PonyModel {
   name: string;
}
سپس یک خاصیت عمومی را بر همین مبنا در کامپوننتی، تعریف و مقدار دهی اولیه کرده‌اید:
import { PonyModel } from "./pony";

@Component({
  selector: "app-detect-common-errors-test",
  templateUrl: "./detect-common-errors-test.component.html",
  styleUrls: ["./detect-common-errors-test.component.css"]
})
export class DetectCommonErrorsTestComponent implements OnInit {

  ponyModel: PonyModel = { name: "Pony1" };
اکنون در قالب این کامپوننت، به شکل زیر از این وهله استفاده شده‌است:
 <p>Hello {{ponyModel.age}}

در این حالت اگر fullTemplateTypeCheck فعال شده باشد و دستور ng build --prod را صادر کنیم، به خروجی ذیل خواهیم رسید:
 \detect-common-errors-test.component.html(5,4): : Property 'age' does not exist on type 'PonyModel'.
همانطور که ملاحظه می‌کنید اینبار خطاهای کامپایل فایل html نیز در خروجی کامپایلر ظاهر شده‌است و عنوان می‌کند خاصیت age در اینترفیس PonyModel وجود خارجی ندارد.

برای اینکه بتوانید به حداکثر کارآیی این قابلیت برسید، بهتر است گزینه‌ی strict را در تنظیمات کامپایلر TypeScript روشن کنید و خودتان را به کار با نوع‌های نال نپذیر عادت دهید. به این ترتیب می‌توانید تعداد خطاهای احتمالی بیشتری را پیش از موعد و پیش از وقوع آن‌ها در زمان اجرا، در زمان کامپایل، پیدا و رفع کنید.


یک نکته‌ی تکمیلی
افزونه‌ی Angular Language service نیز یک چنین قابلیتی را به همراه دارد (و حتی در نگارش‌های پیش از 5 نیز قابل استفاده است).
‫۶ سال و ۷ ماه قبل، شنبه ۱۹ اسفند ۱۳۹۶، ساعت ۱۸:۲۵
علیرضا صبوری علیرضا صبوری
نظرات اشتراک‌ها
پیش نمایش Rider 2019.1
miss click روی امتیاز باعث شد مجبور بشم کامنت بزارم ... ممنون
‫۵ سال و ۷ ماه قبل، شنبه ۲۵ اسفند ۱۳۹۷، ساعت ۱۳:۵۸
میثم میثم
نظرات مطالب
EF Code First #4
ممنون از توضیح شما
من درک درستی از کامنت اول این پست و پاسخ شما نداشتم الان همه چیز روشن شد
تشکر فراوان
‫۱۲ سال و ۴ ماه قبل، سه‌شنبه ۱۳ تیر ۱۳۹۱، ساعت ۱۸:۳۱
مهمان مهمان
نظرات مطالب
ظهور میکرو ORMs
سلام.
چرا اسم من که در پست زیر در نظرات عوض شده؟!
شده صدای سکوت !
کامنت هشتم
‫۱۳ سال و ۷ ماه قبل، دوشنبه ۵ اردیبهشت ۱۳۹۰، ساعت ۱۳:۱۱
وحید نصیری وحید نصیری
نظرات مطالب
گروه بندی اطلاعات و گزارشات Master-Details در PdfReport
- لطفا برای سؤالات بعدی از قسمت پرسش و پاسخ مرتبط با این پروژه در سایت استفاده کنید. 
+ یعنی تاریخ مدنظر معتبر نیست (obj دریافتی از نوع DateTime نیست). بهتر است از DateTime.TryParse استفاده کنید تا مشخص شود، اطلاعاتی که با آن کار می‌کنید، قابل پردازش هستند یا خیر. یک break point روی آن قرار دهید و محتوای آن‌را بررسی کنید.
‫۱۰ سال و ۶ ماه قبل، سه‌شنبه ۱۶ اردیبهشت ۱۳۹۳، ساعت ۱۶:۲۸