First point There's a lot of posts about "putting the business logic server side" or "just exposing database on the server".
I agree with most of arguments for both cases, even if I already had a little preference for the first one.
But with my assignement (B&S 2.3.3), I think I've found one major argument for the first solution (putting business logic server-side). Because my DB methods does'nt use a cookie for locking purposes, the only way I've found for remembering which client holds a lock on a record is to store the caller Thread. (Considering that I don't want a Data instance for each client for some reasons.) Considering also that I will use RMI for networking, putting only the database on the server will cause problems.
Am I wrong or do I have forgotten something ?
Second point It concerns the non-networked mode : in this mode, I think the client has not to deal with RemoteExceptions... So in my interface which defines business methods (we'll name it "Service"), the methods does'nt throw RemoteException but something like ServiceException. But exposing such methods server sides using RMI implies that methods declaration throws RemoteException. (This thread discusses this point in detail.) So today, my design looks like that :
Service interface defines business methods.
ServiceImpl is the major implementation (deals with database)
RemoteService extends Remote, redefine Service methods with throws RemoteException clauses
RemoteServiceImpl is the object bounded in RMIRegistry, and delegates calls to a Service instance
RemoteServiceWrapper delegates calls to a RemoteService instance.
I've also a Factory for creating Service instances : ServiceImpl in case of non-networked mode, RemoteServiceWrapper otherwise.
My problem is that I introduce 5 classes/interfaces with the same methods signatures and some complexity for the junior programmer...
I know we have to keep the solution simple, but I don't like the idea to put only "I have do this like that because it's the most easy/simple and requires less efforts" in my choice.txt !!
Because my DB methods does'nt use a cookie for locking purposes, the only way I've found for remembering which client holds a lock on a record is to store the caller Thread. (Considering that I don't want a Data instance for each client for some reasons.)
If you had not made your decision not to have a Data class instance for each client then you wouldn't be reliant on the thread . Sort of catch-22 there.
Another alternative is for you to add your own cookies to the remote methods, and map them to the thread numbers used internally by the Data class.
Regarding your second issue - making a solution "simple" is not just about reducing number of classes - in fact it can be just the opposite. Adding classes may make the overall solution easier to work with / understand / enhance / debug. So I would not worry about adding classes.
Catch-22 is a term coined by Joseph Heller in his book of the same name, often used to refer to a situation where circular logic is being employed (especially if it forces a situation that is undesirable (from a certain perspective)).