Web Devs

#Caching

کشینگ (Caching) چیست؟

از جمله مواردی که استفاده درست و بجا از آن به طور قابل ملاحظه ای باعث افزایش کارایی برنامه میشود Caching میباشد.درواقع Caching مکانیزمی است که داده ها را ذخیره میکند تا درخواست های آینده برای آن داده ها سریعتر انجام شود و نتیجه به کلاینت زودتر بازگشت داده شود.داده های ذخیره شده می تواند نتیجه محاسبات قبلی یا کپی ای از داده های دیگر در جای دیگری باشد.این کار برای جلوگیری از محاسبات تکراری و یا کاهش درخواست ها به دیتابیس،برای داده هایی که امکان تغییر مداوم آنها کم است و همچنین هزینه محاسبه و یا ساخت دوباره آن زیاد است، صورت میگیرد.
خوشبخانه AspNetCore از روش های مختلف Caching پشتیبانی میکند.
از جمله این روش ها به Cache In Memory و Distributed Cache می توان اشاره کرد.
روش Cache In Memory از حافظه رم سرور برای ذخیره داده های کش شده استفاده میکند. این نوع Cache متناسب برای یک سرور است و برای استفاده از این روش زمانی که چند سرور دارید از ویژگی یا تکنینک Sticky session ( که به معنی درخواست های کلاینت به همان سروری که داده ها را Cache کرده برای پردازش Route میشوند) استفاده کرد.
از روش Distributed Cache برای share کردن داده های کش شده بین چندین سرور استفاده میشود. معمولا داده ها در یک سرور خارجی نگه داشته میشوند و دیگر سرور ها به آن دسترسی دارند.

محل قرا گیری عملیات Caching در معماری پروژه هایمان کجاست؟
معماری رایج در بین وب اپلیکیشن ها غالبا یک معماری تمیز (Clean Architecture) میباشد . و ما در این پست به قرار دادن عملیات مربوط به caching در چنین معماری هایی میپردازیم.
در این قبیل معماری ها براساس اصول طراحی و قوائد تعیین شده در DDD اپلیکیشن به لایه هایی تقسیم میشود و به ترتیب داخلی ترین لایه که Domain layer میباشد و کمترین وابستگی را به یک Dll خارجی دارد و هرچه به لایه های بالاتر میرویم وابستگی لایه ها به یکدیگر بیشتر میشود. از ویژگی های یک معماری خوب Loose Coupling در بین لایه ها میباشد یعنی وابستگی لایه ها به یکدیگر را بقدری کاهش داد که با تغییر یک لایه خللی در کار دیگر لایه ها صورت نگیرد. البته در این تعریف منظور از کاهش وابستگی یعنی کاهش وابستگی در زمان Compile time.

در یک Clean Architecture یا به عبارتی در یک Clean DDD Architecture معمولا لایه های بدین شکل خواهند بود :
1 - Domain|Core layer
2 - Services | Application Layer
3 - Infrastructure Layer
4 - UI Layer

در لایه Domain اپلیکیشن Entitiy ها و Contract ها(interface) های قرار میگیرد و در لایه Infrastructure معمولا پیاده سازی دسترسی به داده ها و دیگر سرویس ها خارجی مانند FileLogger و SmtpNotifier میباشد.این لایه امکان دسترسی و ذخیره سازی دائمی داده ها را ممکن میسازد،همچنین اطلاعات موجود Domain Entity ها در دیتابیس یا هر store دیگری به صورت دائمی در این لایه برای ذخیره، پیاده سازی میشود.از سوی دیگر ریپازیتوری های ما در این لایه پیاده سازی میشوند.(ریپازیتوری محلی است که امکان دسترسی یه اینتیتی ها و valueObject ها را فراهم میکند).
برای پیدا کردن محل درست caching باید با وظیفه یک عامل دیگر اشنا باشیم.

Repository pattern

الگوی طراحی ریپازیتوری یک روش برای انتزاعی کردن دسترسی به داده ها به جای استفاده Concrete شده از آنها میباشد.
از جمله دلیل استفاده از این الگو جلوگیری از دوباره نویسی Query ها و همچنین امکان تغییر دیتابیس یا ORM اپلیکیشن را میتوان بر شمرد.
همانطور که گفتیم ریپازیتوری راه دسترسی ما به داده هاست ، این داده ها ممکن از از دیتابیس واکشی شوند یا اینکه از Cache خوانده شوند و از آنجایی که پیاده سازی الگوی Repository در لایه Infrastructure صورت میگیرد پس در نتیجه لایه قرارگیری caching نیز در همین لایه و در ریپازیتوری میباشد .
اما پیاده سازی caching در داخل خود ریپازیتوری چند مشکل اساسی دارد، مشکل، عدم تست پذیری و نقض اصل اول Solid یعنی Single responsibility میباشد.
برای حل این مشکل یک الگوی طراحی Structural به کمک ما می آید و با پیاده سازی آن این مشکل را حل میکنیم.

در این قسمت به بررسی یک سری از مسائل پایه پرداختیم و در قسمت بعدی این پست به طریقه پیاده سازی آن خواهیم پرداخت.

@fullStackDevs

blog.airbrake.io

Domain-Driven Design: What is it and how do you use it?

A detailed look at domain-driven design in software development, including basic implementation and a handful of advantages and disadvantages of its use.

