DBFlute.NETの紹介

DBFlute.NETとは?

Apache Torque と S2Dao を参考に、現場にフィットすることを重視 したO/Rマッパの .NET環境版 です。Javaの代わりに、C# のクラスを自動生成します。

単に "DBFlute" と言ったとき、"Java版・C#版を問わずにDBFlute全体のこと" もしくは "Java版だけのこと" を指す場合が多く、C#版のDBFluteを明確に表現するときは、"DBFlute.NET" と表現されます。但し、明らかにC#版のDBFluteであることがわかる場合は、単に "DBFlute" と表現することもあります(DBFlute.NETのドキュメント内など)。

O/Rマッパとしての、特徴や概念・ポリシーに関しては、Java版のものと同様ですので、詳しくはそちらのサイトをご覧下さい。

ここでは、Java版との違いに着目して、DBFlute.NET特有の特徴を紹介します。

ひとめでConditionBean (.NET版)

とにかく、ConditionBeanについて、ぱっと見たかったら

DBFlute.NETの構造

自動生成されるソースは C# であり、アプリの実行環境では当然 Java は不要ですが、自動生成プロセスの実行環境において Java(JRE) を利用するのは同じです。だたし、DBFluteモジュールはそれぞれ独立して管理されており、 最新のバージョン、ダウンロードするページなども違いますので、DBFlute.NETのページからダウンロードしてください。

Java版は、DIコンテナに依存せず、かつ、自前でDBアクセスを行うライブラリを有していますが、DBFlute.NETは、Quill を唯一のDIコンテナとし、また、DBアクセスを行うライブラリとして S2Dao.NET を利用しています。ゆえに、DBFlute.NETを利用する際は、必ず Quill + DBFlute.NET + S2Dao.NET という構成になります。

パフォーマンス考慮

DBFlute.NETの場合、DBアクセスを実行するのは "DBFluteランタイム" ではなく、S2Dao.NET です。それゆえ、ちょっとした内部的な動作の違いがところどころに存在しますが、パフォーマンス考慮に関してはJava版と全く同じ考慮がされています。

サポート面の違い

Java版のドキュメント

DBFlute.NETだけで完結したドキュメントは、存在しません。 基本的には、Java版のドキュメントがベースとなり、DBFlute.NET側には、その違いだけを綴ったドキュメントが存在します。 アーキテクト、ディベロッパー共に、違いを理解した上でJava版のドキュメントを読むようにして下さい。

Javaっぽい用語

ドキュメント上で、Javaっぽい用語が利用されます。例えば、DBFlute.NETの説明で "パッケージ" と出てきた場合、大抵の場合それは "名前空間" を示します。また、"Bean" という言葉もご容赦下さい。

コード上のコメントが皆無

コンパイルスピードの確保・リソースの問題の点から、C# クラスやメソッドのコメントは(ほとんど)存在しません。 (Java版(Eclipse)では(C# 環境に比べて)比較的コンパイルスピードが問題になることが少ないため、JavaDocコメントが存在します)

但し、これは時代の流れと共に状況が変わってくる可能性があるため(PCリソースの向上やコンパイラの進化など)、将来的にはコメントの付与も視野に入れています。

機能面の違い

まだ実装されていない機能

以下、DBFlute.NETではまだ実装されていない主な機能です。但し、実装予定は全て未定です。

実装予定のない機能

以下、DBFlute.NETでは、必要性やリソースの問題から実装される予定のない主な機能です。

その他、細かい機能

その他、(細かい挙動の違いを含めて)DBFlute.NETには存在していない機能が存在します。

環境上の違い

Java版と変わる環境周りの主な違いは以下の通りです。

