How should object identification be managed?

Question

I have a java/swing application in (hopefully good) MVC structure. Here is a overview of my model classes:

One or more workers may work at one working location and one worker may work at different working locations (not at the same time, of course). A worker may have different types of a date assigned. The working location has a list of all its workers. Each date has a reference to its worker. All model objects are mutable.

For managing purposes I implemented a Database.java which is responsible for storing the model classes in java collection classes and at program close saving all objects into an xml file (I use java simple xml framework for this task). It has the following three lists: List<Working location>, List<Worker> and List<Date>. So the procedure is:

1. Load xml file on program start
2. Add/edit/remove model-objects to/in/from database (working with the collections of Database.java
3. Save all model-objects from the Database collections into the xml file on program exit

(If there is something bad in my mindset until now, please tell me a better way! I will really appreciate it.)

---

Here is the question:
What is the proper way of identifying model-objects?

I can think of two possibilities:

1. Use object references
   • (+) There is no extra code for handling the generation of new unique ids
   • (-) "Everyone" can edit the objects (Because this is a private project "Everyone" means only me)
2. Use unique IDs for every object
   • (-) more code
   • (+) database may return copies of the model objects to be edited and only when the controller calls the database's methods with the copyied model objects they will be updated

---

EDIT:

There was an important part which I forgot to mention: Multi-Threading and Multi-User
Both of them can certainly be answered with "No". The application will be some kind of one user planning software to replace the current "pen-and-paper-planning". I would say the main requirement is to avoid budgeting workers who are on holiday or not to forget to budget workers who come back from holiday the next day. Because this are the mistakes that often happen.

Also there is no need for deeper analysis of the model objects and therefore no need for complex database queries at the moment. Therefore I like the idea of using XML to create a standalone application. Or is there a good reason to blow up the code to fulfill unlikely requirements?

Answer 1

First, the recommendations:

Use a simple file-based in-proc DB such as H2 DB or SQLite. This is almost as convenient as an XML file - you can keep using the same workflow as you have today. It also future-proofs your software to an extent.

EDIT: If you feel that using a relational DB is overkill, I would still recommend using immutable model objects with a unique identifier. In this way, only your database class can update the actual persistent state. This keeps the process intentional and centralized. It eliminates accidental modifications of the data. This will also make it easier to migrate to another DB if required later.

Now, the "why":

Is your application multi-threaded or multi-user? Using reference-based identity can mess up the internals of a model object if two threads try to modify it at the same time.

EDIT: Do remember, multi-threading can also happen in a single-user application. Async tasks, timers, etc. all create threads and may access your database unsafely.

To avoid this, you can use Immutable objects with unique id parameters. This ensures consistency for that single object. However, different threads may still modify different objects and make them go out of sync. This destroys the integrity of the database. Also, an error or exception can leave operations half done, again causing errors in the DB.

These are of course, the standard reasons as to why an ACID database is essential. Transactions and locking are provided just for this purpose.

Also, as @Birfl mentioned, you will soon hit the point of having to run complex queries on your data. XPath can help to a point, but after that, you will have to write code to search for specific data sets. This might affect performance as well.