CODEWITHSUNDEEP
javamysqldatabaseoop
Kyle Walker
Kyle Walker

Reputation: 579

Converting database data into objects

I'm building my first real Java application, and I'm confused about following good object-oriented design practices.

My application allows a yoga instructor to design a yoga session. There is a MySQL database with five tables:

The sessions are composed of sections, and the sections are composed of poses. I purposefully chose to use a database in this design rather than lists or arrays for the purpose of learning how to integrate a database with Java.

Here is my question: Is it really necessary to make objects out of the poses, sections and sessions?
They are merely data, and they don't have behavior of any kind. The real objects in my application are the windows and tools the user is using to assemble these poses and sections into yoga sessions. It just seems that my code will become unnecessarily inflated and complicated if I force each pose and section and session to be an object. I realize that I may be asking for opinions here, and that is generally discouraged on this forum. But my intent is to understand and follow object-oriented design in what seems to me to be a murky area.

Upvotes: 2

Views: 2861

Answers (3)

user22877227
user22877227

Reputation:

  1. If you use Hibernate or other ORM, you must use POJOs. There's no other way.

  2. If you use JDBC directly, for example Spring JDBC, you could use maps (SimpleJdbcTemplate returns maps in many functions etc.), but reading POJO field is much quicker and less error-prone than reading field from map. Maps take also more place in memory.

  3. If you are using JSF, you need POJOs with getters and setters, maps could theoretically be used for read-only, but the syntax is going obscure.

Reassuming, there's no good alternative for POJOs in Java for storing datas. In some cases you can use maps, but it's good only when the data structures are dynamic or as temporary solution.

Upvotes: 0

sanbhat
sanbhat

Reputation: 17622

To answer your question, Yes, create objects for each. The main principle of Object oriented programming is having different "types" of Objects and doing stuffs (Behaviors - methods) around them.

I suggest you to look at the concept of ORM. ORM is the process of mapping Objects to their persistent representation, i.e Database tables.

If you go for plain JDBC, you may need to write a lot of native SQLs and code to extract individual column's values from your table. When the complexity of your schema increases, it will get difficult to maintain these queries.

With ORM, you can write simple java programs to get and save data from persistent layers.

You can go through this thread to look at the ORM advantages

Hibernate is a great framework available for Java which does ORM

Upvotes: 3

Cjxcz Odjcayrwl
Cjxcz Odjcayrwl

Reputation: 22847

1) If you use Hibernate or other ORM, you must use POJOs. There's no other way.

2) If you use JDBC directly, for example Spring JDBC, you could use maps (SimpleJdbcTemplate returns maps in many functions etc.), but reading POJO field is much quicker and less error-prone than reading field from map. Maps take also more place in memory.

3) If you are using JSF, you need POJOs with getters and setters, maps could theoretically be used for read-only, but the syntax is going obscure.

Reassuming, there's no good alternative for POJOs in Java for storing datas. In some cases you can use maps, but it's good only when the data structures are dynamic or as temporary solution.

Upvotes: 2

Related Questions