私はプロジェクトのドメインモデルに取り組んでいます。プロパティの1つとしてUserTypeという名前のクラスを持つuserという名前のクラスがあります。すべてのユーザーを選択する場合は、結合を使用して対応するすべてのユーザータイプを選択します。挿入はどうすればよいですか？userTypeのハンドラーを作成する必要がありますか？または私は次のようなことをすることができます
INSERT INTO users(... usertype_id ...) VALUES(... #{usertype.usertype_id}...)
助けてください;
私はこれを理解しようと一日中過ごしました。私はibatis3.0を使用していますが、ibatisは初めてです。
Ibatisは完全なORMフレームワークではないため、オブジェクトの関係については認識していません。したがって、テーブル内のレコードに完全に対応していないドメインオブジェクトを直接操作する場合は、 INSERTのようなものを作成する必要があります。つまり、IbatisでマッピングしているUserオブジェクトにgetUsertypeId()メソッド（テーブル列usertype_idに対応する値を返す）がなく、代わりにgetUserType()メソッドがある場合です。
（もちろん、 内部で...getUsertypeId()を呼び出すメソッドを作成することもできますが、ここで停止して、DbなどからUsertypeIdを内部でロードしようとする）もあります。これは、問題を引き起こします。 。JPA / Hibernateの再発明は終了します。）getUserType().getId()setUserTypeId(int id
TypeHandlerが正しいアプローチだとは思いません。その機能は、関係を処理するためではなく、重要な型を変換することを目的としています。
もう1つの有効なアプローチは、テーブルの列に直接マップするプロパティ（たとえば、プロパティがあり、メソッドがなく、ビジネスインテリジェンスや依存関係がないUserDbオブジェクト）を使用して、テーブルごとにほぼ1つずつ、比較的低レベルのダムPOJOのレイヤーを作成することです。上位層または永続性の知識）、さらにその上に、より豊富な「実際の」ドメインオブジェクトの層があり、それぞれがそれらの「ダム」POJOの（通常は小さい）グラフをラップし、呼び出しに必要なインテリジェンスを備えていますグラフをロード/保存するための永続化レイヤー（DAOなど）（おそらく遅延）。 userTypeIdgetUserType()
このアプローチの利点の1つは、実際のibatisマッピングのコア（SQLコーディング）をIbatorでかなり自動的に実行できることです。つまり、DBスキーマからPOJOのコードを作成することもできます。
多くのテーブル（レポート）を含むデータの大規模な読み取りの場合、他の単純なアドホックPOJOを作成できます（これはSELECTの列に直接対応し、値を表示するための基本的なインテリジェンスを備えている可能性があります-「ViewModel」のようなもの） ...またはHashMapsですら。
PS： DDD（および「エンティティ」、「値オブジェクト」、「ビュー」、「コンテキスト」、「リッチドメインオブジェクト」と「貧血ドメインオブジェクト」などの概念）について読みたいと思うかもしれません。Ibatisを使用すると、この方針に沿って学習および実装するための柔軟性が大幅に向上します。