EntityFramework allows me to create tables from POCO classes.
The Repository pattern allows me to create an abstraction layer on top of the database concepts, so that I can focus on programming the actual application.
But then, the UnitOfWork (UoW) pattern. This is a pattern that is greatly advertised on the Web, especially in combination with EF.
I am using multiple Repositories, and I do have the need of committing stuff in an Atomic fashion. Then I every UoW example, I see that they implement a method SaveChanges which does nothing else then pass the call to DbContext.SaveChanges. That feels a bit thin so I probably miss the point. Or is the UnitOfWork nothing more than a DbContext wrapper?
Example scenario:
I have a MultiTenant web-application. When a new Tenant is created, the user that created the Tenant also needs to be stored as user for the newly created Tenant. The class that is responsible for creating a new Tenant and assign the first User in my current case is the Tenant class itself. If something fails, neither the Tenant nor the User should be stored in the database.
The way I handle this now, is that the DbContext.SaveChanges is not called before all actions are successfully executed.
Could somebody (preferring an expert in this domain who actually uses UoW in real EF solutions) explain the advantage for using a UnitOfWork over relying on the DbContext?
Could the expert also tip me on naming conventions? TenantAndUserUnitOfWork strikes me as long and free for interpretation (not something that you expect in an object oriented world or am I wrong?)
An unit of work is a good way of representing a domain transaction. So, does it add value to an application using it (either having Entity Framework or any other underlying storage approach)?
Yes: a good software should implement atomic operations in some scenarios.
Everything could be part of an unit of work.
Answer: yes, if you want to produce serious software.