چرا باید از الگوی repository استفاده کنیم؟

الگوی repository چیست؟

الگوی repository یک استراتژی برای جداسازی دسترسی به داده است. درواقع دسترسی به داده برای کدهای برنامه که با ذخیره‌سازی و بازیابی داده‌ها سر و کار دارند، ایجاد شده است.

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

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

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

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

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

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

فرض کنید کد یکسانی را چندین بار نوشته‌اید. یک بار در API، تا API بتواند موارد Todo را ذخیره کند؛ چندین بار در پشت صفحات UI تان؛ و همینطور چند جای دیگر (برای تاثیر دراماتیک ماجرا!)

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

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

2. شرکت تصمیم می گیرد به MySQL مهاجرت کند.

3. نوشتن unit test را نادیده گرفته‌اید و از همین حالا بخواهید شروع کنید.

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

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

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

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

//pseudocode!

todoRepository.save(todo);

حالا اگر هر کدام از تغییرات بالا مورد نیاز باشد، کافی است کد پشت متد save ریپازیتوری را تغییر دهید. ممکن است یک واسط پایگاه داده داشته باشید که کد INSERT را برای SQL Server پیاده‌سازی می‌کند، اما این مانعی برای تغییر به MySQL یا یک مکانیزم ذخیره‌سازی API خارجی به وجود نخواهد آورد.

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

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

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

دلیل دیگر ممکن است این باشد که روی برنامه‌ای کار می کنید که از استراتژی متفاوتی استفاده کرده است.

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

منبع: https://purple.pizza/why-should-you-use-the-repository-pattern/