B&S: Hiding DBMain implementor

[Musab Al-Rawi]

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.

[Jar Jaquiso]

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

[Musab Al-Rawi]

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

[Musab Al-Rawi]

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).

[Jar Jaquiso]

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:

if (!lock.isHeldByCurrentThread())
{
    throw new DBRuntimeException(new DBException("Record lock not owned by this object."));
}

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 ]

[Musab Al-Rawi]

Thank you very much you have been truly helpful.
things are much clearer now.