ریپازیتوری در مورد مسائل زیادی صحبت می‌کند، به ویژه در دنیای قدرتمند مایکروسافت و API. بیایید در مورد الگوی ریپازیتوری صحبت کنیم و برخی از دلایلی که باید از آن استفاده کنید و دلایلی که بهتر است از این الگو استفاده نکنید را بررسی کنیم.

الگوی ریپازیتوری چیست؟

الگوی ریپازیتوری یک استراتژی برای واکشی و دسترسی به داده‌ها می‌باشد. بیایید کمی مسأله را باز کنیم، دسترسی به داده در برنامه توسط کدها ایجاد می‌شود که با ذخیره‌سازی و بازیابی داده‌ها سر و کار دارد.

شاید شما از SQL Server برای ذخیره‌سازی مجموعه‌ای از آیتم‌های لیست TO-DO در یک جدول استفاده می‌کنید. شما مجبور بودید به نحوی با رابط‌های SQL Server کد را بنویسید، یا ممکن است با Entity Framework، Dapper یا با برخی کتابخانه‌های درونی NET. این کار را انجام دهید.

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

//pseudocode!

var connectionString = "myLocalDb"
var sqlCommand = new SqlCommand(connectionString);
sqlCommand.commandText = "INSERT INTO TodoItems VALUES(@name, @description);";
sqlCommand.params["@name"] = todo.name;
sqlCommand.params["@description"] = todo.description;

sqlCommand.execute();

//some other db connection cleanup code...

این کد رابط بین اشیای Todo  شما در برنامه‌یتان و ورودی‌های سطرهای جدول TodoItem در پایگاه داده SQL Server می‌باشد.

بنابراین، تعامل زیادی وجود ندارد، درست است؟ چرا باید یک الگوی خارجی برای جداسازی داده‌ها وجود داشته باشد؟

چرا لایه داده‌ها را جدا می‌کنید؟

واضح‌ترین دلیل این است که سعی می‌کنیم نوشتن کدهای تکراری را کاهش دهیم.

تصور کنید همان کد تکراری را چندین بار در برنامه خود نوشته‌اید. یک بار در API بنویسید بنابراین API شما می‌تواند آیتم‌های Todo، آیتم‌های متصل به هم در پشت صفحات UI برنامه دسکتاپ و قسمت‌های تصادفی مختلف دیگر را به طور مؤثر ذخیره کند.

حالا اگر هر کدام از این اتفاقات رخ دهد چه می‌شود:

1. یک فیلد جدید به جدول TodoItem در SQL Server اضافه شود.

2. شرکت شما می‌خواهد به MySQL مهاجرت کند.

3. شما نوشتن تست را نادیده گرفته‌اید و از امروز می‌خواهید شروع کنید.

در هر یک از این موارد، برای اعمال این تغییرات نیاز دارید تا کارهای زیادی را انجام دهید. هر تغییری در جدول پایگاه داده، نیاز به تغییر در هر قسمت از برنامه دارد که آیتم‌ها را در آن جدول ذخیره می‌کند. سوئیچ کردن به MySQL نیاز به بازنویسی کامل دارد.

خیلی بد و خیلی خطرناک

وقتی آیفون نوع کابل شارژ خود را روی تلفن تغییر می‌دهد شما ناراحت می‌شوید؟ شما مقدار زیادی پول و زمان را برای لوازم جانبی برای یک نوع خاص صرف می‌کنید. ممکن است آیفون یک روزی به سمت USB-C برود و دنیای آیفون و اندروید در لوازم جانبی مشترک dongle-free (آداپتور بی‌سیم) متحد شوند.

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

بنابراین اکنون به جای کد بالا، چیزی شبیه به دستور زیر را دارید:

//pseudocode!

todoRepository.save(todo);

حالا اگر هر کدام از تغییرات بالا مورد نیاز باشد، فقط باید کد پشت متد save() ریپازیتوری را تغییر دهید. شاید یک رابط پایگاه داده داشته باشید که کد INSERT اس کیوال سرور را پیاده‌سازی می‌کند، اما هیچ مانعی برای تغییر به MySQL، مکانیزم ذخیره‌سازی API خارجی یا حتی mock database برای تست واحد وجود ندارد.

آیا دلیلی برای استفاده نکردن از ریپازیتوری وجود دارد؟

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

پروژه‌های جانبی یا برنامه‌های آزمایشی؟ وقتی دسترسی به داده‌ها ثابت است، زمان خود را صرف نوشتن کد ریپازیتوری نکنید.

دلیل دیگر ممکن است این باشد که شما در حال کار روی برنامه‌ای هستید که قبلا از استراتژی متفاوتی استفاده می‌کرده است. یکی از استراتژی‌های رایج داشتن کد ذخیره‌سازی/گرفتن درون موجودیت‌ها است (مثل todo.save()).

اگر در حال کار بر روی یک پروژه قدیمی هستید که از الگوی متفاوتی استفاده ‌کرده است، الگوها را در هم نیامیزید مگر اینکه قصد جدا کردن تکنولوژی دسترسی به داده‌ها را داشته باشید.

در این مقاله دلایل استفاده کردن و نکردن الگوی ریپازیتوری را بررسی کردیم. اگر این مقاله برایتان مفید بود آن را با دیگران با اشتراک بگذارید.

آموزش asp.net mvc