Data access layer of Bodgitt and Scraper
Hanna Habashy
Ranch Hand
Posts: 532
posted 13 years ago
hi:
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 ]
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
Greenhorn
Posts: 12
posted 13 years ago
Hi Hanna,
I did exactly the same as you:
[LIST]
[*]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.
I did exactly the same as you:
[LIST]
[*]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.
posted 13 years ago
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
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
| It is sorta covered in the JavaRanch Style Guide. |