CODEWITHSUNDEEP
c#design-patternsrepository-pattern
Gup3rSuR4c
Gup3rSuR4c

Reputation: 9480

Services and Repositories in DDD (C#)

How do Services and Repositories relate to each other in DDD? I mean, I've been reading up on DDD for the past 2 days and everywhere I go, there's always a Service layer and there's always a Repository layer. How do these differentiate or compliment each other?

From what I've read, isn't the Repository the layer responsible for delegating interactions between the application and the data?

So, what's the need for the Service layer if it has to implement the Repository to interact with the data anyway even though the Repository probably already implements the methods needed to do so?

I'd appreciate some enlightenment on the subject.

P.S. Don't know if this will help any, but I'm working with an ASP.NET MVC 2 application in which I'm trying to implement the Repository pattern. I just finished implementing the Dependency Injection pattern (for the first time ever)...

UPDATE

Okay, with so many answers, I think I understand what the difference is. So, to review (correct me if I'm wrong):

So, then I have a sub question. Is it considered bad practice to create abstract objects to be sent to my views? For example an AEmployee (A for abstract because to me I means interface) which contains properties from Employee and X or X?

Actually, one more subquestion. If a Service layer can be considered "tuned" for an application does it need to be implemented with an interface?

Upvotes: 32

Views: 19247

Answers (5)

Todd Smith
Todd Smith

Reputation: 17272

As a concrete example a Shopping Cart application might have the following services:

ShoppingCartService - manages a cart of items with add/remove/update support etc.

OrderService - take a cart, converts it to an order and handles the payment process etc.

each of these services needs to talk a "data source" for CRUD operations. This is where the Repository pattern comes in handy as it abstracts the loading and saving of data to and from the data source be it a database, web service or even in-memory cache.

When you want to create a quick prototype of your application without having to deal with database setup, schema, stored procedures, permissions, etc. you can create a cache or fake repository in a matter of minutes.

For the example above your prototype might start off with the following:

  • FakeCustomerRepository
  • FakeAddressRepository
  • FakeCartRepository
  • FakeCartLineItemRepository
  • FakeOrderRepository
  • FakeOrderLineItemRepository

once your prototype is ready to evolve to the next level you can implement these against a real database:

  • SQLCustomerRepository
  • SQLAddressRepository
  • SQLCartRepository
  • SQLCartLineItemRepository
  • SQLOrderRepository
  • SQLOrderLineItemRepository

Upvotes: 12

boj
boj

Reputation: 11385

True, a repository works with data (ie. SQL, Webservice etc.) but that's the only job. CRUD operations, nothing more. There is no place for stored procedure based busines logic.

The service (or business logic layer) provides the functionality. How to fullfill a business request (ie. calculate salary), what you have to do.

Oh, and this is a really nice DDD book: http://www.infoq.com/minibooks/domain-driven-design-quickly

Upvotes: 29

quentin-starin
quentin-starin

Reputation: 26628

The Service will use a Repository to retrieve an Entity and then call methods on it (the Entity) to perform the Command/task.

Upvotes: 30

James Gaunt
James Gaunt

Reputation: 14783

There's no golden standard that defines a service or a repository. In my applications a repository is (as you say) an interface into a database. A service has full access to a repository - but the service exposes a subset of functionality to its consumers.

Think of the repository as more low level. The repository has to expose many ways of accessing the underlying database. A service might combine calls to a repository with other code that only makes sense at a code level (i.e. not in the database), such as access to other state in the application, or validation/business logic that can't easily be applied in a database.

Upvotes: 4

Josh
Josh

Reputation: 10604

From what I can remember, the repository is the final class before the data. The service class can act on data retrieved from the repository. The repository is really just meant to get data to somebody else to do the work. The service layer can provide things such as business logic that all data must pass through. It could also provide for a translation between the application logic and the data layer. But again, this is just what I can remember.

Upvotes: 7

Related Questions