Would like to run something quick by you guys to get your opinion, I am doing the B&S project & the interface required to implement 'db.java' uses string arrays for passing around records in CRUD operations, now my initial thinking is that I should not expose this interface as remote in my RMI implementation but expose a different interface one which deals with the Contractor DTO being passed around & at the server side I simple delegate the call to the db interface by calling the DTO object toStringArray method which deals exclusively with String as mentioned above.
Now with this interface I think it gives the system more freedom to change the backend to an RDBMS or whatever is the furture requirement as this interface can be reused as such & just delgate to a different DAO object.
So here is the crux of my post, that as SUN has already provided me with a required interface to implement should I just make this remote & not bother with the extra interface? i.e its another interface added to the system? & as such another layer maybe overkill? any thoughts on this much appreciated
You will NOT be able to expose the interface given by Oracle on the RMI-server, simply because each method you want to expose must throw a RemoteException and you can not change the given interface. So you'll definitely need a 2nd interface to expose on the server. And it's up to you to decide if you are exposing a business service (for thin client) or just a similar interface like the one you got but using dto-objects instead of String (for fat/thick client).
Ah thanks agian Roel, your wisdom has proved crucial once again!
Yeah the strategy I think I am going to take is a thin client with the remote interface exposing a minimal set of method, i.e no lock/unlock just the bear CRUD operations, I don' thin kthe client needs to get bogged down with locking & such, but I want this interface also not to be purely for the remote case but also for the standalone option so I will have to create a remote interface that implements this interface for he networking aspect of this project.
Ok quick question to you is of the 3 packages you had to implement for SCJD which one took most of your time & was the most challenging, I have the db package done which I am pretty satified with at this minute the remote side thanks to RMI seems to be not that bad, but the GUI with my lack of UI skills seems a bit daunting
If you go for the thin client approach your application just requires 2 methods, unless they have changed the instructions (which I doubt). You can easily create an interface which you can use for standalone and network mode. You could even use the same implementation for standalone and network mode (I didn't do that, because my network server code is slightly different to the code I use in standalone mode, due to the lack of a lockCookie in my given interface)
Rob Symth wrote:Ok quick question to you is of the 3 packages you had to implement for SCJD which one took most of your time & was the most challenging
I spent most of my time on the Data class, but that's because I also created a bunch of test cases to have 100% test coverage of this class, because it's the most important one of your assignment. The business layer was developed reasonably fast (also with full test coverage). The other big part was the GUI which I spent almost the same time as the Data class. But as you can see from the marking criteria of the assignment: gui is just 40 points (and very hard to have maximum score), data class + locking is 120 points. That's why I intended to quickly develop my GUI and submit, but my urge for flawlessness decided otherwise
ok i am making a design decision here that a CSR can book a record even if its already booked i.e the CSR has the power to override a currently booked record, whats you opinion on this? alternative would be to not allow but then how do you un-book a record, so as I am writing this my first assumption i think now is stronger that a CSR should be allowed to override a currently booked record
Rob Symth wrote:ok i am making a design decision here that a CSR can book a record even if its already booked i.e the CSR has the power to override a currently booked record, whats you opinion on this?
That's not about design, but about functional requirements and business logic. I don't like the idea of a CSR having the power to override an already booked record and I'm pretty sure you (as a customer) wouldn't like that either. Think about this scenario for example.
In this version there is no unbook functionality, but that might be added in the next release of the application (or you can add it yourself now if you feel more comfortable with having this functionality).