Is a Repository still a Repository without Unit of Work?

Question

If you create a repository class that encapsulates all of your persistence logic for a given entity, such as PersonRepository, but your repository class does not implement the Unit of Work pattern or the Identity Map pattern, is it still considered a repository? In other words, are Unit of Work and Identity Map required for a repository implementation, or can we just call any class that encapsulates our persistence logic a repository?

I should add one thing. If a repository does not require these patterns and it's really just a container for persistence methods, then what is the difference between a repository and a DAO (Data Access Object)? Are we just creating multiple names for the same object or are we missing part of what a repository is supposed to be?

Answer 1

Yes, it is still a repository.

As for if Repository == DAO, I think Repository should be on business logic layer and DAO should be on data access layer, i.e. I think they are on different layers. So as I understand, Repository calls DAO methods to load and persist data.

Answer 2

I'd say the Repository and Unit of Work patterns aren't related.

Very frequently, I want a single unit of work to span operations on multiple repositories, so an implementation of that would belong into a higher layer.

Answer 3

Building on what Sii said - it seems better to me if the repository and the unit of work aren't related. Seperation of concerns?

Answer 4

When considering separation of concerns, remember that your Repository will have the data storage implementation methods, allowing you to keep that out of your main code. This is helpful for unit testing as well as eventually swapping out your data storage implementation altogether (an example of a data storage implementation would be LINQ-to-SQL in ASP.NET.)

blog entry on repository pattern