www.tgoop.com/fullStackDevs/465

4.7K viewsDec 1, 2019 at 09:34

#Caching

کشینگ (Caching) چیست؟

از جمله مواردی که استفاده درست و بجا از آن به طور قابل ملاحظه ای باعث افزایش کارایی برنامه میشود Caching میباشد.درواقع Caching مکانیزمی است که داده ها را ذخیره میکند تا درخواست های آینده برای آن داده ها سریعتر انجام شود و نتیجه به کلاینت زودتر بازگشت داده شود.داده های ذخیره شده می تواند نتیجه محاسبات قبلی یا کپی ای از داده های دیگر در جای دیگری باشد.این کار برای جلوگیری از محاسبات تکراری و یا کاهش درخواست ها به دیتابیس،برای داده هایی که امکان تغییر مداوم آنها کم است و همچنین هزینه محاسبه و یا ساخت دوباره آن زیاد است، صورت میگیرد.
خوشبخانه AspNetCore از روش های مختلف Caching پشتیبانی میکند.
از جمله این روش ها به Cache In Memory و Distributed Cache می توان اشاره کرد.
روش Cache In Memory از حافظه رم سرور برای ذخیره داده های کش شده استفاده میکند. این نوع Cache متناسب برای یک سرور است و برای استفاده از این روش زمانی که چند سرور دارید از ویژگی یا تکنینک Sticky session ( که به معنی درخواست های کلاینت به همان سروری که داده ها را Cache کرده برای پردازش Route میشوند) استفاده کرد.
از روش Distributed Cache برای share کردن داده های کش شده بین چندین سرور استفاده میشود. معمولا داده ها در یک سرور خارجی نگه داشته میشوند و دیگر سرور ها به آن دسترسی دارند.

محل قرا گیری عملیات Caching در معماری پروژه هایمان کجاست؟
معماری رایج در بین وب اپلیکیشن ها غالبا یک معماری تمیز (Clean Architecture) میباشد . و ما در این پست به قرار دادن عملیات مربوط به caching در چنین معماری هایی میپردازیم.
در این قبیل معماری ها براساس اصول طراحی و قوائد تعیین شده در DDD اپلیکیشن به لایه هایی تقسیم میشود و به ترتیب داخلی ترین لایه که Domain layer میباشد و کمترین وابستگی را به یک Dll خارجی دارد و هرچه به لایه های بالاتر میرویم وابستگی لایه ها به یکدیگر بیشتر میشود. از ویژگی های یک معماری خوب Loose Coupling در بین لایه ها میباشد یعنی وابستگی لایه ها به یکدیگر را بقدری کاهش داد که با تغییر یک لایه خللی در کار دیگر لایه ها صورت نگیرد. البته در این تعریف منظور از کاهش وابستگی یعنی کاهش وابستگی در زمان Compile time.

در یک Clean Architecture یا به عبارتی در یک Clean DDD Architecture معمولا لایه های بدین شکل خواهند بود :
1 - Domain|Core layer
2 - Services | Application Layer
3 - Infrastructure Layer
4 - UI Layer

در لایه Domain اپلیکیشن Entitiy ها و Contract ها(interface) های قرار میگیرد و در لایه Infrastructure معمولا پیاده سازی دسترسی به داده ها و دیگر سرویس ها خارجی مانند FileLogger و SmtpNotifier میباشد.این لایه امکان دسترسی و ذخیره سازی دائمی داده ها را ممکن میسازد،همچنین اطلاعات موجود Domain Entity ها در دیتابیس یا هر store دیگری به صورت دائمی در این لایه برای ذخیره، پیاده سازی میشود.از سوی دیگر ریپازیتوری های ما در این لایه پیاده سازی میشوند.(ریپازیتوری محلی است که امکان دسترسی یه اینتیتی ها و valueObject ها را فراهم میکند).
برای پیدا کردن محل درست caching باید با وظیفه یک عامل دیگر اشنا باشیم.

Repository pattern

الگوی طراحی ریپازیتوری یک روش برای انتزاعی کردن دسترسی به داده ها به جای استفاده Concrete شده از آنها میباشد.
از جمله دلیل استفاده از این الگو جلوگیری از دوباره نویسی Query ها و همچنین امکان تغییر دیتابیس یا ORM اپلیکیشن را میتوان بر شمرد.
همانطور که گفتیم ریپازیتوری راه دسترسی ما به داده هاست ، این داده ها ممکن از از دیتابیس واکشی شوند یا اینکه از Cache خوانده شوند و از آنجایی که پیاده سازی الگوی Repository در لایه Infrastructure صورت میگیرد پس در نتیجه لایه قرارگیری caching نیز در همین لایه و در ریپازیتوری میباشد .
اما پیاده سازی caching در داخل خود ریپازیتوری چند مشکل اساسی دارد، مشکل، عدم تست پذیری و نقض اصل اول Solid یعنی Single responsibility میباشد.
برای حل این مشکل یک الگوی طراحی Structural به کمک ما می آید و با پیاده سازی آن این مشکل را حل میکنیم.

در این قسمت به بررسی یک سری از مسائل پایه پرداختیم و در قسمت بعدی این پست به طریقه پیاده سازی آن خواهیم پرداخت.

@fullStackDevs

BY Web Devs