11 サービスレイヤー

サービスを作成する

Creating a Service

grails create-service helloworld.simple

If no package is specified with the create-service script, Grails automatically uses the application name as the package name.

create-serviceスクリプト実行した際にパッケージ名を指定しなかった場合は、アプリケーション名をパッケージ名として使用します。

package helloworld
class SimpleService {
}

11.1 断定的なトランザクション

デフォルトの宣言的トランザクション

Default Declarative Transactions

class CountryService {
    static transactional = false
}

Warning: dependency injection is the only way that declarative transactions work. You will not get a transactional service if you use the new operator such as new BookService()

警告：依存性の注入は、宣言的トランザクションが機能する唯一の方法です。new BookService()のようにnew演算子を使用した場合、トランザクションなサービスを取得するできません。

Checked exceptions do not roll back transactions. Even though Groovy blurs the distinction between checked and unchecked exceptions, Spring isn't aware of this and its default behaviour is used, so it's important to understand the distinction between checked and unchecked exceptions.

カスタムトランザクションの設定

Custom Transaction Configuration

Annotating a service method with Transactional disables the default Grails transactional behavior for that service (in the same way that adding transactional=false does) so if you use any annotations you must annotate all methods that require transactions.

Transactionalアノテーションをメソッドに指定すると、デフォルトの書式(transactional=falseでの定義)でのトランザクションは無効になります。アノテーションを使用する場合は、トランザクションが必要な全てのメソッドに定義する必要があります。

import org.springframework.transaction.annotation.Transactional
class BookService {
    @Transactional(readOnly = true)
    def listBooks() {
        Book.list()
    }
    @Transactional
    def updateBook() {
        // …
    }
    def deleteBook() {
        // …
    }
}

import org.springframework.transaction.annotation.Transactional
@Transactional
class BookService {
    def listBooks() {
        Book.list()
    }
    def updateBook() {
        // …
    }
    def deleteBook() {
        // …
    }
}

import org.springframework.transaction.annotation.Transactional
@Transactional
class BookService {
    @Transactional(readOnly = true)
    def listBooks() {
        Book.list()
    }
    def updateBook() {
        // …
    }
    def deleteBook() {
        // …
    }
}

11.1.1 トランザクションロールバックとセッション

Understanding Transactions and the Hibernate Session

When using transactions there are important considerations you must take into account with regards to how the underlying persistence session is handled by Hibernate. When a transaction is rolled back the Hibernate session used by GORM is cleared. This means any objects within the session become detached and accessing uninitialized lazy-loaded collections will lead to LazyInitializationExceptions.

To understand why it is important that the Hibernate session is cleared. Consider the following example:

class Author {
    String name
    Integer age
    static hasMany = [books: Book]
}

If you were to save two authors using consecutive transactions as follows:

Author.withTransaction { status ->
    new Author(name: "Stephen King", age: 40).save()
    status.setRollbackOnly()
}
Author.withTransaction { status ->
    new Author(name: "Stephen King", age: 40).save()
}

Only the second author would be saved since the first transaction rolls back the author save() by clearing the Hibernate session. If the Hibernate session were not cleared then both author instances would be persisted and it would lead to very unexpected results.

It can, however, be frustrating to get LazyInitializationExceptions due to the session being cleared.

For example, consider the following example:

class AuthorService {
    void updateAge(id, int age) {
        def author = Author.get(id)
        author.age = age
        if (author.isTooOld()) {
            throw new AuthorException("too old", author)
        }
    }
}

class AuthorController {
    def authorService
    def updateAge() {
        try {
            authorService.updateAge(params.id, params.int("age"))
        }
        catch(e) {
            render "Author books ${e.author.books}"
        }
    }
}

In the above example the transaction will be rolled back if the Author's age exceeds the maximum value defined in the isTooOld() method by throwing an AuthorException. The AuthorException references the author but when the books association is accessed a LazyInitializationException will be thrown because the underlying Hibernate session has been cleared.

To solve this problem you have a number of options. One is to ensure you query eagerly to get the data you will need:

