The repository pattern is procedural, not OOP? [closed]

Question

Well I have been reading a book on domain driven design, it is titled Patterns, Principles and Practices of Domain Driven Design(PPPDDD). I've enjoyed reading it so far, and it gives a lot of insights into DDD in .NET world. However, there is one thing that bothers me a lot. In chapter 21(Repository pattern), the author made these two claims:

Claim 1:

The repository is not an object. It is a procedural boundary and an explicit contract that requires as much effort when naming methods upon it as the objects in your domain model do.

Claim 2:

The repository is the contract between the domain model and the persistence store. It should be only written in terms of the domain and without a thought to the underlying persistence framework. Define intent and make it explicit; do not treat the repository contract like object oriented code.

So the repository pattern is not OOP, but procedural? Do you agree with the claims made by the author of this book? Why does being explicit about repository methods, such as findByUsername(string Username) make repository procedural in nature?

I want to write OO code, not procedural code. If repository is procedural, it kills the purpose of me using this pattern at all. I really hope what the author said isnt true, what do you think?

btw, I have provided snapshots of the section in which the book author claimed repository is procedural below, take a look at them if it helps:

Answer 1

The repository is not an object. It is a procedural boundary

I completely disagree with this. A repository is a collection of things.

If you GetAll() then Add() something to a Repo and then GetAll() again, you don't expect to get the same result. The thing you are talking to has changed

=> It has an internal state, or at least that's how it seems to behave to the outside world.

It hides its internal state, a.k.a. encapsulates it, because all you can access is the interface and not the underlying persistence details.

You can pass messages to a Repository (call its methods) and have a potentially long "discussion" with the same repository.

The object form is perfectly suited for the kind of job a Repository does.

The use of the word procedural in the book is awkward at best, misleading at worst. The fact that it has an explicit contract has nothing to do with a procedural style of programming.

Answer 2

I think the author wants to stress a certain point, but in doing so creates confusion. For example

The repository is not an object.

If not an object, then what? The book seems to be in the context of .NET, so surely the author does not mean we should create static repository functions. That would just be ridiculous.

I can assure you, a repository IS a normal .NET object.

That being said, you don't "see" much of its object-oriented nature when using it. A repository is a service-like object that appears "flat", i.e. it doesn't expose a navigable object structure, just methods. This is stated by the author in the sentence

do not treat the repository contract like object oriented code

Another statement,

Define intent and make it explicit

is often ignored in my experience. Often generic repository implementations that are able to handle all types of domain objects are created. While this may seem like a good idea at first, it is not in the spirit of DDD. You should create repositories with explicit finder methods that make sense in the context of your domain.

So with that out of the way, I think your fear of procedural code is probably unjustified. C# is a mixed-paradigm language, and programming in the small is often procedural, imperative programming. With newer language features it's become increasingly simple to approach the same problems with functional programming (which I'm a big fan of) as well, e.g. with LINQ, but that does not make procedural styles bad. And programming in the large still happens in an object-oriented way.