CDIとEJBの使い分けについて
この程度の要件であれば、EJBのアノテーション（@Statelessとか@EJBとか）は、使う理由が無いのですか？ ないです。DI、AOP、トランザクション管理に関しては、既に CDI と JTA だけで対応できますし、多くの場合その方がパフォーマンスも良いです。 古の J2EE は何でもかんでも EJB に詰め込んでいました。その当時の選択としては間違ってはいなかったのですが、あまりに大きく重くなり過ぎたため、現在では CDI を筆頭とした周辺の仕様に機能を移管し始めています (最終的には EJB が削除される可能性もあります)。互換性のためしばらくの間は EJB と代替仕様の共存になるでしょうが、新規開発時には基本的に EJB ではない方の仕様を優先した方が良いでしょう。具体的には、CDI か EJB かで迷ったときには、特別な理由がなければ CDI を選択した方が得策です。 現時点で
例外処理 - AWS SDK for Java 1.x
end-of-support の今後の AWS SDK for Java (v1) を発表しました。AWS SDK for Java v2 に移行することをお勧めします。日付、その他の詳細、移行方法については、リンク先の発表内容を参照してください。 翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 例外処理 が例外を AWS SDK for Java スローする方法とタイミングを理解することは、 SDK を使用して高品質のアプリケーションを構築する上で重要です。以下のセクションでは、SDK によってスローされる例外のさまざまなケース、および例外の適切な処理方法について説明します。 非チェック例外を使用する理由 は、次の理由により、チェックされた例外の代わりにランタイム (またはチェックされていない) 例外 AWS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
