3 ms·
This is exactly an argument I am having at work right now, from someone that hates dependency injection. If I have a controller that calls a service, and a ser
by tunesmith 13y ago
This is exactly an argument I am having at work right now, from someone that hates dependency injection.
If I have a controller that calls a service, and a service that calls a dao, then the service needs the dao injected:
public Service(Dao dao) {
this.dao = dao
}
Which means (in the absence of autowiring) that the controller needs to be "aware" of the dao:
...
service = new Service(new Dao());
result = service.serviceMethod(param1, param2);
...
And that is objectionable because of putting too much of a burden on people writing controller logic, because of separation of concerns, etc. I am finding it difficult to argue against that point.
I get that this goes away if using a proper inversion of control container so one can autowire, but that is not always practical.
- dragonwriter 13y ago> And that is objectionable because of putting too much of a burden on people writing controller logic, because of separation of concerns, etc. No, the controller needs to be aware of a method of creating new services. Depending on the specific language and other constraints, that might be a factory function passed into the controller's constructor, a factory object passed into the controller's constructor, a refernce to a service locator object, or some other mechanism. Specific direct knowledge of the DAO class is generally neither necessary nor desirable.
- revscat 13y agoHow is that a burden? The controller has to know about the methods of the DAO no matter what. The debate you're having seems to be "what is the best way to get a concrete instance of the DAO into the controller?" The argument being made for constructor/accessor injection is that it makes testing easier. The argument against it is that it makes the API more complicated than it would otherwise be.