این کار حجم کد نویسی رو بالا میبره اما بدون شک در پروژه های بزرگ ارزش خودشو داره. اگر از Repository استفاده نکنید دستورات برقراری ارتباط با بانک رو کجا باید قرار بدید !؟

در کنترلر یا WebAPI نوشتن دستورات برقراری ارتباط با بانک کار اصلی کنترلر هارو که آماده سازی و انتخاب ویو مناسب هست رو بیشتر میکنه و بهش کار با بانک رو هم اضافه میکنه . مخصوصا اگر قرار باشه جستجو یا فیلترینگ انجام بدید حجم کد درون کنترلر زیاد میشه.
بعد بعضی ها با استفاده از Code Refactor متهدهای Private درون کنترلر میسازند که کار ارتباط با بانک و جستجو و ... رو انجام میده ، بعدا متوجه میشوند بهتره متدهای کار با بانک رو به یک کلاس دیگه منتقل کنند و اسمشو بزارن Repository

در یک پروژه از ابتدا با Repository کار کردیم یعنی کدهای ارتباط با بانک در یک پروژه ی مجزا با بانام Repository ساختیم. بعدا وقتی لازم شد یک بخش از کار رو با Winform هم پشتیبانی کنیم کار ما خیلی ساده بود. فقط کافی بود یک Reference به پروژه ی Repository بزنیم و همه چیز آماده بود. این درست زمانی بود که متوجه شدیم که بهتره از Service هم استفاده کنیم و ارتباط بین کنترلر ها از طریق یک لایه ی دیگر به نام Service با Repository برقرار بشه و نه مستقیما و بعد برای کار بهتر از IoC و Dependency Injection استفاده کردیم و Ninject رو هم پیاده کردیم و این مدلی هست که در تمام پروژه های بعدی استفاده می کنیم.

مسئله اینه که استفاده از Repository بدون Service معنی نمیده ، مثل یک توپ کم باده ، میشه قلش داد اما شوتش کنید معلوم نیست کجا میره و جای دوری هم نمیتونه بره ! و بعد وقتی Service ها رو هم اضافه می کنید (منظورم WCF Service نیست) متوجه میشوید که حالا کلی کلاس دارید که برای استفاده از آنها باید مدام از new استفاده کنید و اینجاست که از Invertion Of control Container به داد شما میرسه و ابزاری مثل Unity و Ninject رو پیاده می کنید که کار ساختن کلاس ها رو انجام میدهند .

اگر بخواهید از این مدل استفاده کنید باید همه ی راه رو بروید و حجم کد زیادی بنویسید در ضمن اینکه دیگر باید همه ی کلاسها را از طریق یک اینترفیس تعریف کنید . چون همه ی IoC Container ها با اینترفیس کار می کنند. ولی اگر یکبار با این روش کار کنید دیگر نمیتوانید از آن دست بکشید