File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Data access layer of Bodgitt and Scraper 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 "Data access layer of Bodgitt and Scraper" Watch "Data access layer of Bodgitt and Scraper" New topic

Data access layer of Bodgitt and Scraper

Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
Reading about many data access layer design on the forum, making me rethink about my approch. I read that many people use caching technique to bring the database file into memory, then access it from there.
I followed different approch, which is very similar to accessing RDB using JDBC. I have little experience using IO and flat files. I don't know if it is the right approch or not, and your feedback is greatly appreciate.
here is how I do it:
First I don't bring anything to the memory, performance is not an issue for me at this point. Scalability and extensibility is more important.
In my data access class, every method that needs to access or modify the database, inside the method body, I open a stream to the database file, do all the business logic the method has to do, then close the stream.
It is the same way I do it accessing RDB.
I am not implementing any network support, or locking mechanism at this time. I am taking it one step at a time. So, if anyone think that my approch will be inappropriate implementing network support, or locking please warn me.
thank you
[ May 11, 2004: Message edited by: Hanna Habashy ]

SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Martin Rea

Joined: May 04, 2004
Posts: 12
Hi Hanna,
I did exactly the same as you:
[*]Instantiating Data class
[*]From constructor I read the DB scheme (magic cookie, length of fields, fields in record...)
[*]For each method (read, find, create...) I open a file stream , read what I need and close it
I have also implemented locking and I haven't ran into problems using this approach.
One could argument that the open / closing for every access is costly. But on the other hand requirement states we should not be concerned of performance. During my tests I have had fine respons time both searching, creating etc.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11777

Hi Martin & Hanna,
I think that your approach is justifiable.
I wouldn't even consider the effect of networking on the Data class. The Data class should stand alone regardless of what network protocol and / or server decisions you make later.
Locking is slightly different though - it is your interface which specifies how locking works, which may influence how the Data class works. This may then influence how you build your networking server, but note that it is locking/Data class that influences the networking - not networking influencing the Data / locking.
But even with that caveat, you still should not have a problem with developing your standard Data class data access methods before working on the locking methods. Once you do get to locking you will probably find you need little if any refactoring for the other methods.
Regards, Andrew

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
I agree. Here's the link:
subject: Data access layer of Bodgitt and Scraper
jQuery in Action, 3rd edition