The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S - Database layer potential design 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 - Database layer potential design" Watch "B&S - Database layer potential design" New topic

B&S - Database layer potential design

Alex Sharkoff
Ranch Hand

Joined: Apr 11, 2004
Posts: 209
Hi all,

I'd greatly appreciate your thoughts on the following proposal for the B&S project's database layer.

Specified in the SUN's assignment, DBMain interface and Data class, which implements this interface and reads / writes to the database file, can be thought of as the actual data source implementation (similar to RDBMS: MySQL, etc). If we closely look at the methods in the DBMain interface then we can see that they are very generic, ie they have no references to contractors (eg, String[] read(int recNo) throws RecordNotFoundException ). Therefore, we can assume that DBMain can be used for accessing information not only from Contractor's table but from other tables as well (should they be added to the database file, eg, Customer table). That's why each instance of the Data class is associated with the specific table (tableName is passed as a parameter into the constructor), for which it performs read/write operations. Data class knows how to locate meta information on the table (in fact it will use schema description section in the database file)

In order to access and modify Contractor related data in any data source we create data access object: ContractorDAO interface. This interface defines methods such as:

create(Contractor contractor) throws DuplicateKeyExceptionContractor get(int contractorID) throws RecordNotFoundExceptionupdate(Contractor contractor) throws RecordNotFoundException
lock(Contractor contractor) throws RecordNotFoundException
unlock(Contractor contractor) throws RecordNotFoundException

Our project will contain just one concrete implementation of ContractorDAO interface: FileContractorDAO which in fact provides the means to access Contractor related data in our data source implementation (via Data class)

FileContractorDAO creates an instance of Data class with the Data.CONTRACTOR_TABLE.

Also we'll have a business delegate that will have a local and remote interfaces (too much ejbs in my head ): ContractorBO. This delegate will talk to FileContractorDAO when it needs to access contractor's related data. Business object will perform tasks such as validating user input, booking contractor record, performing searches, etc. The GUI side will always talk to the database layer via ContractorBO.

I think that this design proposal neatly fits into the DataAccessObject design pattern.

Thanks a lot in advance for your comments.

[ August 23, 2005: Message edited by: Alex Sharkoff ]
[ August 23, 2005: Message edited by: Alex Sharkoff ]

Alex (SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCJD 1.4)
Thomas Paul Bigbee
Ranch Hand

Joined: Jun 28, 2005
Posts: 71

I think its a great approach (for a production environment), however, since there is only 40 points being awarded for the Data Class, and...

A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient.

I agree that the data access methods are very generic, I just looked at my implementation, and, there is nothing specific to a Table or Column Name anywhere to be found.

I would just question, as to why another layer is being proposed (even though its a better design) when one hasn't specifically been called for.

Anyway, those are just some of my thoughts.

Alex Sharkoff
Ranch Hand

Joined: Apr 11, 2004
Posts: 209
Thanks a lot, Tom, for your reply.

OK, so you've voted for this design to be overly far the vote tally is 1-1

Does anyone else would like to vote on this design proposal?

Remco Bos

Joined: Feb 14, 2005
Posts: 3
I was also thinking about using a similar design. It looks very elegant. But now I look at the remote/local database part of the assignment: I wonder if I should implement the DB interface on the local and remote stub, or create a DAO interface and let the remote/local stub implement that interface.Any ideas?
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11776

Hi Remco,

Hmmm, your name sounds familiar. Did you used to work for Stratus in Maarssen, Holland?

A similar question to the one you raise is "Should lock methods be callable by the client" (be prepared for a long read thought ). It certainly appears that Sun do not have a preference one way or the other.

I wonder if I should implement the DB interface on the local and remote stub
Your DB interface probably does not allow you to throw the needed exceptions for you to use it as your remote interface so you are almost certainly going to have to wrap it - don't know if that makes a difference to your decision or not.

Regards, Andrew

The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Alex Sharkoff
Ranch Hand

Joined: Apr 11, 2004
Posts: 209
Thanks, Remco and Andrew , for your thoughts.

So the vote tally for the proposed design is 2-1 (in favour of such design).

Andrew, you've got the crucial vote - it'll be a clear win or a respected draw

I agree. Here's the link:
subject: B&S - Database layer potential design
It's not a secret anymore!