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?
-
Interesting. Are you asking out of curiosity or because you are dissatisfied with it? If the latter, why? – anon Feb 12 '11 at 20:04
-
@anon - curiosity :) - Trying to figure out which other alternatives there is, since the repository pattern seems to be the most widely (and almost also the only one) used. – ebb Feb 12 '11 at 20:08
1 Answers
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.

- 82,527
- 56
- 270
- 393
-
Thanks for you answer :) - As you said then DAO is sitting "on top" of the repository and is therefore very similar to a repository. Do you know any benefits of just using DAO instead of a Repository? – ebb Feb 12 '11 at 20:00
-
There are at least two other options in my edited answer, but I'd say Repository is by far the cleanest, especially if you're using C# and have access to LINQ or Entity framework which provide a lovely deferred-execution IQueryable collection type. – Adam Rackis Feb 12 '11 at 20:05
-
2"DOA ... often sits on top of the repository" goes against the things I've read so far. It's an "abstract interface to some type of database or persistence mechanism". Repository is not an (direct) abstraction for persistence. See [difference between DAO and Repository](https://stackoverflow.com/questions/8550124/what-is-the-difference-between-dao-and-repository-patterns). Also a list of comparisons: [Repository vs DAO](https://github.com/akinuri/software-development-concepts/tree/main/Repository%20vs%20DAO) – akinuri Feb 01 '21 at 11:15