Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Jump into Java microframeworks, Part 2: Ninja

Matthew Tyson | Nov. 25, 2015
Build a functional Person application with Ninja.

The ingenuity, creativity, and plain hard work that software developers put into advancing new technologies is truly astounding. This series looks at three shining examples of that output, the Java microframeworks Ninja, Spark, and Play. In Part 1, I explained what makes Java microframeworks both familiar and different from traditional web application frameworks, even relatively lightweight ones like Spring. I also presented quick demos highlighting each framework's respective features. In the next three articles you'll learn a lot more about each of these frameworks, starting with Ninja.

Ninja: A high-quality RVC stack

I previously explained that while I use the term Java microframework, what I am really referring to is an increasingly popular Java framework style that is similar to MVC, but tightly focused on the minimum elements of a web application: routing requests, rendering views, and processing requests in a controller. Whereas MVC is more directly concerned with separation of concerns (with respect to the model, view, and controllers), RVC-style frameworks prioritize exposing the capabilities of routing, views, and controllers to the developer in a convenient and powerful toolset.

If you don't have Ninja set up in your development environment already, please refer to Part 1 for instructions and programming basics. You will also need the updated source code for the demo application (see below). This tutorial will pick up where we left off, adding persistence, logging, a functional UI, and other features that you would need in a working Ninja application.

Ninja demo: Persistence

Our first step for developing a real-world Ninja application is to get its persistence model set up. We'll start with a model class. The example application generates a list of musicians and bands, so our first model class will be a Person, which could be a musician, producer, or songwriter. Recall that after we built our Maven Ninja archetype in Part 1, the project included the Java Persistence API (javax.persistence) interfaces, as well as Hibernate as the ORM implementation provider. The Person model currently looks like what you see in Listing 1.

Listing 1. /src/main/java/models/Person.java



package models;

import javax.persistence.Entity;

import javax.persistence.GeneratedValue;

import javax.persistence.GenerationType;

import javax.persistence.Id;

@Entity

public class Person {

	@Id

    @GeneratedValue(strategy=GenerationType.AUTO)

    Long id;

	@Column(name="first_name")

	private String firstName;

	@Column(name="last_name")

	private String lastName;

	public String getFirstName() {

		return firstName;

	}

	public void setFirstName(String firstName) {

		this.firstName = firstName;

	}

	public String getLastName() {

		return lastName;

	}

	public void setLastName(String lastName) {

		this.lastName = lastName;

	}

}

Note that the @Entity annotation marks the class as a managed persistent one. The @Id and @GeneratedValue annotations specify the primary key field and the strategy for generating it. In JPA, all members are persisted by default unless marked otherwise; therefore, the name fields will be persisted. I added the @Column notations in order to be able to specify names in a way that is compatible with RDBMS.

 

1  2  3  4  5  6  7  8  Next Page 

Sign up for CIO Asia eNewsletters.