ドキュメントには次のように記載されています。
Grails チームは、コア アプリケーション ロジックをコントローラー内に埋め込むことを推奨していません。
src/groovy フォルダーに 1 つの API コントローラーといくつかの Groovy クラスがあります。これらのクラスはアプリケーション ロジックを実装するだけなので、API コントローラーのアクションは次のように動作します。
//index page
def index = {
render new IndexApi().index(params) as JSON
}
興味があります。アプリケーション ロジックを単純な groovy クラスからサービスに移動する理由はありますか?
実際、サービスは単なるトランザクションではありません。サービスは、ゼロ構成の注入可能なシングルトン コンポーネントに最適であり、grails 環境全体を再起動せずにリロードできます。また、アーティファクトとして検出されるため、リモート プラグインで自動的に公開されます。
トランザクション動作が必要な場合は、ロジックをサービスに配置する必要があります。それ以外の場合は、自分で処理する必要があり、Grails を使用する精神に反します。
私自身は Grails の専門家ではないので、ビルダー クラス、ヘルパー、およびトランザクションではないがサービス層から使用されるその他のロジックなど、「非トランザクション」クラスをサービス層の外に配置しました。
3つの理由があります：
これにより、コントローラーが小さくなり、理解と保守が容易になります
これにより、ロジックのテストが容易になります。
トランザクションを手動で管理する必要はありません。
すべてをコントローラーに配置する場合は、任意のテストを実行できるようにWebランタイムを作成する必要があります。ロジックが外部にある場合は、HTTPリクエストと他のすべてのソースから必要なデータをコピーして、コードを呼び出すだけです。したがって、ロジックはHTTPセッション、リクエスト、またはその他の不要なものに依存しません。
たとえば、JSPをテストするには、HTTPRequestが必要です。リクエストには、HTTPSessionとJSPWriterが必要です。それらにはセッションコンテキストが必要です。したがって、単一のテストを実行できるようにするには、一連のクラス全体をセットアップして初期化する必要があります。そして、それらはすべてインターフェースであり、実装はプライベートです。したがって、実際のメソッド（300個すべて）を自分で実装する必要があります。そして、あなたはこれを正しくする方が良いです、さもなければあなたのテストはあなたが望むものをテストしません。