DanielH (6) [Avatar] Offline
#1
In Chapter 2 the HomeController has a dependency on ProductRepository, because the ProductService needs it as a constructor parameter.

Why isn't the ProductService injected into the HomeController instead?
As I see it, this code contradicts the understanding to not accept dependencies in a constructor only to pass them on to another constructor. Instead, either accept the constructed object in the first place, or, if you really need control over the lifetime, accept a factory.
I see no benefit in newing up that ProductService inside the HomeControllers Index method, especially, as the BasketController HAS a dependency on the service it needs and not on the constructor parameters of that service.
mark.seemann (383) [Avatar] Offline
#2
Re: Chapter 2 - Dependency because it needs to be passed on
I agree with everything you wrote :/

It's one of those instances where the example evolved and where the end result probably should have been different.

What I wanted to do with the example in the book was to highlight first and foremost how it's possible to decouple the HomeController from the ProductRepository to contrast it with the tightly coupled example which came earlier. That focus then caused me to pass the ProductRepository on to the ProductService.

Even if the cause of the bad design was done in the name of showcasing that particular decoupling I agree that this isn't the best example you'll find in the book. It has exactly the problems you point out, and if I could do it differently today, I would.
DanielH (6) [Avatar] Offline
#3
Re: Chapter 2 - Dependency because it needs to be passed on
Thanks for your fast answer.

I am a bit puzzled - can't you just change it? As far as I know, the book is not yet released, is it?
mark.seemann (383) [Avatar] Offline
#4
Re: Chapter 2 - Dependency because it needs to be passed on
It's very close - it's being typeset at the moment, so I can't change the contents any longer.

In any case it's not a small change, because if I change HomeController to require the service instead of the repository, the example loses the connection/contrast to the tightly coupled example. Ideally, a fix would involve changing both the tightly coupled example as well as the loosely coupled example, so I can't 'just' change it.
DanielH (6) [Avatar] Offline
#5
Re: Chapter 2 - Dependency because it needs to be passed on
Yes, you are right, it's not as simple, as I made it sound. smilie

So, posting any typos I find is no longer needed?
mark.seemann (383) [Avatar] Offline
#6
Re: Chapter 2 - Dependency because it needs to be passed on
That's right. As part of the production process professional proof readers have gone through the entire text, so let's hope most of the spelling/grammatical errors have been weeded out by now smilie
chorse (16) [Avatar] Offline
#7
Re: Chapter 2 - Dependency because it needs to be passed on
Daniel & Mark,

Thanks for clearing this up, because I wondering exactly the same thing. After reading through DI once and then going back, it struck me as weird or backward to inject repository. I understand that the book can't be changed, but perhaps there should be an separate downloadable errata that could include these types of changes.

It would be of help to us DI newbies who are also interested in how the code works.

Great book - It really gave me good understanding of DI and also helped with understanding abstractions in other patterns in general.
mark.seemann (383) [Avatar] Offline
#8
Re: Chapter 2 - Dependency because it needs to be passed on
Agreed that this might be worth pointing out. I'm sure there's going to be an errata page in the future (most books tend to get one of those). I've added a note to include this discussion in the errata. Thanks for suggesting that.
Steven van Deursen (11) [Avatar] Offline
#9
I'm pleased to announce that this anomaly will be fixed in the second edition. You can find the fix in chapter 3 of the second edition: https://manning.com/seemann2/