At what level should dependency injection be used? Controller or domain?

Question

Hi guys, I would like to hear from you what are the main advantages and disadvantages of using dependency injection at the controller level and / or domain level.

Let me explain; if I get IUserRepository as a parameter for my user , I can act in two ways:

1) I insert IUserRepository directly on my domain object, then I consume the user at the controller level without creating new objects, this means that I get them ready from the DI container.

2) I insert IUserRepository on my controller (say Register.aspx.cs), and there I add all my domain objects using dependencies that come from the DI container.

---

Yesterday, when I talked with my friend, he told me that if you get your domain objects from the container, you will lose your life cycle control, since the container manages it for you, he meant that it could be a prone error when Work with large xml configuration files. An opinion that is inconsistent with the fact that you can have tests going through each domain object in the assembly, and then it asks for the container, whether it is a singleton, request scope, session scope or application. He fails if either of them is right. A way to ensure that this kind of problem does not happen.

I was more likely to take the approach to domain (1), as I see big savings on repeating lines of code at the controller level (of course, there will be more lines in the XML file).

Another point that my friend raised is that, suppose for some reason you have to go from container A to B and say that B does not support constructor injection (which is the case for the seam container, Java, which manipulates BC or performs its task only with the installation of setter), but its point of view is that if I have all my code at the controller level, I can smoothly reorganize my code, since I get access to such tools like auto- refactoring and auto-completion , Which is not available when you are working with XML files.

I was stuck on this since I needed to make a decision right away.

What approach should my architecture use? Are there any other ways of thinking ???

Do you guys really think this is an urgent issue, should I worry about it?

Answer 1

If you want to avoid the anonymous domain model , you have to abandon the classic n-tier architecture of an n-level CRUDY application. Greg Young explains why this document is about DDDD . DI will not change that.

CQRS would be a better option, and DI fits very well into the small stand-alone components that this type of architecture tends to produce.

Answer 2

I'm not in the Java field, but according to your data, it seems in your questions that you are using some kind of MVC structure (since you are dealing with controllers and a domain). But I have an opinion on how to use DI in the Domain Driven architecture.

First, there are several DDD methods: some use MVC in the view and do not use the application service level between MVC and Domain. In other cases, MVP (or MVVM) is used and there is no service level. BUT I think that some people will agree to me that you very rarely enter repositories (or other services ...). I would recommend introducing repositories into Command (using MVC and not a single service level), Presenter (if you use MVP) or Application Services (if you use a service level). I mainly use the application layer, where each service gets the repositories that they need to enter in the constructor.

Secondly, I would not worry about switching between IoC containers. Most container frames today support ctor injection and can automatically resolve parameters. Now I know that you are a Java developer, and I am an MS developer, but the MS Practices team has a Common Service locator that can help you create code that is extremely independent of the container infrastructure you use. Maybe something similar in the Java community.

So, go to option 2. I hope I pushed you in the right direction.