Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is Repository Pattern with Domain Driven Design become Anti-Pattern? [closed]

First of all I want to clarify that I am new to Domain Driven Design and I am asking this question because I have read something called Anemic Domain Model.

Most of the time I see following thing while working with Repository pattern.

  1. We have One Generic Repository
  2. We have Model that only contain set of public properties but it does not contain any method ( So It become Anemic Domain Model as per definition of DDD) because here repository class handle other process for that entity or model.

Please provide your valuable answer for my query.

Let me clarify few things.

Generic Repository means Generic interface that get implemented by Entity repository.

My confusion is regarding following thing

For example: Suppose I want to save

    public class User
    {
        public int Id { get; set;}
        public string Name { get; set};
    }

    public class UserRepository : IRepository<User>  
    {  
        // All Operation Like Save / Get /  UserEntity (Domain Object)       
    }

So here is my User class do nothing instead it just have properties and other operation handle by UserRespository. So my User is Anemic Domain model. ( As it do nothing specific)

Here in attached image I consider ProductRepository so my question is: Is My Product class an Anemic model?

Please consider following Sample Image for what I am trying to say.

enter image description here

like image 998
dotnetstep Avatar asked Aug 07 '13 05:08

dotnetstep


People also ask

Is repository pattern an anti pattern?

A generic repository is a type that comprises of a set of generic methods for performing CRUD operations. However, it's just another anti pattern and is used frequently with Entity Framework to abstract calls to the data access layer.

What is repository in domain-driven design?

Repositories are classes or components that encapsulate the logic required to access data sources. They centralize common data access functionality, providing better maintainability and decoupling the infrastructure or technology used to access databases from the domain model layer.

What type of pattern is repository pattern?

The Repository pattern implements separation of concerns by abstracting the data persistence logic in your applications. Design patterns are used as a solution to recurring problems in your applications, and the Repository pattern is one of the most widely used design patterns.

Can domain services use repository?

Yes, a domain service can access repositories.


2 Answers

I agree that the IRepository interface is generally a waste of time. If I put the basic CRUD operations in my IRepository interface, then how do I deal with data like audit data? Where deleting it would be forbidden. Should I just return a InvalidOperationException when I try to call Delete()?

Some people have suggested smaller interfaces like IReadable, IWriteable, IUpdateable or IDeleteable. I think this approach is even messier.

Personally (and this is just my own solution after giving everything else a good run around the block), for DDD, I prefer to use an interface per repository (mostly for IoC and unit testing). This gives me IUserRepository, IAuditLogRepository, etc. My repositories also take (as parameters) and return domain entities (aggregate roots or just single entities). This way there is no anaemic DTO objects to maintain or clutter my solution. However I still use view-models to keep sensitive data out of my views.

There's lots of arguments online for and against the repository pattern.

like image 109
Adrian Thompson Phillips Avatar answered Oct 14 '22 08:10

Adrian Thompson Phillips


The repository pattern is not an anti-pattern per se, but I have seen far to many implementations of DDD where the repository pattern provided little or no value. Hand your n-tier-provide-no-value layered architecture to a pragmatic hardcore expert dev and he will probably give you the "anti-pattern" critique (and valid I might say).

Repository pattern pros:

  1. An abstraction of the underlying persistence technology
  2. A possibility to define your aggregate roots, only aggregate roots should have repositories
  3. A way of explicitly stating which operations are valid for the aggregate root in question, for example if its not valid to delete your entity, your repository should have no delete method.
  4. Something that is easy to test without a database (stubbing your repositories)

Repository pattern cons:

  1. Closeness to your persistence technology.
  2. Yet-another tier

Personally I prefer using the repository pattern when doing DDD, but your solution sounds more like the active record pattern, thus removing most of the benefits of using repositories in the first place. I never do generic repositories because they remove pros 2 & 3 (I can have a generic implementation, but I don't expose it directly to repository-consumer code).

And also: don't use repositories for population of DTOs, ViewModels, etc. Use separate models and technology for modelling writes (DDD can work great) and reads.

like image 31
Marius Avatar answered Oct 14 '22 08:10

Marius