It's not the first time I am asking this myself. However, since ASP.NET Boilerplate puts a lot of effort in further abstracting the database access with generic repositories I would like to ask about the reasoning behind this. Of course, the first argument that comes in everyones mind is unit testing. But lets be honest, most companies, and especially small ones don't write unit tests at all (since customers obviously won't pay for things they do not see). Is there any other point in using the repository pattern?
1 Answer(s)
-
0
OK, this is a long discussion point (asked before in several times as I remember. for example: <a class="postlink" href="https://github.com/aspnetboilerplate/aspnetboilerplate/issues/525">https://github.com/aspnetboilerplate/as ... issues/525</a>).
I can say these:
Using repositories in a known pattern in DDD (<a class="postlink" href="http://martinfowler.com/eaaCatalog/repository.html">http://martinfowler.com/eaaCatalog/repository.html</a>). But you can say that DbContext almost implements repositories (by providing collection-like interface to access data).
The first motivation for me to include repositories into framework to provide ORM independence. This is not just for the applications, but for also the framework itself (framework uses repositories in some cases and we want to be ORM independent since ABP supports all ORMs, or plain ADO.NET, in theorically).
Another motivation is to abstract usage of DbContext/ISession and implementing ambient Unit Of Work. For example, in ABP you should not inject YourDbContext in your class but you should inject IDbContextProvider<YourDbContext>. Repositories nicely abstract that.
Another point is to see dependencies explicitly. If a class injects DbContext, it's not clear which DbSets it's using. But, if it injects IRepository<Person> we know that this class uses Person entity/table/dbset.
Another point is unit testing, but you don't care it as I see (you are right, most companies don't write unit tests, but I see this is increasing).
Another point is to abstract complex data access logic, like stored procedure usage or complex query building, into a dedicated class, repository.
Injecting IRepository<Person> allows ABP to be able to dynamically! select the DbContext. Yes, you can have more than one DbContext includes Person entity and you may want to use a DbContext conditionally. For example, one condition can be multi-tenancy. If you have a dbcontext for tenants and another dbcontext for host and both contains person dbset, you may want to use tenant dbcontext if current user is tenant user and so on...
These are the points (if I haven't missed). But, at the end of the day, ABP allows you to inject IDbContextProvider<YourDbContext> and use it freely, no problem :)
