Forums Register Login

B&S: Hiding DBMain implementor

+Pie Number of slices to send: Send
one interesting design (based on what i understood from Jar Jaquiso post) is to hide the implementor of DBMain interface and limiting access to the whole DB layer through a Business Interface

Is this accomplished by simply giving it the default access to the DBMain implementor and having the Business interface inside the suncertfy.db package.
+Pie Number of slices to send: Send
Hello Musab,

In my design the DBMain implementor has default access as you said. In the suncertify.db package I also created a DBMainFactory class which is a singleton that has a public method that returns a DBMain object based on a parameter that is provided by it's clients.

My business interface is in the suncertify.business package and retrieves the DBMain object via the DBMainFactory class.

Jar
+Pie Number of slices to send: Send
Hi Jar,
I didn't think that I would get that lucky and have you personally answer my question , so thanks for the reply
since we are at it I have to say that you design is really interesting and BIG congratulations for the great grade that you got.
I think i will have more questions soon since my next step would be RMI.

thanks
+Pie Number of slices to send: Send
Jar,

I want to hide the locking methods by adding an adapter. If this adapter is in a different package (suncertify.business as you named it) then I am still not hiding the locking methods.

am I going to the extream with hiding the locking methods?
there is another way to handle locking record (without hiding locking methods) that requires MENTIONING the sequnce of doing things in the contract ( for example lock update unlock).
+Pie Number of slices to send: Send
Hello Musab,

I think there is no need to try to hide the lock/unlock methods on the database layer, after all they are part of the public DB interface.

It's the business's Adapter class who will be hiding this methods to the GUI.

About the sequence of doing things (lock-update-unlock) I didn't mention it in my DB interface Javadoc comments but I did force this use in my DB interface implementation class by validating in the update and the delete methods that the record to modify is effectively locked. If it isn't locked I throw an exception:


My DBException is wrapped in a DBRuntimeException as the DB interface does not provide a nice exception treatment. My business adapter can then recreate the original DBException from the enclosing DBRuntimeException.

Jar
[ August 30, 2007: Message edited by: Jar Jaquiso ]
+Pie Number of slices to send: Send
Thank you very much you have been truly helpful.
things are much clearer now.
Destiny's powerful hand has made the bed of my future. And this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 681 times.
Similar Threads
Field Names to the GUI Client
Q about interfaces: implicit conversion
URLyBird: Use of intermediate interface
NX:Contractor About RemoteException
URLyBird 1.3.2 : GUI Doubt
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 03:59:57.