AllCommonパッケージ
Java版におけるDBFluteランタイムのクラス(一部除く)が、AllCommonパッケージ(名前空間)配下に自動生成されます。 DBFluteのフレームワーク(ConditionBeanなどを解析するクラスなど)ごと自動生成されていると言えます。
自動生成クラスをプロジェクトに追加
自動生成されたクラスは、VisualStudio上で明示的に "プロジェクトに追加" する必要がります。特にテーブルを追加した後の再自動生成では、プロジェクトに追加する必要のあるクラスファイルが、 それぞれのディレクトリに散らばっています。Koropokkur.NET には、これらファイルのプロジェクトへの追加を支援する機能があります。
generateOutputDirectory
basicInfoMap.dfprop の generateOutputDirectory のデフォルト値は、'../source'
outputPackageAdjustmentMap
basicInfoMap.dfprop の outputPackageAdjustmentMap に、C#特有の flatDirectoryPackage, omitDirectoryPackage プロパティが存在します。 パッケージ(名前空間)とディレクトリ構造が不一致が許される C# ならではの調整プロパティです。
quillDataSourceName
dependencyInjectionMap.dfprop に、C#特有の quillDataSourceName プロパティが存在します。Quillで管理されているDataSourceの中でどのDataSourceを利用するかを指定します。 複数DB対応時などに利用します。逆に、同dfprop内の別のプロパティはほとんどDBFlute.NETでは利用されないプロパティです。
extendedS2DaoSettingClass
littleAdjustmentMap.dfprop に、C#特有の extendedS2DaoSettingClass プロパティが存在します。DBFlute.NETが利用するS2Dao.NETを拡張する設定クラスを指定します。 DBFlute.NET独自の拡張に加えて、アプリケーションで独自の拡張を加えたいときに利用します。
dbParameterParser
DBFluteConfig に、C#特有の dbParameterParser プロパティが存在します。S2Dao.NET内部で行われるDBパラメータの解析に拡張を加えたいときに利用します。
defaultPackage
outsideSqlDefinitionMap.dfprop に、C#特有の defaultPackage プロパティが存在します。"既定の名前空間" を利用してい場合に、その名前空間を指定することで、外だしSQLを探すパスが調整されます。
知らずに "既定の名前空間" を使っていると、DBFlute.NETとして正常な構成であっても外だしSQLが見つからない可能性がありますので注意を。
omitResourcePathPackage
outsideSqlDefinitionMap.dfprop に、C#特有の omitResourcePathPackage プロパティが存在します。リソース(外だしSQL)を探すパスから省略したい名前空間を指定します。
omitFileSystemPathPackage
outsideSqlDefinitionMap.dfprop に、C#特有の omitFileSystemPathPackage プロパティが存在します。外だしSQLのSQLファイルをファイルシステム上に配置して、それをアプリから読み込んで実行する際の(この機能自体が C# 特有)探すパスから省略したい名前空間を指定します。
additionalAssemblyProvider
DBFluteConfig に、C#特有の additionalAssemblyProvider プロパティが存在します。外だしSQLのSQLファイルの配置アセンブリをさらに追加したい場合に利用します。(C# では、リソースファイルの指定に探す対象のアセンブリの指定が必要なため)
fileSystemPathResolver
DBFluteConfig に、C#特有の fileSystemPathResolver プロパティが存在します。外だしSQLのSQLファイルをファイルシステム上に配置して、それをアプリから読み込んで実行する際に(この機能自体が C# 特有)、そのファイルシステムのパスを(デフォルトと合わない場合に)調整します。

外だしSQLを探すパスを調整するプロパティに関しては、環境に合わせて色々なプロパティを組み合わせて利用します。 複雑になりがちなので都度の検証と合わせて設定するようにして下さい。

その他、細かい環境の違い

その他、DBFlute.NETには存在していないプロパティなど、Java版との環境の違いが存在します。

実装上の違い

主に、ディベロッパーが実装しているときに意識するJava版との違いです。 Java版のドキュメントを参照する前に、これらの違いを必ず理解するようにして下さい。

プロパティの採用

C#の言語仕様である "プロパティ" を、Entity 等におけるプロパティに採用しています。ゆえに、プロパティを呼び出すときに、Java版とはファーストタッチが変わりますのでご注意下さい。

e.g. Entityのプロパティ {MEMBER} @Java
Member member = new Member();
member.MemberId = 3;
member.MemberName = "Savicevic";
String memberName = member.MemberName;

