همه ی کارها را میتوانید با استفاده از لایه ی سرویس به راحتی انجام دهید و نیازی به استفاده از Repository pattern ندارید.
وقتی ریپوزیتوری ندارید Unit of work هم ندارید.

لایه ها به این صورت هستند :

1- دیتابیس
2- EF
3- Repository - Unit of work
4- Service
5- Controller - ASPMVC

معمول این است که از لایه های 1 و 2 و 5 در بسیاری از پروژه های ساده و کوچک (تمرینی ، آموزشی ) استفاده میشود.
در پروژه های بزرگتر یک لایه Service اضافه میشود تا کدهای مربوط به مدیریت و ذخیره سازی اطلاعات و محاسبات تجاری از پروژه ی وب جدا شود (از کنترلر ASP)
این جدا سازی کمک میکند کدهای درون کنترلر خوانا تر باشند و عیب یابی آن ساده تر باشد . در واقع درون کنترلرها فقط باید دستورات مربوط به وب + سرویس قرار بگیرد.

حالا برای اینکه بتوانید این لایه هارا به هم وصل کنید باید از یک DI استفاده کنید.

هدف از ایجاد هر لایه اضافه کردن یک درجه ی ازادی به سیستم است. این درجه ی آزادی کمک میکند وابستگی شما به لایه پایینتر کمتر شود.
یک درجه ی آزادی مثل یک مفصل در استخوان عمل میکند. استخوانی که مفصل ندارد خم نمیشود ، میشکند.

مثلا در لایه ی 2 استفاده از EF وابستگی شما را به نوع دیتابیس از بین میبرد. شما میتوانید بجای SQL Server از MySQL ، sqlite و ... استفاده کنید.
فقط کافی است که ConnectionString رو تغییر بدید تا نوع دیتابیس تغییر کند. (خم کردن)
در حالی که بدون EF اگر شما قصد داشتید دیتابیس را تغییر دهید باید تمامی کدهایی که دیتابیس را مدیریت میکند باز نویسی می کردید. (شکستن)

اضافه کردن لایه ی Repository وابستگی شما را به EF از بین میبرد. مثلا میتوانید بجای EF از NHibernate استفاده کنید .
ضمن اینکه امکان تست دیتابیس به صورت مجزا ممکن میشود. تغییرات در دیتابیس مستقیما روی کدها شما تاثیر نمیگذارد.
مثلا ممکن است یکی از ستونهای جدول را حذف کنید.
چون لایه ی سرویس دیتابیس را نمی بیند متوجه این تغییر نمیشود و کدهای شما بدون مشکل بیلد میشوند.
این قضیه در پروژه های بزرگ که تیمهای جداگانه روی قسمتهای مختلف پروژه کار می کنند بسیار کاربر دارد.

وقتی از Repository استفاده میکنید حافظه ی موقت EF را از بین میبرید. به معنی که EF از وضعیت قبلی خود آگاه نیست و هر بار باید دوباره اطلاعات را بخواند. اینجاست که مفهوم Unit of work نیاز میشود. مثلا در تراکنش بانکی لازم است واریز کنند و برداشت کننده هر دو رکورد ثبت داشته باشند تا تراکنش موفق اعلام شود. اگر از اولی برداشته شود ولی به دومی واریز نشود تراکنش مردود است.
قابلیت استفاده از Transaction در EF وجود دارد ولی با آمدن Repository دیگر کار نمیکند.

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

1- پروژه ای وجود ندارد که صد در صد اصولی پیاده شده باشد.
2- اصول و قونین هم صد در صد درست و بی نقص نیستند
3- همه ی اصول و قوانین تغییر میکنند.
4- هرچقدر از عمر یک پروژه میگذرد اصول و قوانین بیشتری در آن شکسته میشود.
5- عمر پروژه های نرم افزاری اونقدر نیست که عمرتون رو برای نوشتن نسخه ی کامل و بی نقص اون پروژه تلف کنید.

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