I just started my assignment (URLyBird 1.1.1) a few days ago. I think I will use the following approach:
Design:
=======
* Use a 3 layer architecture (GUI, business, DAO)
* Use a thin client
* Use no transfer / value objects at all in the suncertify.db package
Data class:
===========
* Mark all methods as synchronized and make it a Singleton
* Implement an extended interface
* Use a worker class for managing data (the record map) + use record cache
* Use a separate class that facilitates the locked records
* Identify clients by their thread id
Networking:
===========
* Use sockets...yeah really ;-)
GUI:
====
* I will keep it simple...no fancy stuff, as it doesn't give any extra credits
So for now, I have some small questions / doubts:
1. The instructions say that I should implement the used Exceptions in the provided interface (in the suncertify.db package). A zero and one argument constructor should be provided.
Well that's ok, but I want my exceptions to extend from a general DatabaseException, so that I can wrap all kinds of exceptions in this DatabaseException and throw it to the business layer. I think it's just legal that these exceptions (like RecordNotFoundException) extend from a base exception class (DatabaseException). Right?
2. Do I need some kind of synchronization / locking for the reading / writing to the provided database file? I will use a record cache, so at startup I will read the whole database and put the records in a Map. If the application terminates a shutdown hook will write the record cache back to disk. Only one thread will do this, so what precautions should I take?
3. What about the validation of the database file at startup? There are no must requirements specified about this, but I've read that almost everybody checks if the magic cookie value matches the value that is expected. That's cool, but it's a rather simple check and does not confirm that the records themselves are ok...
I guess the best thing to do is quit the application when the database is corrupt (also providing an message to the CSR)? The application doesn't work without a correct database.
4. What about the deleted property of a record? Use it in the Room transfer object? It's also in the record itself and makes it easier to write back the data to the file at application termination. On the other hand...it's a kind of flag indicating if a record is marked as deleted, so I don't see it as a 'normal' property...
Cheers,
Dennis