Timeline for Injecting DAO dependencies into Service Class in Core Java
Current License: CC BY-SA 4.0
15 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 1, 2019 at 22:01 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Apr 1, 2019 at 21:48 | answer | added | candied_orange | timeline score: 1 | |
Apr 1, 2019 at 19:09 | comment | added | Laiv | If you can replace/change the DAO instance without having to change the service (any time), yes. Note that the DI is highly recommended to make the solution more testable. The more testable the better. Solutions should be first testable and then everything else (IMO). | |
Apr 1, 2019 at 19:02 | comment | added | Yug Singh | Got your point. In my project even though the DAO's are singleton and they are declared as static, final but since we need the db instance to be up and running to be able to test the classes having accessors to dao, our classes are tightly coupled to DAO. I assume this is meant by last statement in your last comment.So if we remove this dependency on Db instance then can we say that our class is now loosely coupled to the DAO? | |
Apr 1, 2019 at 18:55 | comment | added | Laiv | Testing is a good hint. A very important one. It should be possible for you to replace the DAO any time. Singletons and constants don't get along with that. Ideally, yes getting injected the dependencies make a big deal. Are you familiar with Dependency inversion and dependency injection? | |
Apr 1, 2019 at 18:53 | comment | added | Yug Singh | @Laiv from your comment regarding #1 I understood that for something to be called loosely coupled, we must be able to test it independently.For this in our class we should be injecting the dependencies so that we can use mocking tools s.a Mockito to mock them and thus making testing independent of dependencies. Pls correct me if I am wrong. | |
Apr 1, 2019 at 18:51 | comment | added | Laiv | Sorry to say but #2 demands injection, making the Handler aware of the DAO. Unless you inject the service into the handler or you expose the service to a 3rd component, from the Handler itself. | |
Apr 1, 2019 at 18:47 | comment | added | Yug Singh |
@Laiv our services are stateless. They only implement functions. This is done to avoid multithreading related issues. So we can directly access our services using ServiceName.methodName() .
|
|
Apr 1, 2019 at 18:46 | comment | added | Yug Singh | @Laiv thanks for the comment regarding #1. Actually we need our db instance to be running to test the #1 i.e. our service classes. | |
Apr 1, 2019 at 18:35 | review | Close votes | |||
Apr 16, 2019 at 3:10 | |||||
Apr 1, 2019 at 18:23 | comment | added | Laiv | How do you instanciate Services in #2? | |
Apr 1, 2019 at 18:19 | comment | added | Laiv |
How do you test #1? In other words, what do you for testing services without real DB access? If you can't, then Yes, you are tightly coupled to TestAcceessor.Instance
|
|
Apr 1, 2019 at 15:39 | history | edited | Yug Singh | CC BY-SA 4.0 |
edited text
|
Apr 1, 2019 at 15:30 | history | edited | Yug Singh |
edited tags
|
|
Apr 1, 2019 at 15:18 | history | asked | Yug Singh | CC BY-SA 4.0 |