همه‌ی دات‌نت‌کارها با Entity Framework و Repository Pattern آشنا هستن و احتمالاً اکثرمون با این بحث که آیا واقعاً نیاز به Repository داریم وقتی خود EF داره این کارو می‌کنه، درگیر شدیم. یکی از قوی‌ترین دلایلی که مخالف این پترن هست، اینه که خب ما توی پروژه‌های واقعی هیچ‌وقت نمیایم دیتابیس رو تغییر بدیم که Repository بخواد کمکمون کنه.
با اینکه این فرضیه برای اکثر پروژه‌ها درسته، اما مثال نقض هم داره. اکثر ما وقتی راجع‌به پروژه فکر می‌کنیم چیزی مثل فروشگاه توی ذهنمون میاد؛ مثل دیجی‌کالا، یا سایت‌های بانکی و مالی. و خب کاملاً درسته که توی اون‌جور پروژه‌ها نخوایم لایه‌ی دیتابیس رو تغییر بدیم. اما نرم‌افزار فقط شامل فروشگاه و حسابداری و بورس نمیشه. یه دسته از نرم‌افزارهایی هم هستند که برای اینکه توی سازمان استفاده بشن، یا تحت وب و برای عموم، باید خودمون روی سرورمون نصبشون کنیم. مثال فنی مثل Keycloak یا نرم‌افزارهای مدیریت مستندات سازمانی و بقیه‌ی نرم‌افزارهای زیرساختی، فنی و کاربردی درون‌سازمانی.
اینجور نرم‌افزارها معمولاً ، نه همیشه، به ما حق انتخاب بین چند دیتابیس رو میدن. اینجاست که استفاده از Repository و یا حتی خود EF خیلی به‌درد می‌خوره. علت اینکه همیشه ممکنه EF جوابگو نباشه هم اینه که شاید لایه‌ی داده‌مون الزاماً دیتابیس نباشه و شاید یه سرویس مجزا باشه که باید بهش HTTP Request بزنیم و داده رو بگیریم. پس باید فکر کنیم که کاربرد ما چی می‌تونه باشه و بر طبق اون پیش بریم. از اونجایی که این چند ماهه خیلی با نرم‌افزارهای این‌جوری درگیر بودم، این موضوع برام جالب بود که اگه خودم قرار باشه سیستمی طراحی کنم که چندتا دیتابیس مختلف رو بتونه ساپورت کنه، چیکار می‌کردم.

@ever_code