CODEWITHSUNDEEP
javasqldatabasepostgresqldata-binding
M0rgenstern
M0rgenstern

Reputation: 411

Mapping database tables to Java classes - Dependencies

I am trying to represent database tables as Java objects. I do not want to use JPA or Hibernate. I use JDBC for the actual connection to the database.

Currently I have three tables:

Now my User class looks like this:

public class User {
    private Integer id;
    private String email;

    private Profile profile;
}

And my Profile class looks like this:

public class Profile {
    private Integer id;

    private User owner;

    private Contact contact;

    private String picturePath;
    private String hobbys;
    private String job;
}

And finally the Contact class:

public class Contact {
    private Integer id;

    private User owner;

    private String firstName;
    private String middleName;
    private String lastName;
}

So I planned to write a Dao for each class, which provides different methods for database request, does the request and returns the object accordingly.
I thought it would be good to have a function in each Dao which retrieves a complete object. This means, for the UserDao it returns a User where id and email is filled and the Profile object is also created from the corresponding values in the DB. So the Contact in this Profile object would also be filled from the corresponding Contact entry in the DB.

The problem I now have is how to organize this, because for the User I would have to ask the ProfileDao to create a Profile object, and in the ProfileDao I would need to ask the ContactDao for the corresponding Contact. The ContactDao usually would try to get the user as well, as it would be needed to create the Contact object completely.
So I would need to tell the Daos somehow to only retrieve the object itself and not the linked objects.
But this seems odd to me.

Would this really be the right way to go? Like calling the ContactDao with an additional parameter which tells the Dao to only get a flat representation.
Or should I link the user to the contact only via the user's id and provide a function to retrieve the corresponding user when he is needed?

What would be the correct way to solve this problem?

EDIT It seems to me, I may have left an important information out (because I did not know it could be important). Actually the answer of @Oleg gave me that insight.
What I am actually doing is: I build a SOAP webservice which should handle all the connections to the database but also (obviously) also the whole internal logic. On top of that I would like to create a SOAP client which can be integrated in a webpage or an app.
My thought was I would need to give all possibilities to access the data in my database in any way I could imagine. But the answer by @Oleg seems to suggest something else:
If I am implementing a SOAP-API (his example was REST but at the end it does not really matter), I should only care about the things I NEED.
Say e.g. If I want to have a user, I just create a user object with an ID and the Email. If I want to have the profile of that user, I do another Request which gives me a flat profile object. And then I would also implement only those things in my API.
would that be the right way, taking these additional information into account?

Upvotes: 1

Views: 2395

Answers (2)

Robert Bain
Robert Bain

Reputation: 9576

"I honestly do not like it if there is so many stuff happening in the background which you cannot control" - JPA solves your problem, it's an industry wide, battle-proven API, with a couple of good implementations. EclipseLink is the reference implementation, Hibernate in my experience is more prolific and they both do what you need. It will also handle the transactional side of things for you. In response to your concern, I can't think of anything which you cannot control that you would need to.

I'm of the opinion, why maintain and test your own code to do things that every Java developer is doing, when there are libraries written by experts in the field that do it for free?

Upvotes: 1

Oleg Sklyar
Oleg Sklyar

Reputation: 10082

My advice would be to turn away from the EE-centric DAO concept to a domain-driven design. It is widely spread to define DAO interfaces (please, not classes if you go this route) being sort of Java-entity to DB-table mappings and then use a collection of such DAOs across different business flows. The flaw is that your business code becomes tightly coupled by DAOs and you have questions like the one you are asking as you want to provide a "generic" solution for something that has no generic use cases.

Instead, define another type of a data API, one that is driven by your business domain flow and only for that particular flow or business domain. Think of it as a high level API to the data that your business flow needs at different steps, so implement it with high-level inputs and high-level outputs rather that direct DB-mappings. Imagine you are defining a REST API instead, which sort of requests and responses you would provide for an external user to operate on the data, forbid any internal knowledge at that interface level.

Having done so you will

  1. decouple different areas of business logic;
  2. provide small testable APIs (interfaces) to cover each business flow
  3. will nevel loose the control over what-the-hell-are-all-these-DAO-functions-somebody-put-in-two-years-ago-and-where-are-they-used
  4. will be able to migrate to a different DB technology (where I do not mean from e.g. Oracle to MSSQL, but to e.g. a No-SQL solution if you decide you want one)
  5. will finally have a design that other people can comprehend

Upvotes: 1

Related Questions