I've read quite a few topic on what Repository is, but there are still few things bugging me.
To my understanding only difference between Repository and traditional data access layers are Repository's query construction capabilities ( ie Query Object pattern). But when reading the following definitions of a Repository Pattern, it seems we can still have Repository even if we don't implement Query Object pattern:
a) From:
Repositories are the single point where we hand off and fetch objects. It is also the boundary where communication with the storage starts and ends.
I think above quote suggests that Repository is an entry point into DAL. In other words, according to the quote, the DAL consumer (say Service layer) comunicates with DAL via Repository. But shouldn't instead data context represent an entry point into DAL ( thus Repository should reside within data context )?
b) From:
The primary thing that differentiates a Repository from a traditional data access layer is that it is to all intents and purposes a Collection semantic – just like IList in .Net
Don't most traditional DALs also have methods that return a collection (for example List<Customer> GetAllCustomers()
)? So how exactly is a collection-like semantic of a Repository any different from collection-like semantic of a traditional DAL?
c) From:
In a nutshell, the Repository pattern means abstracting the persistence layer, masking it as a collection. This way the application doesn't care about databases and other persistence details, it only deals with the abstraction (which usually is coded as an interface).
As far as I know, the above definition isn't any different from the definition of a traditional DAL. Thus, if Repository implementation only performed two functions – having the collection-like semantics and isolating the domain objects from details of the database access code – how would it be any different from a traditional DAL? In other words, would/should it still be called Repository?
d) What makes the following interface a Repository interface instead of just a regular DAL interface?
From:
public interface IPostsRepository
{
void Save(Post mypost);
Post Get(int id);
PaginatedResult<Post> List(int skip,int pageSize);
PaginatedResult<Post> SearchByTitle(string title,int skip,int pageSize);
}
Thank you
The Repository pattern allows you to easily test your application with unit tests. Remember that unit tests only test your code, not infrastructure, so the repository abstractions make it easier to achieve that goal.
They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources.
A repository is a specialisation of the Facade pattern which is structural.
A repository provides an interface to access data stored in the database or external resources. Data is returned in the form of objects. Repositories act as a bridge between the models and the controller. By using Repository Pattern we can decouple the hard dependencies of models from the controllers.
FYI I asked a very similar question over here and got some excellent answers.
The bottom line is it appears to depend on the complexity of your architecture. The repository pattern is most useful to create a layer of abstraction when you need to access different types of data stores, i.e. some data is in entity framework, some is on the file system, etc. In simpler web apps with a (probably unchanging) single data store (i.e. all data in SQL Server, or Oracle, etc) it is less important. At that point something like the Entity Framework context object functions as a repository for your entity objects.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With