1

In Fowler's book "Patterns of Enterprise Application Architecture" there is no mention of persistent features of the Repository pattern. By "persistent features" I mean such features that update, save, add or delete entities. Just pure matching mechanism over a set of domain objects.

On the other side, lets take a look at Mike Hadlow's blog post named Using the IRepository pattern with LINQ to SQL. There are concrete persistent methods like insert and delete.

So how should a repository pattern be implemented? Could you guys please point me towards good "true" repository implementations. I'm getting some frustration on this topic.

Thanks in advance! Hope for your help!

Gordon
  • 312,688
  • 75
  • 539
  • 559
kseen
  • 359
  • 8
  • 56
  • 104
  • 1
    What do you need it do? Implement that. – John Buchanan Dec 09 '11 at 07:00
  • 3
    A repository is nothing more than an abstraction layer between your data source and your application. whether it has persisting funcionality or read functionality or both is not relevant – Polity Dec 09 '11 at 07:10

1 Answers1

2

A repository should just act like an in-memory collection of data. The nomenclature you choose, whether it be Add or Insert, Delete or Remove, Select or Get, is not important.

You could separate your repository into 2 interfaces, and then have a ReadOnlyRepository for getting / selecting data, and a WriteRepository for adding / updating / deleting data. It doesn't matter. What matters is that your application or business code uses the repository to interact with data as if it was already loaded into memory, so you don't have to craft SQL queries intermingled with business or application code.

Update

Since we're talking about a pattern, there is not a single "true" repository interface or implementation. There can be many different implementations that all follow a similar pattern.

danludwig
  • 46,965
  • 25
  • 159
  • 237