Recommendation for persistent layer?

[C Bulow]

Hi there,

I'm working on bringing an old Java desktop application a bit up to date and I'm planning on basing it on Spring Boot. The application is very light weight on installation, so no database or anything other than a jar, plus data files. Currently it saves and loads data to an XML file on the file system, which makes it very easy to move the application and data to a different computer. Internal references to different objects is currently a bit cumbersome like fetching a subset based on certain criteria and such, mostly because the model is a bit of a hierarchy and it fetches though references from the top.

Now, I'd like some help on choosing the best way to do this using the Spring framework to refactor and make my work easier. I thought about using an in-memory database to use Spring JPA to fetch subset data but it seems like a bit of an overhead when I don't really need the database. Do you have other options?


I'd also like a tip on the easiest way to save my internal model to a flat file (doesn't have to be XML, just human readable).

Thank you in advance.

[Stephan van Hulst]

I can't really comment on how to migrate your project to Spring, because I don't know what it looks like and I don't understand your explanation of the cumbersome parts.

Regardless, the easiest way I've ever dealt with persistence in mature applications is through the use of the repository pattern. Your model should only know about other model classes, and should never have to work with databases, files, or pretty much anything that's not part of your business layer. When you want to save or transmit or do anything else that involves serializing your model, you let an external controller class (like a REST controller in web applications, or an event handler in desktop applications) pass that part of your model to a repository that knows how to flatten the model. You can do this regardless of whether you want the model to serialize to XML, a database or an internet connection. The repository is responsible for the conversion.

For a repository that reads and writes to XML, you can use the JAX-B API to easily flatten your classes as beans. Some people use the annotations directly in their model, but in my experience this invariably leads to headache and bugs. Don't be afraid to create beans that seem like they're copies of your model. It may look like code duplication, but they serve a different purpose and it will help you to isolate your model from any specific kind of data representation.

Try to avoid the Active Record pattern. It works great for small applications, but as applications mature, Active Record becomes a hell and only gains more circles.

[C Bulow]

Oh, I intended to include an example but got distracted and forgot when I returned. Sorry for my absentmindedness and thank you for taking the time to reply anyway.

I didn't know about the Active Record pattern but I can see that's pretty much what I intended with the in-memory database. I'm not sure what will be best practice for my project then. The model is actually pretty much separated from everything else in that a separate layer reads the model and creates the XML (creating nodes manually atm.) and controllers and the UI fetch the model to get the data they need (though I'm thinking using DTO's for the UI might be better to separate the UI more from the model).

Anyway, back to that example I was mentioning: The application is a game management system (not an actual game), keeping track of players' position on a map, teams and the income they have and so on. At the top is a campaign object that keeps a separate list of players, teams, territories, etc. A team object has a list of players belonging to the team and a player knows to which team it belongs and its position on the map.

A scheduled task might need to find which players are in a specific position. It has a reference to the campaign, gets a list of players from the campaign, and loops through every player and get those that matches the relevant position. For comparison with JPA this could be done with something like: List<Player> playerList = findByPosition(x).

Another example is to find which enemy teams are present in a position of a given player. Teams can be allied, so it involves first fetching the players present, then checking whether their team is an ally of the given player and making a list of the result. I'm using the model every time but it feels like there should be a better way of solving this.