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.