Using Groovy AOP to express business logics in Grails framework
This document describes a number of problems found in the scenario of applying Groovy AOP to Grails framework that reflects Comprehensibility.
From http://grails.org,
"Grails aims to bring the "coding by convention" paradigm to Groovy. It's an open-source web application framework that leverages the Groovy language and complements Java Web development. You can use Grails as a standalone development environment that hides all configuration details or integrate your Java business logic. Grails aims to make development as simple as possible and hence should appeal to a wide range of developers not just those from the Java community."
There are high-level artefacts e.g., Controllers, or Domain classes in Grails framework. An AOP language needs a good design to cover high-level pointcuts for expressing such software artefacts in Grails. Moreover, Grails is extensible via its plug-in system. A developer can define their own artefacts in a newly developed plug-in. For Grails, the AOP language needs to be extensible to capture join points introduced by these artefacts.
For example, Groovy AOP comes with a set of primitive pointcuts like:
- pcall(pattern)
- etc.
But these do not reflect the semantics of Grails artefacts. Their users need some PCDs like:
- controller(pattern)
- action(pattern)
- etc.
Here is an example of a web application written using Grails.
class BookController {
def list = {
def books = Book.list()
render(view:'book', model:[books: books])
}
def show = {
...
}
def update = {
...
}
}
An aspect written in Groovy AOP:
aspect SecurityAspect {
def pc = pcall('BookController.*')
around(pc) {
// check access
}
}
An aspect written in Groovy AOP, with a higher level of PCDs:
aspect SecurityAspect {
def pc = controller('book') & action('*')
around(pc) {
// check access
}
}
An aspect written using a variant syntax Groovy AOP, with a higher level of PCD (shortcut form):
This syntax is probably preferred by the developers, according to idioms they are familiar with.
aspect SecurityAspect {
around(controller:'book', action:'*') {
// check access
}
}
Groovy AOP also needs to support a good way to be able to extend and cover a new software artefact added through Grails plugin system as well.
Conclusion
As a general purpose AOP system for Groovy, Groovy AOP can be used with Grails framework. It may help expressing business logics as application-level aspects. However, the implementation of Grails framework is dynamic because a developer can add a new software artefact by creating a plug-in. To make an AOP system meets this requirement, it should support the ability to define new PCDs through the same plug-in architecture.
Ability to understand by developers ?
- A system should provide idioms that developer are familiar with in the AOP language
Ability to evolve & customize ?
- A system should provide the way to define new PCDs
How well does AOSD support/go along with Comprehensibility?
- Depends on its implementation, and its base language (e.g. Java / AspectJ, Groovy / Groovy AOP). Currently, Groovy AOP has not support this approach well yet.
