Business layer design

[David Coppens]

Hi all,

I am currently working on the URLyBird 1.2.3 assignment.
The database package is finished and I am currently starting work on the business layer.

The following design is what I am planning to implement and I would like your comments on this.

- I have an interface Operations that defines the operations that are applicable to my assignment, i.e. search records based on criteria and book a record
- Then there is a LocalOperations class that implements this interface. This class has an instance of the Data class that resides in the db package
- Also a NetworkOperations class exists that is accessible through RMI.
- There is a BusinessFactory class through which the GUI will be able to obtain an instance of an Operations-implementing class. It will provide a method with this signature: getBusinessOperations(String dbLocation, boolean local) and will return LocalOperations or NetworkOperations class based on the local boolean.

Any remarks/improvements on this design?

Thanks in advance!

[John Stone]

One of the problems I have and I'm having in my work is 'how to name the class/method' :-). I use to say, that good name is 50% of work, and I usually show my colleague (working on non-related part) my prototype and let him guess, what he thinks the class and methods are doing.

What I want to say, is that I don't like the name "Operations".

How do you plan to deal with exceptions? (your remote ifc will need to throw RemoteExceptions, what kind of exceptions will you gui catch?)

[Alex Belisle Turcot]

Hi,

some quick thoughts..

- Is your NetworkOperations reusing the LocalOperations ?

- Is it a BusinessFactory or ServiceLocator ?

- Would you use directly the "Network/Local-Operations" from your controller or rather from a BusinessDelegate ?

- Does your Data throw RuntimeExceptions? Do you throw those runtimeExceptions from your "Network/Local-Operations", or create new "Checked" Exception to throw instead ?

- Would you capture these exceptions in your businessDelegate or throw them to your controller, or throw them again to your view.. Basically, who will react accordingly to the exceptions ?

Regards,
Alex

[David Coppens]

Hi all,

The RemoteException got me thinking and eventually I think that I will have to take another approach.

I will now use a similar approach to that of Ken in his well-known description.

There will still be an Operations interface of which all operation throw IOException (therefore capturing the RemoteException problem).
Furthermore, to answer Alex' question; the Data class throws runtime exceptions that wrap the IOExceptions that can occur while processing the data file. These runtime exceptions will be caught in the business layer and wrapped in new IOExceptions thrown by the Operations interface. These exceptions will have to be handled by the GUI.

The remote approach will then just be another interface that extends the Operations interface and the Remote interface. The implementation of this interface will be delegating its work to the implementation of the Operations interface.