// if Java
//member.setMemberId(3);
//member.setMemberName("Savicevic");
//String memberName = member.getMemberName();

但し、区分値を設定する場合などは、Set で始まるメソッドで表現されます。通常の値の設定と、区分値の設定ではファーストタッチが変わりますのでご注意下さい。

e.g. Entityのプロパティ {MEMBER} @Java
Member member = new Member();
member.SetMemberStatusCode_Formalized();
//member.MemberStatusCode = "FML";

メソッド・プロパティの先頭は大文字

言語の違いによる習慣の違いです(Javaは先頭が小文字)。 一部、ディベロッパーが目にすることはほとんどないと想定される内部クラスでのメソッドでは、 先頭が小文字のものがあります。

e.g. ConditionBeanやBehaviorのメソッド名の先頭 {MEMBER} @Java
cb.Query().SetMemberName_Equal(value);
... = memberBhv.SelectList(cb);

コンパイル言語ですので、コード補完等の支援により、プログラム上ではこの違いで悩まされることは少ないと考えられますが、 唯一、明確に気を付けるべき箇所があります。それは、外だしSQLのパラメータコメント上でのプロパティの参照です。 ここはコード補完が効かず、かつ、プロパティ名の先頭文字の規則がJava版と違うため、注意が必要です。 (Java版のドキュメントを読むときにご注意下さい)

Java
先頭が小文字 (memberName)
C#
先頭が大文字 (MemberName)
e.g. 会員テーブルの会員名称が 'Stojkovic' であること {MEMBER, MEMBER_NAME} @OutsideSql
/*IF pmb.MemberName != null*/
and MEMBER_NAME like /*pmb.MemberName*/'S%'
/*END*/

コールバックで delegate

コールバックを実装するのに、インターフェースではなく delegate を利用します(但し、複数メソッドが必要な箇所では同じくインターフェース方式)。

e.g. ExistsReferrerのコールバックで delegate {MEMBER, PURCHASE} @Java
MemberCB cb = new MemberCB();
cb.Query().ExistsPurchaseList(delegate(PurchaseCB subCB) {
    subCB.Query().SetPurchasePrice_GreaterEqual(2000);
});

埋め込まれたリソース

外だしSQLを利用する際に、SQLファイルの "ビルドアクション" を "埋め込まれたリソース" に設定する必要があります(ファイルシステムに配置する場合はまた別の設定が必要)。 SQLファイルを作成したら、必ずこの作業を忘れずに行って下さい。 (しなかった場合は、実行時に "SQLファイルが見つからない" というエラーになります)

Koropokkur.NET には、これらファイルのプロジェクトへの追加を支援する機能があります。

Exampleのススメ

環境面・実装面で参考になるExampleプロジェクトが存在します。特にディベロッパーは、Behavior や ConditionBean、外だしSQLなどの実際のコード例を見て理解できるように、必ずチェックアウトして実装中いつでも参照できるようにして下さい。

SVNリポジトリURL
https://www.seasar.org/svn/sandbox/dbflute.net
Exampleプロジェクト
dfnet-basic-example (trunk)

ツールのススメ

ReSharperのススメ

必須ではありませんが、ReSharper の利用をお奨めします。

実装をする際の様々な支援機能が付いています。DBFlute.NETのようなタイプセーフが特徴の実装スタイルにおいては、 ReSharper の機能を利用することで、その最大限の力を発揮するでしょう。(特に、キャメルケースコード補完など)

Koropokkur.NETのススメ

必須ではありませんが、必須と言えるくらいの機能を持つ Koropokkur.NET の利用をお奨めします。

特に、その中の "VSArrange" は、VisualStudioと自動生成ツールとの相性のズレを解消してくれるため、DBFlute.NETでは重宝します。 テーブルの追加による新しいクラスのプロジェクトへの追加、テーブルの削除による古いクラスのプロジェクトからの削除、これらを一括で自動調整してくれます。 (アップグレード時の新しいクラスの追加・削除にも役に立ちます)