Design principles

The following is a list of design principles when creating Scooter Framework.

Type less and accomplish more

There are many useless labor works in Java programming, such as typing attributes of a domain class, typing getter and setter methods for every attribute, start-stop-restart web servers, packaging-and-repackaging deployment files, etc. These labor works consume a significant amount of our time.

However, we are hired as a programmer not a typist. We are tasked to solve a business problem, not strike keys. A good framework should help programmers doing less useless labor work and accomplish more.

Scooter Framework comes with the following capabilities that save programmers from non-business related laboring work:

Embrace databases

Databases are not evil. They are valuable tools that store data and application states. Many enterprises have invested millions of labor hours in database sql queries, functions, and stored procedures etc.

Scooter Framework recognizes this fact and have the following features to work with databases:

  • Composite primary key friendly
  • Configurable database table name pattern
  • Active Record based domain model
  • Using SQL statements directly inside Java code
  • Managing SQL statements in an external property file
  • Multiple databases

Convention over configuration (COC)

The importance of COC principle can be presented by comparing Java code written with and without COC in mind.

The following Java code and database script samples are copied from a published paper on a popular technology portal site. The Java code is written based on some other orm frameworks.

import javax.persistence.*;

@Table(name = "PURCHASE_ORDERS")
public class PurchaseOrder {

    PurchaseOrder() {}

    PurchaseOrder(BillingAddress billingAddress) {
    street = billingAddress.getStreet();
    city = billingAddress.getCity();

    @AttributeOverride(name = "street",
    column = @Column(name="STREET")),
    @AttributeOverride(name = "city",
    column = @Column(name="CITY"))

    private String street;
    private String city;
    private String itemName;

    public String getItemName() {
        return itemName;

    public void setItemName(String itemName) {
        this.itemName = itemName;
The corresponding database schema:
create table PURCHASE_ORDERS (
        street varchar(255) not null,
        city varchar(255) not null,
        itemName varchar(255),
        primary key (street, city)

When using Scooter Framework, the domain class becomes much clearer and simpler with just a few lines of code.


import com.scooterframework.orm.activerecord.ActiveRecord;

public class PurchaseOrder extends ActiveRecord {

By comparing the same PurchaseOrder class implemented by different frameworks, we can see that annotations are unnecessary:

    No need to declare @Entity: It is a model (entity) class as long as it is in the model directory.
    No need to declare @Table: The table name can be decoded from the model class name.
    No need to declare @IdClass and @Id: primary key fields are detected automatically.
    No need to use @AttributeOverrides: there is no attribute listing.
    No need to use @Column: columns are part of meta data that we can get from the database.
    No need to write getters and setters: there is no need to repeat each column as attribute.

This is the power of COC.

Don't repeat yourself (DRY)

Many J2EE frameworks keep database meta data in a config file which are usually in xml format. Developers have to maintain a mapping file for each table in the database.

This sometimes causes lots of headache for developers as they have to make sure the database meta data on their side is in sync with the database meta data inside the database. This extra work is a direct consequence of violating this DRY principle.

Scooter Framework saves:

  • No duplicating domain model meta data in Java code
  • Automatic detecting database schema changes

Test friendly

Testing is very important in software development. Scooter Framework targets database-backed application development. It comes with a set of test classes so that developers can do unit testing and functional testing by simply executing a test target in build.xml script. See test guide for more details.