views:

249

answers:

4

In DDD one of the key concepts is Repository, which allows you to retrieve Entities (or Aggregate Roots) and then save them back after they are updated.

Let assume that we need to perform some 'bulk' operation with entities, and the number of entities makes it absolutely impossible to retrieve them into memory. I.e. operation can only be performed in the database.

Where is the place for such 'bulk' operation? Should it be a method on repository? Won't it "leak" Repository abstraction with database specific operation? Won't it move business operation from Entity to Repository?

+3  A: 
void DoLongInvolvedTask();

I don't see anything wrong with putting bulk tasks as methods in your repository. They don't leak anything. Having a Bulk operation does not imply any database specific operations, that is unless your method is something like ReBuildMSSQLIndexesOnMyBigTable().

Darryl Braaten
+1  A: 

You should not have any save, retrieve logic in domain object (I am assuming you are using domain model). That is the responsibility of Repository. So your bulk method belongs in repository.

If you are using ORM then your repositories won't depend on database. they would jut forward all request to the ORM layer.

If you are writing your own mapper then repository would forward request to mapper for the entity. And I think this coupling is ok.

StackUnderflow
+1  A: 

What you need is called a service in domain-driven design. Services are used to model procedural tasks. A bulk update operation, like the one you describe, would be an ideal candidate for a service.

dthrasher
+2  A: 

I think it should be a service.

Evans recommends in his book, that when you are in doubt whether to put a method that "smells bad" inside a class because you think that it doesn't belong there, make a ServiceFoo class with the operation inside.

lurks