先生と生徒の会話形式で理解しよう

生徒

「Quarkusでデータベースを使い始めたんですが、EntityやRepositoryの置き場所が分からなくなってきました…」

先生

「QuarkusではPanache ORMを使うと、データアクセス周りをとても分かりやすく構造化できます。」

生徒

「Panacheって便利そうですが、設計を間違えるとごちゃごちゃしそうで不安です。」

先生

「だからこそ、最初に構造化設計の考え方を整理することが大切です。順番に説明していきますね。」

1. QuarkusとPanache ORMの基本的な関係

QuarkusとPanache ORMは、Javaによるデータベース開発をシンプルにするために設計されています。従来のHibernate ORMは設定や記述が多く、初心者には理解しづらい部分がありました。 Panache ORMは、その複雑さを減らし、直感的なコードでデータ操作を行えるようにしています。

Quarkusのプロジェクト構成の中でPanache ORMを正しく使うことで、 Entity、Repository、Serviceといった役割分担が自然に整理されます。これが構造化設計の第一歩になります。

2. Panache ORMを使うメリットと設計の考え方

Panache ORMの最大の特徴は、ボイラープレートコードを減らせる点です。 findやlistAllといった基本的なデータ取得処理を、短いコードで記述できます。これにより、ビジネスロジックに集中したJava開発が可能になります。

ただし、便利だからといってEntityにすべての処理を書いてしまうと、プロジェクト構成が崩れてしまいます。 QuarkusとPanache ORMでは、役割ごとにクラスを分ける構造化設計が重要です。

3. Quarkusプロジェクトにおける基本パッケージ構成

QuarkusとPanache ORMを使ったプロジェクトでは、パッケージ構成を最初に決めておくことが大切です。初心者でも理解しやすい構成を意識すると、後から迷いにくくなります。


com.example
├─ entity
├─ repository
├─ service
└─ resource

entityにはデータベースと対応するクラス、 repositoryにはデータアクセス処理、 serviceには業務ロジック、 resourceにはREST APIを配置します。これがQuarkusとPanache ORMにおける基本的な構造化設計です。

4. Panache Entityの設計方法

Panache ORMでは、Entityクラスがデータベースのテーブルと対応します。 QuarkusではActive Record形式とRepository形式の両方が選べますが、初心者には構造が分かりやすいActive Record形式から始めるのがおすすめです。


package com.example.entity;

import io.quarkus.hibernate.orm.panache.PanacheEntity;
import jakarta.persistence.Entity;

@Entity
public class User extends PanacheEntity {

    public String name;
    public String email;
}

このようにPanacheEntityを継承することで、 IDや基本的なCRUD処理を自動的に利用できます。 Entityはデータ構造を表すことに専念させるのが設計上のポイントです。

5. Repository層によるデータアクセスの整理

Active Record形式でもRepositoryを併用することで、より構造化された設計が可能になります。 Repository層には、検索条件が複雑な処理や再利用したいクエリをまとめます。


package com.example.repository;

import com.example.entity.User;
import io.quarkus.hibernate.orm.panache.PanacheRepository;
import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class UserRepository implements PanacheRepository<User> {

    public User findByEmail(String email) {
        return find("email", email).firstResult();
    }
}

このようにRepositoryを分けることで、 Entityが肥大化するのを防げます。 Quarkusのプロジェクト構成としても、役割が明確になります。

6. Service層で業務ロジックをまとめる

Service層は、Panache ORMを使ったデータ操作を組み合わせて、業務ルールを表現する場所です。 REST層から直接Repositoryを呼ばず、Serviceを経由する設計が推奨されます。


package com.example.service;

import com.example.entity.User;
import com.example.repository.UserRepository;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Inject;

@ApplicationScoped
public class UserService {

    @Inject
    UserRepository userRepository;

    public User getUserByEmail(String email) {
        return userRepository.findByEmail(email);
    }
}

この構成により、ビジネスロジックが一か所に集約され、変更にも強いQuarkusアプリになります。