Win a copy of Android Programming: The Big Nerd Ranch Guide this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Data access layer of Bodgitt and Scraper  RSS feed

Hanna Habashy
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
Martin Rea
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12105
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!