Java development is all about getters and setters. Ever since the Java Beans framework introduced in 1997, this has become a blessing (and a plague some argue) in modern Java applications. ActiveJDBC does not require getters and setters for models. Since models already know all the allowable metadata from database at startup, they will perform validations of names of attributes.

Built in getters and setters

ActiveJDBC provides two base methods for getting information from DB and putting it in:

The name is a name of a column from a table PEOPLE. Same goes for a setter:

Wrapper setters/getters???

ActiveJDBC will not provide these. However, you can have them if you like:

This will provide a safety net to those wishing some compiler static checking. With ActiveJDBC you can use dynamic getters and setters or write wrapper getter and setter methods. Please, see Recommendation below for more information.

##Type conversion getters

ActiveJDBC provides a number of type conversion getters:

ActiveJDBC will do all possible to convert your data into the type. This also goes for CLOBs:

If the BODY column in your table is CLOB, ActiveJDBC will automatically convert it to Java String.

Please, see Clob support and caching as well as JavaLite Commons Convert class for more information.

Recommendation: Use TDD, in combination with some setters and getters

In our work, we start writing a test before writing much code. We create a one line model code, then start writing a test. Inside the test, we write a piece of code I know will fail:

The table PEOPLE does not have a column BLAH, and ActiveJDBC is conveniently telling me this:

java.lang.IllegalArgumentException: Attribute: 'blah' is not defined in model: 'class org.javalite.activejdbc.test_models.Person and also, did not find an association by the same name,
available attributes: [id, updated_at, graduation_date, dob, name, last_name, created_at]

From this message, I see that the allowed attributes are:

id, updated_at, graduation_date, dob, name, last_name, created_at

which gives me all the information I need to start writing a real test.

Since I know from Autogenerated Fields that id, updated_at and created_at are auto-generated columns and I need not touch them, I?m left with these to work:

graduation_date, dob, name, last_name

When we are done with the test, we have a piece of durable code which has captured required model behaviour. We then proceed to implement the rest of the model code - necessary validations, other code, until the test starts to pass.

General rule of thumb : only write setters and getters for attributes you are actually using in code.

In our projects over the past 5 years using ActiveJDBC and ActiveWeb, we progressed through three stages of understanding our coding patterns:

  • Stage 1: First we were excited and used dynamic setters and getters across the project, a la Ruby on Rails: String name = p.getString("name");. Then we realized that like Ruby developers we were not getting any benefits from static typing of Java or from autocomplete from IDEs, no refactoring help, and moved to Stage 2:
  • Stage 2: Write setter and getters fr every attribute. We immediately got refactoring, IDE support and static typing. However, nobody was happy writing them. There was even an attempt to autogenerate them, but due dynamic nature of ActiveJDBC (attributes based on columns in tables), this prove too much work, we progressed to stage 3:
  • Stage 3: Write only getters and setters that are used in code verbatim. In most cases, when reading a submitted form from a web page, or reflecting attributes on a web page, ActiveWeb or a JSP can read these attributes dynamically, which means you do not need setters and getters. In rare cases we use them verbatim in code, and for those cases, the attributes are wrapped in setters and getters.

For example, here is the Book model. As you can see it has no setters and getters. Here is its use in controller: BookController as well as view: books/index.ftl.

As you can see, nowhere in code we had to access attribute directly, therefore we did not write setters and getters.

How to comment

The comment section below is to discuss documentation on this page.

If you have an issue, or discover bug, please follow instructions on the Support page