[SpringBoot JPAを使用したWebアプリケーションの開発:発注ドメインの開発]

実装機能

商品注文

クエリ

受注履歴

注文キャンセル

オーダー

受注エンティティ、開発受注エンティティ

受注ライブラリ開発

受注サービス開発

開発

受注検索機能

オーダー機能テスト

受注ステータスに基づいた在庫管理

キャンセル

時在庫

を削除

受注エンティティは、作成時に受け取る受注であるため、受注数量に応じて在庫

を削減する必要がある.

整理する

> casecade

エンティティ関係のカスケードを作成しています

    @OneToMany(mappedBy = "order", cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

    @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;

設定すると、プライマリ・テーブルのデータが変更されると、次のテーブルも変更されます(1つのテーブルのみが保持されていても、残りのテーブルは保持されます).
ただし、テーブル関係を決定した場合にのみカスケード設定を行うことが望ましい.
関係のエンディングデザインが不確定な場合は、使用しないほうがいいです.

>Entityの作成方法

Entityで作成方法を使用してサービス層にEntityオブジェクトを作成することで、setterを呼び出して値を追加するなど、ソースを大幅に削減できます.
ただし、個別に開発されていないため、作成したエンティティの作成方法を使用することなく、エンティティオブジェクトを作成することでビジネスロジックを作成できます.
これを防止するために、基本作成者のアクセス制御者を保護するように設定し、他の場所での新しい作成を阻止することができます.

1 : protected Class() {}
2 : @NoArgsConstructor(access = AccessLevel.PROTECTED)

>Entity Classでビジネスロジックを作成する理由

JPAが使用されているため、Entity Classでフィールドの値を変更すると、変更に従って更新クエリが実行されます(JPAの利点).
Mybatisのようなフレームワークを使用すると、クエリーを作成した後に逐一実行する不便さが必要になります.
したがって、Entity値を変更するビジネスロジックは、サービス内ではなくEntity内で作成されます.

- Entity에 비즈니스 로직이 있는 것
[도메인 모델 패턴]
서비스 계층은 단순히 엔티티에 필요한 요청을 위임하는 역할

- Entity에는 비즈니스 로직이 없고 대부분 서비스 계층에서 비즈니스 로직을 처리하는 것
[트랜잭션 스크립트 패턴]
Entity는 getter, setter밖에 없고 보통 SQL을 직접 다루는 스타일에서 사용

各モードはメンテナンスの利便性に応じて使用できます(=Kebake).