Quill と DBFlute.NET の未来プロジェクト

Seasar.NETプロダクトたちの現状

Quill と S2Container.NET の二つのDI方式を提供し、
Quill をメイン(推奨)としています。

// Seasar.NET: QuillとS2Container | jfluteの日記
http://d.hatena.ne.jp/jflute/20081215/1229321164

// Quill の .NET 4.0 対応がそろそろ!? | jfluteの日記
http://d.hatena.ne.jp/jflute/20101207/1291650467

の通りです。

S2Container.NETは現行コードのKEEPが基本。
(既に 1.4.0 では S2Container は動作しません)

とはいえ、Quillもそんなに大きな修正はしていません。
もともとスリムな設計なので。

データベース周りは、
S2Dao.NETとDBFlute.NETが主なプロダクトです。
S2Dao.NETは現行コードのKEEPが基本。
先進的な機能はDBFlute.NETが対応。

とはいえ、DBFlute.NETも大きな動きはなく、
Javaと共通の Alto DBFlute 部分だけ更新。

// あれっ、DBFlute.NETは? | jfluteの日記
http://d.hatena.ne.jp/jflute/20120923/1348398340

Seasar.NETプロジェクト自体の現状

そして、Seasar.NETプロジェクト自体は、
「現状維持」がポリシーとなっています。
新しいことは基本的にしません。

jfluteがメンテしているDBFlute.NETは除き、
よほどのバグでなければコードに手を入れない。
特に、S2Container.NET と S2Dao.NET は、
もとより現行コードKEEPなので、完全にそのまま。

メーリングリストでも、
調査作業はあまりせず、わかる範囲でサポート。
基本的にはソースコードを読んでもらう。
パッチを送ってもらっても確認作業もできないので、
参考実装という形で置いておくだけ。
(DBFlute.NETだけは、jfluteのアドリブで)

これは、Seasar.NETのコミッタメンバーが、
OSS活動を継続するのが厳しくなってきたことが背景です。

一時はプロジェクトを閉じることも議論されましたが、
現状維持をポリシーに薄く継続することにしました。
一応、jfluteがリーダーです。

ただ、そんな中でも積極的にメンテをしてくれた、
koyackさんには感謝感謝です。

また、そんな中でもメーリングリストで
助け合いをしてくれていたユーザーの方々に感謝感謝です。

そして、そんな中、こないだの ClubDB2 の帰りに、
koyackさんと「なぎ食堂」でベジごはんを食べながら、
プチ Seasar.NET コミッタ会議しました。

新しいスリムな Quill を!

気付いたらどんどん.NETのバージョンは上がっていきます。
でも、コミッタのモチベーションは上がりません(><。

さすがに現状維持自体もつらくなってきています。
いまの Seasar.NET モジュールは歴史がありすぎなのです。
Java から移植された S2Container.NET や
S2Dao.NET は、その役割を全うしたと思います。

そこでっ!

最新の C# (いまは 5.0) 対応...というか限定の、
もっとスリムで新しい Quill を作ろうという話に。
継続してメンテナンスできるようなもの。
DLLファイルが一つだけで済むような Quill。

「単純なDI」と「トランザクション」だけ。
S2Container.NETも無し、S2Dao.NETも無し、
そして、AOP (Interceptor) も無し、
結局必要になる機能も削っちゃうかもだけど、
まずは、スモールスタート!

互換性も崩す可能性あります。
というか、最新のC#限定だし、
AOP削ったりとか色々と既に崩れるわけですが、
Quillの使い方自体も崩す可能性はあります。

というか、Namespace変えるかもしれないし、
要は、全く新しいプロダクトと言ってもいいでしょう。
(名前もどうなるか...Quill2 とか!?)

新しいC#で新しい DBFlute.NET を!

DBFlute.NETは、今もまだニーズがあります。
というか、若干高まっている気がします(^^。

S2Dao.NET の要らない DBFlute、
Java版と同じ機能を持つ DBFlute、
これができれば、やはりワクワクします。
(Java版は、遥かに洗練されているので)

数年前までは、そんな時間も取れないし、
とてもじゃないが移行できないと考えていました。

気付いたら C# も進化し、
「メソッドエクテンション (拡張メソッド)」
と呼ばれる機能も対応されていました。
http://ufcpp.net/study/csharp/sp3_extension.html

Scalaで先に知ったのですが、
C#にもないのかなぁと思ってつぶやいたら、
Scalaのプロフェッショナルの方に教えてもらいました笑。

これを使えば、Javaのコードをわりと
そのまんま移植できるんじゃないかなって!?
やはり、StringクラスとかIListなど、
標準クラスのメソッドが移植で一番大変なところなので。

そうそう、ADO.NETをラップした、
PreparedStatement や ResultSet なんかも
作ってみたらいいんじゃないかと。
うまく Adaptor をたくさん作って、
できるだけJavaそのままのコードで動くようにと。

そして、jfluteのスキルもこの何年かで上がりました。
100%じゃなくていい、80%くらいの精度でいいから、
JavaからC#に変換するプログラム書けるんじゃないかと。
しかも、dbflute-runtime限定でいいわけですから、
色々な割り切りもできるので、わりと現実的じゃないかと。

こういった知恵を足し合わせていけば移植できるかなって(^^。
また、こういった知恵を楽しむことが大切。
もくもく移植作業では、時間的にも
モチベーション的にも現実的ではないでしょう。

koyackさんに早速、
DBFlute.NETランタイムのプロジェクトの
土台だけ作ってもらいました。(ありがとう!)

// DBFlute.NET | Github
https://github.com/seasarorg/dbflute.net

まだ、dbflute.net-runtime は空っぽです。
まずは、メソッドエクテンションから地道に。
主にはkoyackさんにお願いすることになりますが...
(何が必要なのかの洗い出しはjfluteがやります)

dbflute.net-migrationというプロジェクトは、
これはJavaのプロジェクトです。
JavaのDBFluteランタイムをC#に変換するプログラムを
ちょっとずつ書いていきたいと思います。

Quill + DBFlute.NET をメインプロダクトに!

このままでは、
Seasar.NETというブランドも未来がありません...

そこで、
ニーズが高く、かつ、コミッタも作ってみたいと思う、
Quill と DBFlute.NET をメインプロダクトにして、
しっかり今の.NETの世界でも通じるプロジェクトに!
今後の.NETの進化にもついていけるプロジェクトに!

もちろん、今までの Seasar.NET のモジュールは、
ダウンロードはできますしソースコードも残りますので、
そこは何も変わらずです。
ただ、ドキュメントのトップからは外れるかもですね。

とはいっても、
モノができてからじゃないとお話にならないでしょう。

いつできるかって、そりゃぁまったくわかりません。
jfluteは、いま Java8 対応や Scala への展望など
の方を優先度高くして、日々のOSS活動をしております。
koyackさんも業務多忙でそんな時間は取れないでしょう。
(それでもいつも色々とやってくれて本当にありがとう)

道のりは長そうだし、途中で挫折するかもしれませんが、
とにかく「始めよう」と小さな小さな行動を起こしてみました。

はてさて、どうなることやらねっ(^^

【追記】
// [seasar-dotnet:2386]
Quill と DBFlute.NET の未来プロジェクトのスレッド

ちょっと始まりましたよぅ。
ぜひ、そこのスレッドをご覧あれぃ