2017年度 Java 永続化フレームワークについての推測(3) Reladomo

#前ポスト
- [2017年度 Java 永続化フレームワークについての考察(1)](http://qiita.com/shiroma_yuki/items/8d434862bba072bff264)
- [2017年度 Java 永続化フレームワークについての考察(2) Doma2](http://qiita.com/shiroma_yuki/items/d0e3b319626f4278fc6f)

#前置き
隙間時間を利用して書いているので精度の甘い箇所があれば、ご指摘いただけると幸いです。
まずEOLであるものは除外。
有償の機能については検討対象に含むが、実際に使用はしません、懐の問題で。
「まぁ、たぶん明記されてなくてもPostgreならいけるだろ」ぐらいの間抜けな理由で使用DBはPostgreに固定。

#環境
**ネットワーク環境的な問題から動作確認できていません。**
gradleもmavenもリポジトリに接続できなくて動かないため推測記事になります、ご了承ください……
antでMithraGeneratorを叩けばいけるはずだけど、これは面倒くさい……

#対応範囲
|ORM|Transaction|Data Model|DSL|
|:-:|:---------:|:--------:|:-:|
|○|※1|※2|○|
○:対応
×:非対応
※1:Geronimo JTAに依存
※2:バイテンポラルデータモデルをネイティブサポート

#所感
- 「規約より定義」感
- XMLからすべてを生み出す構成、テーブルDDLどころかインデックスDDLまでXMLの定義次第で生成される
- DSLから感じる遅延評価の気配
- テンポラルデータモデル、バイテンポラルデータモデルをサポートするが、使わなくてもよい
- DSLからのSQL生成であるため、ユーザが挙動を熟知している必要がある
- 全体的に「高度にシステム化された内容を、明瞭な共通認識の下に生産する」ことを目的としたDSLっぽい

#サンプル
##単テーブル検索
``` EmployeeSearchTest.java
// 主キー検索
MithraManagerProvider.getMithraManager().executeTransactionalCommand(tx -> {
    Employee employee = EmployeeFinder.findOne(EmployeeFineder.id().eq(BigDecimal.ZERO));
});
// 全件検索
MithraManagerProvider.getMithraManager().executeTransactionalCommand(tx -> {
    EmployeeList list = new EmployeeList(EmployeeFiner.all());
});
```
```Employee.xml
<MithraObject
    objectType="transactional"
    xmlns:xsi="http://www.w3.org/2001/XML-Schema-instance"
    xsi:noNamespaceSchemaLocation="mithraobject.xsd">

    <PackageName>jp.co.qualsyite.</PackageName>
    <ClassName>Employee</ClassName>
    <DefaultTable>employee</DefaultTable>

    <Attribute
        name="id"
        javaType="java.util.BigDecimal"
        columnName="id"
        primaryKey="true"
        primaryKeyGeneratorStrategy="SimulatedSequence">

        <SimulatedSequence
            sequenceName="employee"
            sequenceObjectFactoryName="jp.co.qualysite.ObjectSequenceFactory"
            hasSourceAttribute="false"
            batchSize="1"
            initialValue="0"
            incrementSize="1"/>
    </Attribute>
    <Attribute name="firstName"  javaType="java.lang.String" columnName="first_name"  nullable="false" maxLength="60" />
    <Attribute name="middleName" javaType="java.lang.String" columnName="middle_name" nullable="false" maxLength="60" />
    <Attribute name="lastName"   javaType="java.lang.String" columnName="last_name"   nullable="false" maxLength="60" />
    <Attribute name="from"       javaType="java.util.Date"   columnName="from"        nullable="false" />
    <Attribute name="thru"       javaType="java.util.Date"   columnName="thru"        nullable="false" />
    <Attribute name="in"         javaType="java.util.Date"   columnName="in"          nullable="false" />
    <Attribute name="out"        javaType="java.util.Date"   columnName="out"         nullable="false" />

    <Relationship
        name="posts"
        relatedObject="Post"
        cardinality="one-to-many">
            this.id = Post.employeeId
    </Relationship>
</MithraObject>
```

##テーブル結合

#要点
- カバー範囲はORM+データモデルロジック
- DSLはJava実装なのでIDEの補完機能が効く
- データモデル側で車輪の再発明をする必要がないため、そこが強い
- XMLでガチガチに固めるため、システムありきで構造がしっかりしている必要がありそう

#ハマったポイント
ハマったっていうか動いてない。

#後ポスト
- [2017年度 Java 永続化フレームワークについての考察(4) jOOQ](https://qiita.com/shiroma_yuki/items/1f64cac07afc745579a5)

#参考記事
- [Reladomo Kata](https://goldmansachs.github.io/reladomo-kata/main-kata-presentation/ReladomoKata.xhtml#(1))