Alternatives to the repository pattern?

Question

People have yelled at me, that I should always use the repository pattern, which I've done for quite a while... Now I'm wondering whether there is any decent alternatives for this pattern at all?

Answer 1

Well there's the Data Access Object pattern, but that often sits on top of the repository, and serves to wrap up complex queries so they can simply be called as a single method.

Repository provides a standard interface into your database, and DAO exposes standard queries, which is why the two go together so well; DAO forwards specific calls to repository. Of course you could certainly choose to not use a repository in your DAO. You could open a connection to your DB and run the queries directly, or use a Table Data Gateway, but I think the reason most people prefer Repository is because it's quite a bit cleaner than those two options, though they shouldn't be yelling at you :)

http://en.wikipedia.org/wiki/Data_access_object

In computer software, a data access object (DAO) is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database. It provides a mapping from application calls to the persistence layer. This isolation separates the concerns of what data accesses the application needs, in terms of domain-specific objects and data types (the public interface of the DAO), and how these needs can be satisfied with a specific DBMS, database schema, etc. (the implementation of the DAO). This design pattern is equally applicable to most programming languages, most types of software with persistence needs and most types of database, but it is traditionally associated with Java EE applications and with relational databases accessed via the JDBC API because of its origin in Sun Microsystems' best practice guidelines[1] ("Core J2EE Patterns") for that platform.