Calling one DAO from another DAOFactory

Question

Currently, the architecture of my application is as follows:

View → Host → Some asynchronous executor → DAOFactory → DAO (interface) → DAO (Impl)

Such an architecture is currently operating; mainly because at the moment I need only one kind of DAO. But as this requirement grows, I need to expand to several DAOs, each of which has its own implementation on how to obtain data.

Here is an illustration of my case:

The main headache comes from FooCloudDao , which loads data from the API. This API requires a kind of authentication method - a string character that was saved during login (say, a Session object - yes, this one also has its own DAO).

It's mysteriously simple to pass an instance of Session through FooDaoFactory , just in case there is no connection, but it seems hacky and counter-intuitive. The next thing I could imagine was to access the SessionDAOFactory from FooDaoFactory to get an instance of Session (and then pass this when I need an instance of FooCloudDao ).

But, as I said, I'm not sure if I can do something like this - well, maybe I could, but is this really the right way to do this?

Answer 1

I assume that your problem is that FooCloudDao has different “dependencies” than other components, and you want to avoid passing dependencies through each class on the way.

Although there are quite a few design patterns that could solve your problem, I would suggest looking at the principles of Injection / Inversion of Control . What would you do with this:

• You would create an interface for your FooCloudDao , for example:

 interface ApiTokenProvider { string GetToken(); } 

2. You would create an implementation of this interface that could get it from a session or from anywhere:

 class SessionBasedApiTokenPrivider implements ApiTokenProvider { public string GetToken() { // get it from the session here } } 

3. The ApiTokenProvider class above should be registered in the IoC container of your choice as the implementation of the ApiTokenProvider interface (so that anyone who requests the ApiTokenProvider will be disconnected from the actual implementation → the container would provide it with the correct implementation).

4. You have something called constructor injection in the FooCloudDao class (this is later used by the container for “injection”) your dependency):

 public FooCloudDao(ApiTokenProvider tokenProvider) { // store the provider so that the class can use it later where needed } 

5. Your FooDaoFactory will use the IoC container to resolve FooCloudDao with all its dependencies (so you will not instantiate FooCloudDao with new )

---

When performing these steps, you will ensure that:

• FooDaoFactory stays clean from passing dependencies through
• you will make your code more reliable because you can test your FooCloudDao without a real session (you could only give a fake interface implementation).
• and all other benefits associated with inversion of control ...

Note about the session: if you encounter the problem of getting the session in SessionBasedApiTokenProvider , most of the time the session itself is also registered by the IoC controller and entered where necessary.