Few things about Repository Pattern that I simply don't understand - repository-pattern

Question

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

Answer 1

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.