• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S:concerned about overdoing DB implementations!

 
Richard Levy
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I got my SCJD assignment a while ago, but work commitments mean that I can only now pick up from where I left off.

Previously I'd started with the database implementation. In my assignment (I assume its the same in all) I've been given an interface specifying the database methods and have been told that the data access class "must be called Data.java". This implies a concrete implementation of the interface that "must" be used for data access.

My concern about over-design stems from this insistance on a single class for data access. As we have an interface, I would usually write multiple classes that implement it and serve up an implementation from a factory. In this instance, for both the local and remote databases, I must serve up a single class.

I'll try and explain my design simply and without giving too much away:

* Data.java implements specified database interface

* I created another interface (DB2.java) the same as the database interface but all the methods declare remote exceptions too so it can be used by a local or remote implementation

* On creation, Data.java calls a database factory to get an instance of a database dependant on the mode. (factory is abstract and the factory instance returned, determined by mode, serves up the appropriate local or remote DB). The returned database instance implements the DB2 interface and is stored in a private member variable in the Data class.

* Each method in Data.java simply delegates to the DB2 instance (having the same methods). The exception handling in Data.java covers local and remote databases.

So, I've got facades, factories, abstract factories, singletons etc all in there and it seems like a lot, but its only because of this insistance on the Data.java class.

Have I missed some point? I've spoken about this to a well respected architect in the Java community and he said that he'd done something similar.

I hope I havent given too much away, but I couldnt give any less away.

Thanks
Rich!
 
Daniel Bryant
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Richard,

Your design sounds similar to mine, with just a few minor details changed:

Data.java is a fascade which contains (and delegate appropriately) a FileAccess and LockManager reference (both Singletons).

For the remote connection to the DB I have an adapter on the client-side that adapts my Remote Interface to the DBAccess interface and handles the RemoteExceptions appropiate (throwing an GUIException, that is caught elsewhere). I don't instantiate the appropriate class (direct or adapter) to connect to the DB using a factory, but I guess I could.

I hope this helps.

Daniel
 
Richard Levy
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

thanks for the reply. Its nice to know that I'm on the right track (or we're both way off the mark ;-) ).

Thanks
Rich
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Data.java is a fascade which contains (and delegate appropriately) a FileAccess and LockManager reference (both Singletons).

Have you thought in a DAO?
Why to couple your data implementation to a single persistence implementation?

Regards
 
Daniel Bryant
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Oricio,

An interesting thought - the reason I have used a FileAccess class is that if our "customer" changed to using a RDBMS they would have to alter both the physical access and locking (which would most likely be provided by the RDBMS) which would mean a complete redesign of the class implementing the DBaccess interface anyway.

I'm not sure of this, but do you not think using DAO would be overkill for this project? Would it be ok for a junior programmer to understand?

Best wishes,

Daniel
 
Oricio Ocle
Ranch Hand
Posts: 284
Debian Firefox Browser Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if our "customer" changed to using a RDBMS they would have to alter both the physical access and locking

Are you sure?
Our locking methods ensure logical consistency of data and transactional behaviour even client side.
CRUD operations behind a DAO could be upgraded without change locking implementation, ensuring backwards compatibility.

I'm not sure of this, but do you not think using DAO would be overkill for this project? Would it be ok for a junior programmer to understand?

as a general issue, a bridge pattern could be aesily understood, that is: hide implementation whenever it's possible.

I have a question for you:
why are you using singletons?

Regards
 
Daniel Bryant
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Oricio,

Thanks for the feedback.

Our locking methods ensure logical consistency of data and transactional behaviour even client side.
CRUD operations behind a DAO could be upgraded without change locking implementation, ensuring backwards compatibility.


This is a good point - I was thinking a RDMS would handle all the transactions etc, but I see what you mean (I'll have to give this some more thought... ). Just out of curiosity do you use a transfer object on your server-side implementation of the DAO pattern (for example returning a Room object to the client instead of an array of Strings)?

I have a question for you:
why are you using singletons?


My thoughts behind this decision is that if someone was to alter my design in the future and instead of instantiating just one Data object (which I do now), needed to instantiate multiple copies of this object (for example, each thread needed it's own copy of the Data class) then the Singleton pattern ensures there would only ever be one FileManager or LockManager object, and therefore there would be no potential for such situations as two FileManagers (in the same JVM) both updating the same record.

However, I am keen to hear if you have any thoughts or criticisms on this design.


Best wishes,

Daniel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic