Skip navigation links

Package uk.ac.ed.epcc.webapp.model.data

This package implements the data layer that connects the SQL database with the Java model.

See: Description

Package uk.ac.ed.epcc.webapp.model.data Description

This package implements the data layer that connects the SQL database with the Java model.

As far as is reasonably possible we try to encapsulate any dependency on the JDBC classes within this package. We also aim to concentrate the appearance of SQL fragments to be only within this package as much as is reasonably practical. Though it is very unlikely that we will ever want to move away from using JDBC for data persistence this encapsulation makes it easier for us to refactor the implementation. Database tables and records are abstracted into the Repository and Repository.Record classes Select conditions are abstracted into the classes and interfaces in the uk.ac.ed.epcc.webapp.jdbc.filter package.

The data model is that every database table has a corresponding Java class. Instances of these classes correspond to rows in the database.

At lowest level of the API are the Repository and Repository.Record classes. These are final classes that represent a database table and a table record respectively. This package also contains the abstract DataObject and DataObjectFactory classes. These classes are sub-classed to produce the table specific model classes.

There is a very close parallel between Repository/Record and DataObjectFactory/DataObject. The first are Database facing final classes providing an abstraction layer above JDBC. The second are application facing abstract classes that are subclassed to provide customised classes for individual database tables, containing internal references to the the appropriate Repository/Record objects. This two level approach allows a great deal of flexibility to refactor the domain objects without requiring a corresponding reformat of the database schema. It also allows a greater separation of concerns.

The DataObjectFactory class implements methods for extracting sets of multiple database entries. We use a Factory class rather than static methods because this allows us to inherit common factory code and add additional behaviour suitable to particular domain objects.

In many cases the factory and the target class are independent classes (we often keep one as a static inner class of the other to keep them associated). Where the Objects are more likely to be implemented as Sets of objects rather than individuals we can make the DataObject an inner class (or pseudo-inner class) of the Factory see LinkManager and HistoryFactory.

The classes in uk.ac.ed.epcc.model.data.forms provide an interface for building user interface forms. These can be used to easily construct interface forms. Though most modifications to model state come via custom application logic, two very common operations are to create and to modify individual domain objects. This is particularly important as part of the application management functions. The DataObjectFormFactory class contains code to produce creation and update forms for a DataObject based on the SQL schema. This class is sub-classed to produce Creator and Updater which implements the default create/update logic. Individual model classes may sub-class these to customise the behaviour. We also want to be able to set class-specific defaults for both the create and update forms. This is implemented by having the default methods in DataObjectFormFactory call methods in the DataObjectFactory. Originally this functionality was implemented directly in the DataObjectFactory but the forms code was considered to be a sufficiently distinct responsibility to merit its own class.

There are many different frameworks available for doing database persistence of Java objects. This particular scheme is database centric in that much of the behaviour of the object is driven by the Database schema rather than in the source of the object. For example if an additional field is added to a table additional fields will appear in the form used to create that object. A text field that can be null in the database can be left blank in a form. The API of Repository.Record allows DataObjects to access a database field if it exists and to pick up a default value if it does not.

 
Skip navigation links