class AuthorService {
    …
    void updateAge(id, int age) {
        def author = Author.findById(id, [fetch:[books:"eager"]])
        ...

In this example the books association will be queried when retrieving the Author.

This is the optimal solution as it requires fewer queries then the following suggested solutions.

Another solution is to redirect the request after a transaction rollback:

class AuthorController {
    AuthorService authorService
    def updateAge() {
        try {
            authorService.updateAge(params.id, params.int("age"))
        }
        catch(e) {
            flash.message "Can't update age"
            redirect action:"show", id:params.id
        }
    }
}

In this case a new request will deal with retrieving the Author again. And, finally a third solution is to retrieve the data for the Author again to make sure the session remains in the correct state:

class AuthorController {
    def authorService
    def updateAge() {
        try {
            authorService.updateAge(params.id, params.int("age"))
        }
        catch(e) {
            def author = Author.read(params.id)
            render "Author books ${author.books}"
        }
    }
}

Validation Errors and Rollback

A common use case is to rollback a transaction if there are validation errors. For example consider this service:

import grails.validation.ValidationException
class AuthorService {
    void updateAge(id, int age) {
        def author = Author.get(id)
        author.age = age
        if (!author.validate()) {
            throw new ValidationException("Author is not valid", author.errors)
        }
    }
}

To re-render the same view that a transaction was rolled back in you can re-associate the errors with a refreshed instance before rendering:

import grails.validation.ValidationException
class AuthorController {
    def authorService
    def updateAge() {
        try {
            authorService.updateAge(params.id, params.int("age"))
        }
        catch (ValidationException e) {
            def author = Author.read(params.id)
            author.errors = e.errors
            render view: "edit", model: [author:author]
        }
    }
}

11.2 サービスのスコープ

• prototype - クラスへの注入時にサービスが生成される
• request - リクエスト毎にサービスが生成される
• flash - 現在とその次のリクエスト用にサービスが生成される
• flow - フローの開始から終了まてのサービス(サブフロー含まず)
• conversation - フローの開始から終了まてのサービス(サブフロー含む)
• session - ユーザセッション毎にサービスが生成される
• singleton (デフォルト) - サービスが1つのみ生成される

If your service is flash, flow or conversation scoped it must implement java.io.Serializable and can only be used in the context of a Web Flow

サービスのスコープがflash、flowあるいはconversationの場合、java.io.Serializableを実装する必要があり、Webフローのコンテキストの中でだけ使うことができます。

static scope = "flow"

11.3 依存注入とサービス

依存性の注入の基本

Dependency Injection Basics

class BookController {
    def bookService
    …
}

class AuthorService {
    BookService bookService
}

NOTE: Normally the property name is generated by lower casing the first letter of the type. For example, an instance of the BookService class would map to a property named bookService.

注:通常、プロパティ名は、型の最初の文字を小文字のにして生成します。たとえば、BookServiceクラスのインスタンスは、bookServiceという名前のプロパティにマップされます。

To be consistent with standard JavaBean conventions, if the first 2 letters of the class name are upper case, the property name is the same as the class name. For example, the property name of the JDBCHelperService class would be JDBCHelperService, not jDBCHelperService or jdbcHelperService.

標準のJavaBean規約と整合をとるため、クラス名の最初の2文字が大文字の場合、プロパティ名はクラス名と同じになります。たとえばJDBCHelperServiceクラスは、jDBCHelperServiceまたjdbcHelperServiceでは無く、JDBCHelperServiceという名前のプロパティにマップされます。

See section 8.8 of the JavaBean specification for more information on de-capitalization rules.

小文字への変換規則の詳細については、JavaBeanの仕様のセクション8.8を参照してください。

依存性注入とサービス

Dependency Injection and Services

class AuthorService {
    def bookService
}

依存性注入とドメインクラス/タグライブラリ

Dependency Injection and Domain Classes / Tag Libraries

class Book {
    …
    def bookService
    def buyBook() {
        bookService.buyBook(this)
    }
}

Service Bean Names

The default bean name which is associated with a service can be problematic if there are multiple services with the same name defined in different packages. For example consider the situation where an application defines a service class named com.demo.ReportingService and the application uses a plugin named ReportingUtilities and that plugin provides a service class named com.reporting.util.ReportingService. The default bean name for each of those would be reportingService so they would conflict with each other. Grails manages this by changing the default bean name for services provided by plugins by prefixing the bean name with the plugin name. In the scenario described above the reportingService bean would be an instance of the com.demo.ReportingService class defined in the application and the reportingUtilitiesReportingService bean would be an instance of the com.reporting.util.ReportingService class provided by the ReportingUtilities plugin. For all service beans provided by plugins, if there are no other services with the same name within the application or other plugins in the application then a bean alias will be created which does not include the plugin name and that alias points to the bean referred to by the name that does include the plugin name prefix. For example, if the ReportingUtilities plugin provides a service named com.reporting.util.AuthorService and there is no other AuthorService in the application or in any of the plugins that the application is using then there will be a bean named reportingUtilitiesAuthorService which is an instance of this com.reporting.util.AuthorService class and there will be a bean alias defined in the context named authorService which points to that same bean.

11.4 Javaからサービスを使う

class BookService {
    void buyBook(Book book) {
        // logic
    }
}

package bookstore
class BookService {
    void buyBook(Book book) {
        // logic
    }
}

package bookstore
interface BookStore {
    void buyBook(Book book)
}

class BookService implements bookstore.BookStore {
    void buyBook(Book b) {
        // logic
    }
}

// src/java/bookstore/BookConsumer.java
package bookstore;
public class BookConsumer {
    private BookStore store;
    public void setBookStore(BookStore storeInstance) {
        this.store = storeInstance;
    }
    …
}

<bean id="bookConsumer" class="bookstore.BookConsumer">
    <property name="bookStore" ref="bookService" />
</bean>

import bookstore.BookConsumer
beans = {
    bookConsumer(BookConsumer) {
        bookStore = ref("bookService")
    }
}