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.
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.
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.
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.
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.
Yes, a domain service can access repositories.
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.
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:
Repository pattern cons:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With