19

Is the DAO—Data Access Object—a commonly used pattern in .NET? I've always used DAOs as a way to provide access to my data layer. For example I might have a thin interface over my EntityFramework ObjectContext exposing all of my ObjectSets as IObjectSet.

Complex queries would then be exposed by DAOs, each of which with a dependency on this interface. I might have a ProductDAO that exposes methods like GetProductsOnSale() or GetInfrequenlySoldProducts(). My controllers or presenters would then use these methods, which would likely be virtual to allow stubbing specific results for unit tests.

So is this a commonly used idiom in .NET? For some reason the overwhelming majority of examples I see online using this pattern are based on Java. Even this question on DAO best practices is tagged as Java and not C#.

There's nothing wrong with using something from another community, I just have a slight fear that everyone around me is doing things differently...

Community
  • 1
  • 1
Adam Rackis
  • 82,527
  • 56
  • 270
  • 393

3 Answers3

12

It is a common idiom in .NET. I have used it and have seen it used in many places.

It is built into the framework - see the System.Data namespace - many of the classes are base classes for specialized providers (SQL Server, Oracle, MySQL etc...) and operations are executed on the base classes.

However, what you are describing sounds more like the Repository Pattern to me, not simply the use of Data Access Objects.

This is also used in many projects, though is not built into the framework.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • My understanding is that the repository is the "thing" that exposes all those `IObjectSet` members, and the DAO is the class that uses the Repository to build the queries. Is that consistent with how you use those terms? – Adam Rackis Apr 26 '11 at 19:32
  • 2
    @Adam - Not really, the `DAO` is what _abstracts_ the actual DB interface, the `Repository` is what abstracts the use of the `DAO` to represent a supposed "in memory" collection. – Oded Apr 26 '11 at 19:33
  • I see. What would you call the objects that take an instance of a repository and expose complex queries? Surely it's not a good idea to just dump all of your—probably numerous—quueries onto your repository...I'd imagine things getting pretty cluttered pretty quickly – Adam Rackis Apr 26 '11 at 19:36
  • @Adam - For something that coordinates complex interactions behind a simple interface - I would use the [Facade pattern](http://en.wikipedia.org/wiki/Facade_pattern) as a link between the code and the repository. – Oded Apr 26 '11 at 19:37
1

I use the DAO pattern extensively.

You mentioned the Entity Framework; to that I would add that I find DAO much better than DataSets and DataTables, which are too much like a database an not enough like an object for my tastes. For example, DataRows can't be added to more than one data table, so I can't pass around subsets of the loaded data to different objects without moving them to a container that wasn't built to contain them. (I.e., it seems like a DataRow should be in a DataTable, but they can only be in one DataTable at a time.) DataRowViews are clunky and not nearly as intuitive as adding entity objects to another list.

Katie Kilian
  • 6,815
  • 5
  • 41
  • 64
1

My biggest recommendation on the usage of the Repository pattern for encapsulating data access (which indeed is a very good pattern), is to be able to create a generic repository. But to create a very smart generic repository that gives you basically live wiring to immediate access to all standard CRUD operations, along with access to the complex query construct that you won't expose past you ISomeService facade.

The most important thing about using a generic repository, is you want it to be based on constructor injection and not based on inheritance. This way you can compose your SomeService to be dependent on many generic repositories that it would need to fulfill a meaningful business domain boundary.

I wrote an indepth blog on this concept. Creating a common generic and extensible NHiberate Repository version 2. While this blog post is specific in reference of NHibernate you can take the same core concepts and apply them to almost any DAO.

Note with some tools, like Entity Framework, Linq2Sql and RavenDB to name a few, they expose very refined repositories themselves and might not necessarily benefit from adding an additional wrapper.

Chris Marisic
  • 32,487
  • 24
  • 164
  • 258