• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S - Database layer potential design

 
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Alex

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.

Tom
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot, Tom, for your reply.

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

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

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic