The two biggest parts of a software design are the architecture and the object model. The architecture governs how pieces interact and communicate. The object model details the pieces themselves, the data buckets, the nouns we use as we talk about a business.
Tidepool’s object model currently has 19 entities (only 12 detailed below), each of which has its own database table and DAO (data access object). For example, “rule” entities can be accessed through the SbRuleStore DAO, which works with the SbRule table in the MySQL database.
Many programs access the database directly, which is perfectly fine, but it limits your options. By adding a DAO abstraction layer between your code and the database, you can simplify things over time or do wacky redirection stuff like I’m doing.
The Tidepool DAO connects to two different databases: the local Derby database and the remote server database. When you save data, it first saves it locally, then queues an update to the server. When you search data, it looks only at the local database, which is much faster. The beauty of a DAO is the rest of the code doesn’t need to know this. With a flick of a switch, I can work local-only (when you’re disconnected from the Internet) or directly with the server.
Technically this DAO approach is part of the architecture. It enables the object model, which consists of the entities, their fields, and how they connect to each other, as detailed in the chart. The model is merely an abstraction, which I could implement it with many different architectures.
For the curious, I’m using JPA (Java Persistence API) to do object-relational mapping both locally and on the server. All queries exist as methods in the DAO, so these details are hidden. The communication between client and server can easily switch between Remote EJB and JAX-RS. I implemented both to see which I liked better. Currently Remote EJB is winning, but when we port to tablets, we’ll have to use JAX-RS.