Is it considered bad design to pass a repository interface as an argument to a method on a domain class?

Question

Our domain model is very anemic right now. Our entities are mostly empty shells, almost purely designed for holding values and navigating to collections.

We are using EF 4.1 code-first ORM, and the design so far has been to shield our novice developers against the dreaded "LINQ to Entities cannot translate blablabla to a store expression" exception when querying against the context during early iterations.

We have various aggregate root repository interfaces over EF. However some blocks of code in the impls seems like they should be the domain's responsibility. As long as the repository interface is declared in the domain, and the impl is in the infrastructure (dependency injected), is it considered bad design to pass a repository interface as an argument to a method on an entity (or other domain) class?

For example, would this be bad?

public class EntityAbc {
    public void SaveTo(IEntityAbcRepository repos) {...}
    public void DeleteFrom(IEntityAbcRepository repos) {...}
}

What if a particular entity needed access to other aggregate root repositories? Would this be ok or not, and why?

public void Save() {
    var abcRepos = DependencyInjector.Current.GetService<IEntityAbcRepository>();
    var xyzRepos = DependencyInjector.Current.GetService<IEntityXyzRepository>();
    // work with repositories
}

Update 1

I did not mention moving code to an application layer because I consider some of the code that uses IEntityAbcRepository to involve business rule enforcement. The repository impl should be as vanilla as possible, right? Its main responsibility should just be a simple abstraction over the ORM, allowing you to find / add / update / delete entities. Wrong?

Also, this question applies to methods on other non-entity domain classes -- factories, services, whatever pattern may be appropriate. Point being, I'm asking the question about any method on a domain class, not just an entity class. @Eranga, this is one place where you can use constructor injection because factories & services are not part of the ORM.

The application layer could then coordinate flow by injecting a repository impl into its constructor, and passing it as an argument to a domain service or factory. Is this bad practice?

Update 2

Adding another clarification here. What if the domain only needs access to the IEntityAbcRepository in order to execute its Find() method(s)? In the example above, the SaveTo and DeleteFrom methods would not invoke any add / update / delete methods on the repository interface.

So far we've combined the find / add / update / delete methods on a single aggregate root repository interface for simplicity. But I suppose there's nothing stopping us from separating them out into 2 interfaces, like so:

1. IEntityAbcReadRepository <-- defines all find method signatures
2. IEntityAbcWriteRepository <-- defines all add / update / delete method sigs

In this case, would it be bad practice to pass IEntityAbcReadRepository as a parameter to a domain method?

Answer 1

Your first approach is better compared to the second approach which uses "Service Locator" pattern. Dependencies are more obvious in the first approach.

Here are some links that explains why "Service Locator" is a bad choice

• Is it bad to use servicelocation instead of constructor injection ...
• Singleton Vs ServiceLocator
• Say no to ServiceLocator

Both of these solutions stem from the fact that EF does not allow you to use constructor injection. However you can use property injection as explained in this answer. But that does not guarantee that mandatory dependencies are present.

So your first approach is the better solution.