wood burning stoves
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S - Data access class (Data.java) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S - Data access class (Data.java)" Watch "B&S - Data access class (Data.java)" New topic

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

Richard Levy

Joined: Jan 19, 2005
Posts: 22

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,
[ September 06, 2006: Message edited by: Richard Levy ]
Liviu Carausu
Ranch Hand

Joined: Oct 07, 2004
Posts: 159

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,


Oracle Certified Master Java SE6 Developer(SCJD),
OCE JEE 6 JSP and Servlets Developer.
Jeremy Botha
Ranch Hand

Joined: Feb 16, 2005
Posts: 125
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.


McFinnigan? Never heard of him. Nobody here but us chickens...<br /> <br />SCJP for Java 1.4<br />SCJD for Java 5.0
Daniel Dalton
Ranch Hand

Joined: Mar 20, 2005
Posts: 146
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

Joined: Nov 09, 2003
Posts: 131
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.
I agree. Here's the link: http://aspose.com/file-tools
subject: B&S - Data access class (Data.java)
It's not a secret anymore!