Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S - Data access class (Data.java)

 
Richard Levy
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

in my assignment it says "your data access class must be called Data.java, must be in a package called suncertify.db and must implement the following interface" <standard DB interface>.

I've taken this to mean that this class must be used to do access to the database from the remote client or the local/server side. So, my Data.java is an ellaborate facade (with factories and adapters etc) that either establishes a remote connection to a serverside database, or creates an object to read the database locally. So as far as data access goes, my Data.java is the highest level data access point and everything happens in it.

Has anyone else interpreted it like this, or do most people use Data.java for the direct file access to the DB then build on top of that?

Honestly, you'd think Sun were out to confuse people the way they write their assignments!

Thanks for your help,
Rich
[ September 06, 2006: Message edited by: Richard Levy ]
 
Liviu Carausu
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I use Data.java for the direct file access to the DB. The other things (like remote database implementation )are built on top of this.

This was my first design decision, maybe I will think again about it if I find some good reasons.

I hope it helps,

Liviu
 
Jeremy Botha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Richard.

I've taken the same approach as Livui. Data.java is my file access class, which I then call via a Persistence Manager object to allow a decoupling point between data access logic and physical data access.

J
 
Daniel Dalton
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Richard,

I chose to separate out the locking into a separate lock manager, and the file I/O stuff into its own class because I felt that it was warranted and produced more cohesive classes. My Data class was then a facade over the top of these.

I also chose to present a different interface to the client program, which allowed the client to not have to care about whether it was dealing with a local or remote database.

At the end of the day, you have to be able to justify what YOU choose to do. As long as you meet the requirements in YOUR instructions, and can justify what you've done, you should be fine.
 
Anna Hays
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I did it the same ways as these guys too.

I think Sun has many reason to do things a certain way. And one of them could be, of course, to confuse you.

The beauty of this is you get to design your own implementation and learn something.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic