I'm getting into the Repository pattern (which I love), and as I read up on it I see this UnitOfWork pattern in many articles. Before I knew anything about UnitOfWork I was just using my Repository pattern inside my service layer (business logic). This seems to work great so I'm wondering why having another layer (ie. UnitOfWork) may be beneficial?
Why would I want a UnitOfWork layer in my service/business logic layer? If your service layer is specific enough and doesn't cover everything under the sun then it doesn't seem like it's needed.
Note that I'm looking at this from an EF perspective. I've even read articles where people mention that EF's DbContext is a UnitOfWork. So why make my own UnitOfWork if EF's DbContext already does this for me? Why not create my DbContext in my service layer and then pull in the repositories I need and do all good?
The Repository I get because it makes testing my services easier, but I don't see the benefit of a UnitOfWork especially if you are using an ORM.