Skip to main content

Architecting Applications 1: the model

Posted by zixle on January 18, 2006 at 4:33 PM PST

While in Russia (see Shannon's blog) I wrote a long blog on undo, actions and various other things. At the time I felt this a bit long for a blog and so it languishes in my unposted blog queue (with many others, but that's a different story). I really liked the idea of writing a series of blogs centered around a real app though, hence this blog and hopefully more to follow.

As part of the series I'll cover architecting the app (this blog) including using beans persistence as a way to save the model, Actions, Undo, the need for an application class, data binding and various other things that come up.

In writing a series of blogs around an app I thought it important that the app be compelling enough, but not too big such that you become bogged down in all the implementation details. So, I needed something small but not too small as to be trivial. I may have erred on the side of trivial, none-the-less the concepts and points are still worth while to explore.

If you're like me you have a ton of passwords for various machines and web sites that you're expected to remember. As an added wrinkle each password should be unique and unreadable, ugh! Added together this makes it nearly impossible to remember all your passwords. For this series I'm going to stick with a simple app that manages passwords. A Java based app that stores passwords has the added bonus of being able to run from a USB memory stick on the three major platforms: Windows, OS X and Linux. I realize there are loads of commercial apps in this space that undoubtedly go way beyond what I'm going to do. None-the-less such an app is at least interesting and not too complicated (at least as far I'm going to take it).

Here's roughly where I'll end up when done with the series:

A password store will need to be encrypted, I'm going to leave that out as I don't want to worry about the legal issues of such a blog.

There are various approaches to designing apps. Some of the more popular patterns are model-view-presenter , presentation model and model-view-controller. I'm a fan of the latter, and especially for an app of this size. In creating any app you'll need to make the desicision as to which approach is applicable to your design space and requirements.

Model-View-Controller dictates that you have a clear model for your application. The Controller coordinates keeping the view and model in sync. The model for Password Store is going to be trivial. It'll consist of a List of PasswordEntrys. Each PasswordEntry will have the following properties: host, user and password. PasswordEntry will be a proper bean in that it'll communicate changes to listeners by way of a PropertyChangeListener notification. That means any time you change a property all PropertyChangeListeners are notified of the change. Here's the code for setting the host property:

    public void setHost(String host) {
        String oldHost =; = host;
        if (propertySupport != null) {
            propertySupport.firePropertyChange("host", oldHost, host);

The methods for setting the user and password follow the same pattern. This may seem like a lot of boilerplate code for something so trivial, and I would agree. I'll try and address that in a later blog.

The List of PasswordEntrys will be managed by a PasswordModel. PasswordModel will initially expose the List as modifiable. I suspect this is a bad long term decision, but I'm going to stick with it in hopes of keeping the API simple and not getting bogged down in details. Here's the code:

public class PasswordModel {
    private List passwordEntries;
    public PasswordModel() {
        passwordEntries = new ArrayList(1);
    public List getPasswordEntries() {
        return passwordEntries;

The biggest downside with choosing List is that it doesn't notify listeners of changes to the contents. This is key, and something I'll touch on later.

An added bonus of making the PasswordEntrys proper beans is that I can save and restore the PasswordEntrys using beans persistence. Here's the code:

    public void load(String file) throws IOException {
        BufferedInputStream inputStream = new BufferedInputStream(
                new FileInputStream(file));
        XMLDecoder decoder = new XMLDecoder(inputStream);
        List entries = (List)decoder.readObject();
    public void save(String file) throws IOException {
        BufferedOutputStream outputStream = new BufferedOutputStream(
                new FileOutputStream(file));
        XMLEncoder encoder = new XMLEncoder(outputStream);

At this point we have the model, which by itself isn't all that interesting. Next time around by the end of the blog we should have something that you can at least run.


Related Topics >>