Tao of Spring Roo
Tao of Spring Roo
As you see, Spring Roo is not only a simple scollad tool for code generation, it also try to introduce a new programming model.
AspectJ and AOP programming
Roo is heavily dependent on AspectJ, the famous AOP framework, which is a subproject of Eclipse.org.
With the benifit of AspectJ, Roo try to separate the concern of an entity class.
The entity class itself focuses on the declaration of business fields, and only includes the basic definition of the properties and bean validation declaration, the JPA specific definitions are moved to Roo_Jpa_Entity aspect, and the toString helper method is included in the Roo_ToString aspect, the setter and getter methods of the properties are categorized in the _Roo_JavaBean aspect.
As you have seen in the before section, the entity class becomes slim and clean.
Roo will process the .aj files and compile them into classes at compile time. Thus all extra features in the .aj files will be accessible in the entity class at runtime.
In Eclipse IDE, open the Java editor, when you try to get code assistance of the method of class Signup, it will get completion options of all setters and getters of all properties and database CRUD operations. It is same to the later version of Signup class which have been remove all Roo specific features.
In pom.xml file, an aspectj maven plugin is declared, which will help to compile the .aj files into classes.
With the help of AJDT, you can switch between entity class and related the aspect quickly through the markers in the Java editor, you can also open the Cross Reference view to preview the pointcuts and advice.
ActiveRecord Pattern
Roo recommends you always use ActiveRecord pattern in your projects.
If you are a developer switched from Ruby on Rails, you will feel this pattern is very friendly.
But if you are Java web developer and familiar with the multi-layered architecture, you will feel a little incompatible. The codes are a little wired to you, especially after you have removed the the Roo specific features, the entity class becomes very fat.
Fortunately, Roo does not force you to choose AcitveRecord pattern in your project. You can freely select if use AcitveRecord pattern or not when you create an entity class. In order to disable ActiveRecord pattern, just need to specify a –activeRecord=false parameter to the entity command when creating an entity class. By default or set –activeRecord=true to the entity command, Roo will apply the AcitveRecord in the entity class.
ActiveRecord try to use single entity class to centralize all entity related operations. But it make the entity class become very heavy in a real world project. if you do not apply the ActiveRecord, you can choose the multi layered architecture, and create Repository and Service layer for your project respectively, the entity class will become very clean which only includes the mapping fields and some none transactional business logic.
In some books or articles, they are called Rich Model and Anemic Model respectively.
After you removed the Roo specific features, compare the Conference class(and ConferenceRepository and ConferenceService classes) and Signup class to get better understand of this pattern.
Multi Layered Architeture
ActiveRecord
As you see, Spring Roo is not only a simple scollad tool for code generation, it also try to introduce a new programming model.
AspectJ and AOP programming
Roo is heavily dependent on AspectJ, the famous AOP framework, which is a subproject of Eclipse.org.
With the benifit of AspectJ, Roo try to separate the concern of an entity class.
The entity class itself focuses on the declaration of business fields, and only includes the basic definition of the properties and bean validation declaration, the JPA specific definitions are moved to Roo_Jpa_Entity aspect, and the toString helper method is included in the Roo_ToString aspect, the setter and getter methods of the properties are categorized in the _Roo_JavaBean aspect.
As you have seen in the before section, the entity class becomes slim and clean.
Roo will process the .aj files and compile them into classes at compile time. Thus all extra features in the .aj files will be accessible in the entity class at runtime.
In Eclipse IDE, open the Java editor, when you try to get code assistance of the method of class Signup, it will get completion options of all setters and getters of all properties and database CRUD operations. It is same to the later version of Signup class which have been remove all Roo specific features.
In pom.xml file, an aspectj maven plugin is declared, which will help to compile the .aj files into classes.
org.codehaus.mojo
aspectj-maven-plugin
1.2
org.aspectj
aspectjrt
${aspectj.version}
org.aspectj
aspectjtools
${aspectj.version}
compile
test-compile
true
org.springframework
spring-aspects
${java.version}
${java.version}
With the help of AJDT, you can switch between entity class and related the aspect quickly through the markers in the Java editor, you can also open the Cross Reference view to preview the pointcuts and advice.
ActiveRecord Pattern
Roo recommends you always use ActiveRecord pattern in your projects.
If you are a developer switched from Ruby on Rails, you will feel this pattern is very friendly.
But if you are Java web developer and familiar with the multi-layered architecture, you will feel a little incompatible. The codes are a little wired to you, especially after you have removed the the Roo specific features, the entity class becomes very fat.
Fortunately, Roo does not force you to choose AcitveRecord pattern in your project. You can freely select if use AcitveRecord pattern or not when you create an entity class. In order to disable ActiveRecord pattern, just need to specify a –activeRecord=false parameter to the entity command when creating an entity class. By default or set –activeRecord=true to the entity command, Roo will apply the AcitveRecord in the entity class.
ActiveRecord try to use single entity class to centralize all entity related operations. But it make the entity class become very heavy in a real world project. if you do not apply the ActiveRecord, you can choose the multi layered architecture, and create Repository and Service layer for your project respectively, the entity class will become very clean which only includes the mapping fields and some none transactional business logic.
In some books or articles, they are called Rich Model and Anemic Model respectively.
After you removed the Roo specific features, compare the Conference class(and ConferenceRepository and ConferenceService classes) and Signup class to get better understand of this pattern.
Multi Layered Architeture
ActiveRecord
@Entity
public class Conference{
}
@Repository
public class ConferenceRepsoitory extends
JpaRepository
,
JpaSpecificationExecutor
{ } @Service @Transactional public class ConferenceService{ @Autowired ConferenceRepository conferenceRepository; }
@Configurable
@Transactional
@Entity
public class Signup{
@Transactional
public Signup save(){
}
}